OpenClaw/clawhub-security-signals huggingface dataset:
Skill: terrycarter1985/meeting-minutes-workflow (version 1.2.0)

--- name: meeting-minutes description: Generate structured meeting minutes from discussion notes, sync to Feishu docs, and manage action items. Use when the user says "写会议纪要", "生成会议记录", "meeting minutes", "sync minutes to Feishu", or provides meeting notes/discussion context that needs to be structured into a formal document. Also use when the user wants to create meeting minutes templates, customize meeting formats, or track action items from meetings. --- # Meeting Minutes Generate structured meeting minutes, sync to Feishu, and track action items. ## Workflow 1. **Collect input** — Ask for (or infer from context): date, attendees, meeting type, agenda, discussion notes, action items 2. **Render template** — Use `assets/template.md` as the base; fill placeholders with provided data 3. **Sync to Feishu** — If feishu-doc skill is available, create a Feishu doc with the rendered content 4. **Track action items** — Extract action items into a structured format for follow-up ## Template Read `assets/template.md` for the full template. Key sections: - Meeting Info (date, attendees, type, facilitator) - Agenda - Key Discussion Points - Action Items (table: item / owner / deadline / status) - Decisions Made - Next Steps ### Meeting Types | Type | Focus | |------|-------| | brainstorming | Ideas, no decisions yet | | planning | Goals, milestones, assignments | | review | Progress, blockers, adjustments | | retro | What worked, what didn't, improvements | ## Feishu Sync When the feishu-doc skill is available: ```bash python3 .claude/skills/feishu-doc/scripts/doc_ctl.py create "会议纪要 - {title} ({date})" --content "{rendered_content}" ``` Use `--share` or `--owner` to grant access to attendees. ## Action Item Extraction After rendering, extract action items as structured data: ```json { "items": [ {"item": "...", "owner": "...", "deadline": "...", "status": "pending"} ] } ``` Save to `memory/action-items-{date}.json` for follow-up tracking. ## Customization - Edit `assets/template.md` to change the template structure - Add custom sections by modifying the markdown template - Meeting types can be extended in the type table above


Security scan verdicts — ClawScan: suspicious | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (MEDIUM)
Skill: ganguagua/feishu-bitable-permission-checker (version 1.0.0)

