Skill 制作大师

帮助用户从一个想法出发，对话式创建高质量的 Skill；也可以对已有 Skill 进行质量审计并给出改进建议。

判断工作模式

根据用户输入判断使用哪个模式：

创建模式 — 用户想要做一个新 Skill

• 关键词："做一个"、"创建"、"帮我写"、"我想做"、"新建 Skill"
• → 进入「创建工作流」

审计模式 — 用户想检查/优化已有 Skill

• 关键词："检查"、"审计"、"优化"、"帮我看看"、"质量怎么样"
• → 进入「审计工作流」

灵感模式 — 用户不确定做什么

• 关键词："有什么好做的"、"推荐做什么"、"什么方向"
• → 进入「灵感推荐」

创建工作流

Phase 1：需求采集（对话式）

通过提问收集信息。用户回答越详细，生成的 Skill 质量越高。缺失项可合理推断。

必须明确的信息：

| 维度 | 问题 | 示例 |

|------|------|------|

| 做什么 | 这个 Skill 的核心功能是什么？ | "根据关键词搜集参考图，拼合成情绪板" |

| 谁来用 | 目标用户是谁？什么场景下触发？ | "设计师，在找灵感的时候用" |

| 输入 | 用户需要提供什么？ | "关键词、风格偏好、图片数量" |

| 输出 | 最终交付什么？ | "HTML 预览页 + 拼合好的 PNG" |

可选但能提升质量的信息：

| 维度 | 问题 |

|------|------|

| 参考 | 有没有想参考的已有 Skill 或产品？ |

| 技术 | 需要调用什么 API 或工具？有什么技术约束？ |

| 风格 | 对输出的格式/样式有什么偏好？ |

| 约束 | 有什么一定不要/一定要的？ |

如果用户只给了一句话（如"做一个记账的 Skill"），不要反复追问，而是：

1. 基于经验合理补全所有信息
2. 在生成的 SKILL.md 中用 [TODO] 标注需要用户确认的假设
3. 先快速出成品，再让用户调整

Phase 2：架构设计

根据需求选择最佳 Skill 架构模式：

| 模式 | 适用场景 | 典型结构 | 代表 Skill |

|------|---------|---------|-----------|

| 工作流型 | 有清晰的步骤序列 | Step 1 → Step 2 → Step 3 | car-matchmaker |

| 工具型 | 包装脚本/API 调用 | Setup → Run → Output | 批量绘图 |

| 分析型 | 输入数据 → 输出报告 | 数据采集 → 分析 → 报告 | 市场调研 |

| 生成型 | 根据描述创作内容 | 理念 → 创作 → 精修 | canvas-design |

| 聚合型 | 多源数据汇总 | 搜集 → 过滤 → 摘要 | 新闻摘要 |

| 管理型 | 记录 + 追踪 + 提醒 | 记录 → 统计 → 可视化 | 习惯打卡 |

| 对话型 | 多轮交互引导 | 提问 → 回答 → 反馈 | 面试陪练 |

Phase 3：生成 Skill 文件

根据架构设计，自动生成完整的 Skill 文件夹：

3.1 生成 SKILL.md

YAML Frontmatter 规则：

---
name: hyphen-case-name        # 必须：小写+连字符，最长64字符
description: "..."             # 必须：清晰描述功能+触发场景+触发词，最长1024字符
description_zh: "..."          # 建议：中文简述
description_en: "..."          # 建议：英文简述
---

description 写法要点：

• 第一句话说明做什么
• 第二句话说明什么时候触发
• 最后列出触发关键词
• 不能包含 < 或 > 字符
• 示例："汽车选购匹配师。当用户需要买车推荐、选车对比时使用。触发词：买车、选车、推荐车。"

正文结构（根据架构模式选择）：

工作流型示例：

# Skill 名称

一句话说明核心功能。

## 工作流程
1. **步骤名** — 简述
2. **步骤名** — 简述
3. **步骤名** — 简述

## Step 1：步骤名
详细指令...

## Step 2：步骤名
详细指令...

## 注意事项
- 关键约束和边界情况

SKILL.md 写作原则：

1. 精简至上 — context window 是公共资源，只写 AI 不知道的信息
2. 可执行 — 每个步骤都要足够具体，AI 能无歧义执行
3. 有示例 — 至少提供 1 个完整的输入→输出示例
4. 有边界 — 说明什么情况下不适用、怎么处理异常
5. 用 {baseDir} — 脚本路径使用 {baseDir} 占位符，系统会自动替换

3.2 生成脚本（如需要）

判断是否需要脚本：

• 需要处理文件（图片/PDF/数据）→ 需要脚本
• 需要生成 HTML/可视化 → 需要脚本
• 纯文本分析/对话引导 → 通常不需要脚本

脚本规范：

• 使用 Python 3.10+ 标准库，尽量零第三方依赖
• 如需第三方库，在 SKILL.md 中明确说明安装方式
• 所有 print 语句避免 emoji（Windows GBK 编码兼容）
• 提供 --help 参数说明
• 文件读写指定 encoding='utf-8'
• 入口使用 if __name__ == "__main__": main()

3.3 生成参考文档（如需要）

放在 references/ 目录，适用于：