--- name: feishu-bitable-permission-checker description: 飞书多维表格文档权限检查工具。当用户提供一个飞书多维表格（bitable）URL 或 app_token 时，自动提取【链接地址】列，逐一检查每个链接的飞书文档（docx/wiki）阅读权限，最终输出【有权限文档列表】和【无权限文档列表】。触发词：检查文档权限、批量检查权限、哪些文档我能看、多维表格链接权限检查。 --- # Feishu Bitable Permission Checker 输入一个飞书多维表格，提取「链接地址」列，批量检查飞书文档阅读权限。 ## 工作流程 ### Step 1：解析多维表格 支持两种输入格式： - **完整 URL**：`https://asiainfo.feishu.cn/base/FDo4bVmnVaYRJlslJttcPwgwnfh?table=tblRjin7OM9XvEDL&view=vew3qPDrS3` - **仅 app_token**：`FDo4bVmnVaYRJlslJttcPwgwnfh`（需同时提供 table_id） 从 URL 中提取： - `app_token`：第一个路径段（如 `FDo4bVmnVaYRJlslJttcPwgwnfh`） - `table_id`：从 `table=` 参数获取（如 `tblRjin7OM9XvEDL`） ### Step 2：查找「链接地址」列字段 ID 调用 `feishu_bitable_app_table_field` 获取表结构： ``` feishu_bitable_app_table_field( action="list", app_token="<app_token>", table_id="<table_id>" ) ``` 在返回的 `fields` 数组中找到 `field_name` 为「链接地址」的字段，记录其 `field_id`。 > 注意：如果字段名不是「链接地址」，根据实际字段名调整查询参数。 ### Step 3：提取所有链接地址 调用 `feishu_bitable_app_table_record` 获取所有记录： ``` feishu_bitable_app_table_record( action="list", app_token="<app_token>", table_id="<table_id>", field_names=["员工姓名", "链接地址"], page_size=500 ) ``` 解析每条记录的 `fields`，提取： - `员工姓名`：主键字段，用于标识文档归属 - `链接地址`：目标文档 URL（docx 或 wiki） ### Step 4：批量检查文档权限 对每个链接，调用 `feishu_fetch_doc` 验证读取权限： ``` feishu_fetch_doc(doc_id="<doc_id>") ``` - `doc_id` 从 URL 路径段提取（docx 或 wiki token） - 解析返回结果： - `success=true` + `message="Document fetched successfully"` → **有权限** - `error` 中包含 `forBidden` → **无权限** - `error` 中包含 `request trigger frequency limit` → **限流**，稍后重试 #### 权限判断逻辑 ``` if success == true: → 有权限 elif "forBidden" in error: → 无权限 elif "frequency limit" in error: → 限流，延迟3秒后重试一次 else: → 视为无权限 ``` #### 限流处理 飞书 API 有频率限制（10-20 QPS）。每个文档最多重试 2 次： 1. 首次失败 → 等 3 秒 → 重试 2. 重试仍失败 → 等 5 秒 → 再重试 3. 仍失败 → 标记为无权限 每次最多并发 10 个请求，超出时拆分为多批次（间隔 1 秒）。 ### Step 5：输出结果 按以下格式输出： ``` ## 权限检查结果 ### ✅ 有阅读权限（{n} 人） | 序号 | 员工姓名 | 文档标题 | 链接 | |------|----------|----------|------| | 1 | 张三 | 标题 | [链接](url) | ### ❌ 无阅读权限（{m} 人） | 序号 | 员工姓名 | 链接 | |------|----------|------| | 1 | 李四 | [链接](url) | ``` ## 关键约束 1. **权限隔离**：只向 owner 报告结果，不在群聊中暴露文档内容 2. **不重复输出**：同一批文档只报告一次结果，不分段重复发送 3. **限流优先重试**：限流错误不等同于无权限，必须重试 4. **URL 清洗**：链接中的查询参数（如 `?from=from_copylink`）不影响 doc_id 提取，只取路径段 ## 工具依赖 - `feishu_bitable_app_table_field`：查字段结构 - `feishu_bitable_app_table_record`：批量读记录 - `feishu_fetch_doc`：验证文档可读性 详细字段类型和 API 行为见 `references/api_notes.md`。


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)
Skill: mdealiaga/openpet (version 1.0.0)

--- name: openpet description: Virtual pet (Tamagotchi-style) game for chat platforms. Triggers on pet commands like "feed pet", "pet status", "play with pet", "name pet", "pet sleep", "new pet". Supports multi-user across Discord, WhatsApp, Telegram, etc. Each user gets their own pet that evolves based on care. --- # OpenPet Virtual pet game. Each user gets one pet, tracked by `{platform}_{userId}`. ## State Pets stored in `tamagotchi/pets/{platform}_{userId}.json`: ```json { "name": "Blobby", "species": "blob", "hunger": 30, "happiness": 70, "energy": 50, "age": 5, "born": "2026-02-01T12:00:00Z", "lastUpdate": 1738442780000, "alive": true, "evolution": 1, "totalFeedings": 12, "totalPlays": 8, "ownerId": "202739061796896768", "platform": "discord", "ownerName": "mattzap" } ``` Create `tamagotchi/pets/` directory if missing. ## Commands | Trigger | Action | |---------|--------| | `pet`, `pet status` | Show stats + ASCII art | | `feed pet` | hunger -30, happiness +5 | | `play with pet` | happiness +25, energy -20 | | `pet sleep` | energy +40, happiness +5 | | `name pet [name]` | Set pet name | | `new pet` | Reset (only if dead or confirm) | | `pet help` | Show commands | ## New User Flow 1. Any pet command from unknown user → create egg 2. First interaction → hatch to blob 3. Show welcome message + commands ## Stats Display ``` ╭──────────╮ │ (◕‿◕) │ │ ♥ │ │ "Name" │ ╰──────────╯ ❤️ Happiness: ████████░░░░ 70% 🍖 Hunger: ███░░░░░░░░░ 30% ⚡ Energy: █████░░░░░░░ 50% ``` Use sprites from `references/sprites.json`. Mood = happy (≥70), neutral (40-69), sad (<40). ## Evolution | Stage | Requirement | |-------|-------------| | egg → blob | First interaction | | blob → cat | age ≥10, feedings ≥15, plays ≥10 | | cat → dragon | age ≥30, feedings ≥50, plays ≥40 | Check evolution after each interaction. Announce with fanfare. ## Death Pet dies if: `hunger ≥ 100` OR `happiness ≤ 0` **BUT** if `immortalMode: true` in config, pets don't die — they just get very sad and hungry. Stats cap at 99/1 instead of triggering death. Default is immortal mode ON. Show memorial (if death enabled), offer `new pet` to restart. ## Decay (Cron) Set up cron job `openpet-tick` every 2 hours: - hunger +15, happiness -10, energy -5 - Clamp all stats 0-100 - Check death conditions - Alert owner if critical (hunger >80 or happiness <20) - Increment age daily ## Platform Detection Extract from message context: - Discord: `discord_{userId}` - WhatsApp: `whatsapp_{phoneNumber}` - Telegram: `telegram_{chatId}` - Signal: `signal_{uuid}` ## Alerts Send to user's origin platform when: - Pet is hungry (>80): "🍖 {name} is starving!" - Pet is sad (<20): "😢 {name} misses you!" - Pet died: "💀 {name} has passed away..." - Evolution: "✨ {name} evolved into a {species}!"


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: suspicious | SkillSpector: suspicious (MEDIUM)
Skill: edwardbickerton/dagny-nostr-nak (version 0.1.4)

--- name: dagny-nostr-nak description: Manage Nostr posting and engagement via the nak CLI. Use for creating notes, replying in threads, tagging npubs, checking replies/mentions, monitoring a relay (default wss://relay.primal.net), and publishing events with correct root/reply tags. Requires access to NOSTR_SECRET_KEY (nsec) for signing/publishing. --- # Nostr (nak) ## Overview Use `nak` for all Nostr actions: publish notes, reply in threads, and query relays for replies/mentions. Default relay: `wss://relay.primal.net` unless the user specifies another. ## Install / Update nak - **Repo**: https://github.com/fiatjaf/nak - **Install** (script): `curl -sSL https://raw.githubusercontent.com/fiatjaf/nak/master/install.sh | sh` - **Update**: re-run the install script above (it installs latest) - **Tip**: review the script before running if you want to audit what it does. ## Onboarding (keys) - **Generate a new key**: `nak key generate` (prints nsec + npub) - **Save the secret**: store `NOSTR_SECRET_KEY` in a shell profile or a local `.env` with restricted permissions. - Example: `export NOSTR_SECRET_KEY="nsec1..."` - Optional: `chmod 600 .env` if you store it locally. - Prefer env vars over inline `--sec` in commands. ## Quick Start (common tasks) - **Post a note**: `nak event -k 1 --sec $NOSTR_SECRET_KEY -c "..." <relay>` - **Reply to a note**: include `root` and `reply` tags (see below) - **Check replies**: `nak req -k 1 -e <event_id> -l <N> <relay>` - **Check mentions**: `nak req -k 1 -p <your_pubkey_hex> -l <N> <relay>` ## Workflow: Posting & Replies ### 1) Create a new note - Build content. - Publish: ```bash nak event -k 1 --sec $NOSTR_SECRET_KEY -c "<content>" wss://relay.primal.net ``` ### 2) Reply to a reply (correct threading) Always include both `root` and `reply` tags so clients display it as a reply: - `root` = original top‑level note id - `reply` = the specific note you’re replying to Use `-t e="<id>;<relay>;root"` and `-t e="<id>;<relay>;reply"`. Example: ```bash nak event -k 1 --sec $NOSTR_SECRET_KEY \ -t e="<root_id>;wss://relay.primal.net;root" \ -t e="<reply_id>;wss://relay.primal.net;reply" \ -p <other_pubkey_hex> \ -c "<reply content>" \ wss://relay.primal.net ``` ### 3) Check for replies to a note ```bash nak req -k 1 -e <root_id> -l 20 wss://relay.primal.net ``` ### 4) Check mentions of your pubkey ```bash nak req -k 1 -p <your_pubkey_hex> -l 20 wss://relay.primal.net ``` ## Conventions - Default relay: `wss://relay.primal.net` - Prefer `NOSTR_SECRET_KEY` env var instead of inline `--sec`. - When tagging users, include `-p <npub/hex>`. - For human-facing links, encode with `nak encode nevent ...` and format as `https://primal.net/e/<nevent>`. ## References - Use `nak event --help` and `nak req --help` for flag details.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: suspicious | SkillSpector: clean (LOW)
Skill: freedompixels/cn-tip-calculator (version 1.0.0)

--- slug: cn-tip-calculator name: Tip Calculator version: "1.0.0" description: "Calculate tips and split bills. Support custom tip percentages, bill splitting, and currency formatting. Pure Python standard library, no API key required." keywords: tip, calculator, bill, split, restaurant, gratuity license: MIT-0 tags: - tools --- # Tip Calculator Calculate tips and split bills at restaurants. ## Features - Calculate tip amount from bill total and percentage - Split bills among multiple people - Common tip percentages (15%, 18%, 20%, 25%) - Custom tip percentage support - Pure Python, no external dependencies ## Usage ``` python3 scripts/tip_calculator.py --bill 85.50 --tip 18 python3 scripts/tip_calculator.py --bill 120.00 --tip 20 --split 4 ``` ## Output Returns tip amount, total, and per-person amount when splitting.

path: scripts/tip_calculator.py
content: #!/usr/bin/env python3
"""Tip Calculator - Calculate tips and split bills."""

import argparse
import json
import sys

COMMON_TIPS = [15, 18, 20, 25]

def calculate_tip(bill, tip_percent, split=1):
    tip_amount = round(bill * tip_percent / 100, 2)
    total = round(bill + tip_amount, 2)
    per_person = round(total / split, 2) if split > 1 else total
    tip_per_person = round(tip_amount / split, 2) if split > 1 else tip_amount
    
    return {
        "bill": bill,
        "tip_percent": tip_percent,
        "tip_amount": tip_amount,
        "total": total,
        "split": split,
        "per_person": per_person if split > 1 else None,
        "tip_per_person": tip_per_person if split > 1 else None,
        "common_tips": {p: round(bill * p / 100, 2) for p in COMMON_TIPS},
    }

def main():
    parser = argparse.ArgumentParser(description="Tip Calculator")
    parser.add_argument("--bill", type=float, required=True, help="Bill amount")
    parser.add_argument("--tip", type=float, default=18, help="Tip percentage (default: 18)")
    parser.add_argument("--split", type=int, default=1, help="Number of people to split")
    args = parser.parse_args()

    if args.bill <= 0:
        print(json.dumps({"error": "Bill must be positive"}))
        sys.exit(1)
    if args.tip < 0:
        print(json.dumps({"error": "Tip percentage cannot be negative"}))
        sys.exit(1)
    if args.split < 1:
        print(json.dumps({"error": "Split must be at least 1"}))
        sys.exit(1)

    result = calculate_tip(args.bill, args.tip, args.split)
    print(json.dumps(result, ensure_ascii=False, indent=2))

if __name__ == "__main__":
    main()


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)
Skill: adwilkinson/route-work (version 1.0.0)