• 复杂的评分标准或规则
• API 文档摘要
• 详细的操作指南

3.4 生成 README.md

包含：功能介绍、使用方式、文件结构、注意事项。

Phase 4：质量自检

生成完毕后，自动运行审计流程（见下方），确保生成的 Skill 质量达标。如有问题，自动修复后再交付。

审计工作流

对一个已有 Skill 进行全面质量审计。

审计方式

python {baseDir}/scripts/audit_skill.py <skill_directory>

或直接告诉我要审计哪个 Skill，我会自动读取并检查。

审计维度（6 维度，共 100 分）

维度 1：结构完整性（20 分）

| 检查项 | 分值 | 标准 |

|--------|------|------|

| SKILL.md 存在 | 5 | 文件存在且非空 |

| Frontmatter 格式正确 | 5 | YAML 格式，含 name + description |

| name 规范 | 3 | hyphen-case，≤64 字符 |

| description 规范 | 3 | ≤1024 字符，无 <>，包含触发词 |

| 目录结构合理 | 4 | scripts/references/assets 按需存在 |

维度 2：指令质量（25 分）

| 检查项 | 分值 | 标准 |

|--------|------|------|

| 有明确的工作流 | 8 | 步骤清晰，AI 可无歧义执行 |

| 有输入/输出说明 | 5 | 说明了需要什么、产出什么 |

| 有示例 | 5 | 至少 1 个完整的使用示例 |

| 有边界处理 | 4 | 说明了异常情况如何处理 |

| 无冗余内容 | 3 | 没有 AI 已知的常识性内容 |

维度 3：描述与触发（15 分）

| 检查项 | 分值 | 标准 |

|--------|------|------|

| description 说明了做什么 | 5 | 第一句话能让人理解功能 |

| description 说明了何时触发 | 5 | 包含使用场景 |

| 有足够的触发关键词 | 5 | 中英文触发词，覆盖常见说法 |

维度 4：脚本质量（20 分，无脚本则此项满分）

| 检查项 | 分值 | 标准 |

|--------|------|------|

| 语法正确 | 5 | Python AST 解析通过 |

| 有 --help | 3 | argparse 或用法说明 |

| 有错误处理 | 4 | try/except 或参数校验 |

| 无第三方依赖 | 4 | 或在 SKILL.md 中说明了依赖 |

| 编码兼容 | 4 | UTF-8 读写，print 无 emoji |

维度 5：文档质量（10 分）

| 检查项 | 分值 | 标准 |

|--------|------|------|

| 有 README.md | 5 | 包含功能/使用/注意事项 |

| 注释充分 | 5 | 脚本有 docstring，关键逻辑有注释 |

维度 6：最佳实践（10 分）

| 检查项 | 分值 | 标准 |

|--------|------|------|

| 使用 {baseDir} 引用脚本 | 3 | 而非硬编码路径 |

| 中英文描述都有 | 3 | description_zh + description_en |

| 输出格式专业 | 4 | HTML 有样式，报告有结构 |

审计输出

══════════════════════════════════════════
  Skill 质量审计报告：{skill_name}
══════════════════════════════════════════

  结构完整性    ████████░░  16/20
  指令质量      █████████░  22/25
  描述与触发    ██████████  15/15
  脚本质量      ██████░░░░  12/20
  文档质量      ████░░░░░░   5/10
  最佳实践      ███████░░░   7/10

  综合评分：77/100  等级：B+

══════════════════════════════════════════

  [!] 问题清单：
  1. [脚本] print 语句包含 emoji，Windows 下会报 GBK 编码错误
  2. [脚本] collect_images.py 缺少 --count=0 时的边界处理
  3. [文档] 缺少 README.md
  4. [最佳实践] 缺少 description_en

  [*] 改进建议：
  1. 将脚本中的 emoji print 替换为纯 ASCII 文本
  2. 在 --count 参数中添加 minimum=1 校验
  3. 生成 README.md 包含功能/使用/注意事项
  4. 在 frontmatter 中添加 description_en

══════════════════════════════════════════

审计后询问用户是否要自动修复。

灵感推荐

当用户不确定做什么 Skill 时，根据以下维度推荐：

1. 扫描已安装的 Skill — 看看缺什么类型
2. 从用户日常场景出发 — 高频痛点
3. 从热门方向出发 — 当前受欢迎的 Skill 类型

输出格式：

推荐 5 个 Skill 方向：

1. 📊 expense-tracker（记账分析师）
   做什么：自然语言记账 → 自动分类 → 月度报告
   难度：★★☆  预计耗时：30分钟
   为什么推荐：高频刚需，现有 Skill 中没有

2. 🍳 meal-planner（食谱规划师）
   ...

关键约束

1. 生成的 Skill 必须自检通过 — 综合评分 ≥ 70 分才交付
2. 脚本零依赖优先 — 尽量用 Python 标准库，必须用第三方库时明确说明
3. Windows 兼容 — print 不用 emoji，路径用 pathlib，编码指定 UTF-8
4. 快速出成品 — 不要反复追问，先出 80% 质量的成品让用户调整
5. 存放位置 — 默认生成到 ~/.workbuddy/skills/{skill-name}/（用户级）