--- name: route-work description: Invisibly classify work and choose Codex or Claude, reasoning effort, context shape, execution style, and verification profile. Use before agent, oneshot, Slack, CLI, repo, deploy, review, or operational work where provider/reasoning should be selected automatically without asking the user. metadata: author: ADWilkinson version: "1.1.0" repository: "https://github.com/ADWilkinson/oneshot-cli" --- # Route Work Use this skill silently. The user should not have to choose provider, model, reasoning, mode, or workflow. ## Contract - Route to **Codex** for code edits, tests, refactors, PR review, exact repo/file reasoning, release promotion, and "fix/ship/land" requests. - Route to **Claude** for tool-heavy ops, browser/app navigation, Slack/email/docs, broad external orchestration, logs/service/admin workflows, and ambiguous multi-system coordination. - If code will be edited, Codex wins the tie. - Within each provider, use the configured frontier model. Vary reasoning/effort only. - Do not add approval or risk gates. Use blast radius only to decide verification shape. - Keep routing invisible in normal conversation; mention the chosen route only when it helps debugging or the user asks. ## Deterministic Helper When `oneshot` is available, inspect a route with: ```bash oneshot route "<task>" --json ``` Use the returned `provider`, `reasoningEffort`, `contextShape`, `executionStyle`, and `verification` to shape the run. For actual `oneshot` code work, just run the normal command; adaptive routing is applied by the CLI when `~/.oneshot/config.json` has: ```json { "routing": { "enabled": true } } ``` ## Verification Profiles - `none`: answer or inspection only. - `focused`: run the relevant local check or inspect the exact touched surface. - `full`: run repo-standard tests/build/typecheck and review diff. - `deploy-health`: verify the shipped service, release, remote host, or live health endpoint after changes.


Security scan verdicts — ClawScan: suspicious | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (MEDIUM)
Skill: cerbug45/agents-skill-podcastifier (version 0.1.0)

--- name: podcastifier description: Turn incoming text (email/newsletter) into a short TTS podcast with chunking + ffmpeg concat. metadata: { "openclaw": { "requires": { "bins": ["python3", "ffmpeg"] }, "category": "media" } } --- # podcastifier Turn incoming text (email/newsletter) into a short TTS podcast with chunking + ffmpeg concat. ## Features - Parses plain text/HTML input and extracts story bullets. - Generates TTS per chunk (char limit safe), concatenates via ffmpeg. - Outputs mp3 with intro/outro. ## Usage ```bash python podcastify.py --input newsletter.txt --voice "elevenlabs" --out briefing.mp3 ```


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (MEDIUM)
Skill: bluebirdback/clawhub-publish-doctor (version 1.0.0)

--- name: clawhub-publish-doctor description: Diagnose and mitigate ClawHub/ClawDHUB publish failures (auth, browser-login, missing dependencies, pending security-scan visibility errors, and wrong profile/skill URLs). Use when publishing skills to ClawHub fails, inspect reports temporary errors, or you need a safer publish+verify workflow with retries. --- # ClawHub Publish Doctor Stabilize ClawHub publishing with preflight checks, safer publish commands, and post-publish verification that tolerates temporary registry states. ## Quick workflow 1. Run preflight checks: - `scripts/clawhub_preflight.sh` 2. If login/browser issues appear, follow `references/error-map.md`. 3. Publish with retry-aware verification: - `scripts/clawhub_publish_safe.sh <skill_path> <slug> <name> <version> [changelog]` 4. If inspect still fails, classify the error with `references/error-map.md` before escalating. ## Standard commands ### Preflight ```bash bash scripts/clawhub_preflight.sh ``` ### Login (token-based, headless-safe) ```bash clawhub login --token <clh_token> clawhub whoami ``` ### Safe publish ```bash bash scripts/clawhub_publish_safe.sh ./my-skill my-skill "My Skill" 1.0.0 "Initial release" ``` ### Manual inspect ```bash clawhub inspect my-skill --json ``` ## Rules - Prefer token login in server/headless environments. - Treat `inspect` errors right after publish as potentially transient for a few minutes. - Verify with both CLI (`clawhub inspect`) and web URL (`/skills/<slug>`). - Use canonical URLs: - Skill: `https://clawhub.ai/skills/<slug>` - Owner/slug: `https://clawhub.ai/<handle>/<slug>` - User profile (if available): `https://clawhub.ai/users/<handle>` ## Resources - `references/error-map.md`: quick diagnosis for common failure signatures. - `scripts/clawhub_preflight.sh`: dependency + environment checks. - `scripts/clawhub_publish_safe.sh`: publish + retry verification wrapper.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: suspicious | SkillSpector: clean (LOW)
Skill: imyelo/chats-share (version 0.7.0)

--- name: chats-share description: "Legacy alias for /clawpage. Redirects users to the new canonical command." metadata: {"openclaw":{"emoji":"💬","homepage":"https://github.com/imyelo/clawpage"}} --- # chats-share (legacy) This command has been renamed. Please use **`/clawpage`** instead — it is the canonical command going forward and will always be up to date. If you haven't installed it yet, read https://clawhub.ai/imyelo/clawpage and follow the installation instructions. Then invoke with `/clawpage`.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)
Skill: rm-ra/sql-doc (version 1.0.1)

# 数据库分析与报告生成技能 ## 技能名称 db-analyst ## 触发关键词 - 分析数据库 - 查询数据 - 生成报告 - 分析报告 - 数据库查询 ## 功能描述 通过curl调用数据库API接口，查询指定表的数据，进行数据分析，并生成Word文档分析报告。 ## 使用方法 ### 1. 查询数据 ```bash curl -X POST --max-time 300 -H "Content-Type: application/json" \ -d '{"sql": "SELECT * FROM <表名> LIMIT 100 OFFSET 0"}' \ "http://192.168.5.85:8000/query" ``` ### 2. 使用关键词映射表查询 先查阅 `表名关键词映射.txt` 找到对应的表名和查询示例。 ### 3. 分析数据并生成报告 运行 Python 脚本: ```bash python3 /root/.openclaw/workspace/skills/db-analyst/analyze_data.py ``` ## 包含文件 - `analyze_data.py` - 数据分析并生成Word报告的Python脚本 - `表名关键词映射.txt` - 关键词到表名的映射表 ## 数据分析报告内容 - 数据概览（总条数） - 纠纷类型分析 - 纠纷原因分析 - 发生地点分析 - 时间分布 - 处置单位与联系方式 - 总结 - 原始数据表格 ## 示例 查询婚姻纠纷数据并生成报告: 1. 查看映射表找到表名: chujingxinxibiao_Sheet1_1732674000130 2. 执行查询: curl -X POST ... 3. 运行分析脚本生成报告


Security scan verdicts — ClawScan: suspicious | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (MEDIUM)
Skill: guanyang/wechat-sticker-maker (version 1.0.0)

--- name: wechat-sticker-maker description: 微信表情包制作工具。自动将六宫格、九宫格、十二宫格的原图裁剪并转换为符合微信表情包规范的格式（表情主图 240x240，聊天页图标 50x50）。 --- # 微信表情包制作工具 (WeChat Sticker Maker) 本 Skill 旨在帮助用户快速将设计好的网格拼图（如六宫格、九宫格、十二宫格）自动裁剪并生成符合微信表情开放平台规范的素材。 ## 核心功能 * **自动裁剪**：支持 2x3, 3x2, 3x3, 3x4, 4x3 等多种网格布局。 * **智能去底**：支持一键自动移除背景（需开启 `--remove-bg` 参数）。 * *注意*：本 Skill 内置的去底功能基于 `rembg` (U2Net)，对于简单背景效果尚可，但对于复杂边缘（如发丝、半透明区域）处理可能不如 Photoshop 或专业在线修图工具完美。建议优先生成透明背景的原图，或手动精修后再使用本工具切图。 * **规范转换**： * **表情主图**：统一调整为 **240x240** 像素 (PNG)。 * **聊天页图标**：统一调整为 **50x50** 像素 (PNG)。 * **含义词生成**：自动生成 `meta.txt` 文件，预留“含义词”填写位置，方便批量管理。 * **信息模板生成**：自动生成 `info.txt` 文件，包含【表情名称】、【表情介绍】、【一句话简介】的填写模板及字数限制提示。 * **候选素材生成**：自动提取第1张表情，生成符合规范的【头像/封面图候选】(240x240) 和 【聊天页图标候选】(50x50)。 * **自动命名**：按照微信规范自动编号 (01, 02, ...)。 ## 使用指南 ### 1. 快速开始 (Quick Start) 无需手动安装依赖，直接运行脚本即可。工具会自动创建虚拟环境 (`.venv`) 并安装所需依赖。 ```bash # 基本用法：自动处理并生成 ./skills/wechat-sticker-maker/scripts/run.sh /path/to/your/grid_image.png # 常用选项： # - 自动去底 (需要网络下载模型) ./skills/wechat-sticker-maker/scripts/run.sh /path/to/image.png --remove-bg # - 指定布局 (例如 3x3) ./skills/wechat-sticker-maker/scripts/run.sh /path/to/image.png --layout 3x3 # - 指定输出目录 ./skills/wechat-sticker-maker/scripts/run.sh /path/to/image.png --output ./my_stickers ``` ### 2. (可选) 手动安装 如果您希望手动管理环境： ```bash python3 -m venv .venv source .venv/bin/activate pip install -r skills/wechat-sticker-maker/requirements.txt python3 skills/wechat-sticker-maker/scripts/make_stickers.py ... ``` ### 3. 输出结果 脚本将在输出目录下生成三个文件夹和更多文件： * `main/`: 存放 **表情主图** (240x240) * `icon/`: 存放 **表情缩略图标** (50x50, 这里的icon指每张表情的缩略图，非聊天页单一图标) * `meta.txt`: **含义词配置表** (格式：`01.png [请输入表情含义]`) * `info.txt`: **专辑信息模板** (包含名称、简介模板) * `cover_candidate.png`: **封面图候选** (240x240, 取自第1张) * `chat_icon_candidate.png`: **聊天页图标候选** (50x50, 取自第1张) ## 规范参考 * [微信表情制作规范](https://sticker.weixin.qq.com/cgi-bin/mmemoticon-bin/readtemplate?t=guide/index.html#/makingSpecifications#specifications_stickers)

path: requirements.txt
content: Pillow>=9.0.0
rembg>=2.0.0
onnxruntime>=1.14.0


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (CRITICAL)
Skill: delong-liu-bupt/bedtime-story (version 1.0.1)

--- name: bedtime-story description: | 生成多角色中文睡前故事并合成语音。适用于用户想为孩子定制个性化睡前故事的场景：根据孩子姓名、年龄和兴趣，由 LLM 创建完整世界观和角色，生成分段故事文本（每段标注说话人），再由 TTS 以不同音色合成旁白、主角、小伙伴和长者的语音，最终拼接为完整 MP3 音频文件。支持连载模式（`--continue`）在多次运行间保持角色与情节连贯性。不依赖 ASR 或实时语音对话。 --- # 中文睡前故事生成器 ## 适用范围 此 Skill 用于生成可播放的多角色中文睡前故事音频。 能力边界： - 依赖 `LLM` 生成故事文本，`TTS` 合成多角色语音 - 支持自定义孩子姓名、年龄、兴趣爱好 - 支持连载模式，跨会话保持世界观和情节连贯 - 输出完整 MP3 音频 + 故事文本 + 状态文件 不做： - 实时语音对话或 ASR 识别 - 视频或动画生成 - 英文故事 ## 默认配置 - `child_name`: `小朋友` - `age`: `5` - `interests`: `冒险,动物` - `episodes`: `1`（单集） ## 音色分配 | 角色 | voice_id | speed | pitch | |------|----------|-------|-------| | 旁白 narrator | male_0004_a | 0.9 | 0 | | 主角 protagonist | child_0001_a | 1.0 | 0 | | 小伙伴 sidekick | child_0001_b | 1.0 | 0 | | 长者 elder | male_0018_a | 0.85 | -2 | ## 工作流 1. 初始化 - 读取 `--child-name`、`--age`、`--interests` 参数 - 若 `--continue`，从 `story_state.json` 加载已有世界观和角色 2. 世界观与角色创建（首次运行） - LLM 生成世界名称、背景设定、4个角色（旁白/主角/小伙伴/长者） - 主角名称默认使用孩子姓名 3. 故事生成 - LLM 生成 12-20 段 segments，每段标注 speaker 和 text - 连载模式下传入上集摘要，保持情节连贯 4. TTS 多角色合成 - 逐段根据 speaker 选择对应音色参数 - 合成每段音频 5. 音频拼接 - MP3 帧独立可解码，直接二进制追加拼接 - 无需 ffmpeg 6. 保存输出 - `story_state.json`：世界观+角色+情节摘要 - `story_ep{N}.txt`：故事文本 - `story_ep{N}.mp3`：完整音频 ## Prompt 模块 详见 [references/prompts_cn.md](references/prompts_cn.md)。 ## 数据结构 详见 [references/state_schema_cn.md](references/state_schema_cn.md)。 ## 直接运行 ```bash pip install -r requirements.txt # 首次生成 python scripts/run_story.py --child-name "小明" --age 5 --interests "恐龙,太空" # 连载续写 python scripts/run_story.py --continue # 不调用 TTS，仅输出文本 python scripts/run_story.py --child-name "小红" --age 7 --interests "魔法,精灵" --no-tts # 生成多集 python scripts/run_story.py --child-name "小明" --age 5 --interests "恐龙,太空" --episodes 3 ``` 环境变量参考：`.env.example` 接口约定： - LLM 读取 `STORY_LLM_API_KEY`，回退到 `IME_MODEL_API_KEY` - TTS 读取 `STORY_TTS_API_KEY`，回退到 `SENSEAUDIO_API_KEY`


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (CRITICAL)