技能创建器

用于创建新技能并迭代改进的元技能。

核心流程

确定技能目标和实现方式
编写技能草稿
创建测试用例并运行测试
评估结果（定性 + 定量）
根据反馈改进技能
重复直到满意
扩展测试集进行大规模验证

创建技能

第一步：捕获意图

理解用户意图，明确以下问题：

这个技能让 AI 能做什么？
什么情况下触发此技能？（用户短语/上下文）
期望的输出格式是什么？
是否需要测试用例来验证？

第二步：访谈与调研

主动询问：

边界情况
输入/输出格式
示例文件
成功标准
依赖项

第三步：编写 SKILL.md

技能目录结构

skill-name/
├── SKILL.md (必需)
│   ├── YAML frontmatter (name, description 必需)
│   └── Markdown 指令
└── 捆绑资源 (可选)
    ├── scripts/    - 可执行脚本（确定性/重复性任务）
    ├── references/ - 按需加载到上下文的参考文档
    └── assets/     - 输出中使用的文件（模板、图标、字体）

渐进式加载

元数据（name + description）— 始终在上下文中（~100词）
SKILL.md 正文 — 技能触发时加载（理想 <500 行）
捆绑资源 — 按需加载（无限制，脚本可不加载直接执行）

frontmatter 要点

name: 技能标识符（小写，连字符分隔）
description: 触发时机 + 功能描述。这是主要触发机制 — 包含技能做什么以及何时使用它。描述要稍微"积极"一些，避免触发不足

编写原则

解释为什么：解释指令背后的原因，而非堆砌"必须"/"绝不"
使用祈使语气
保持精简：移除不起作用的内容
泛化而非过拟合：技能要适用于多种场景，不只是测试用例
提供示例：

## 提交信息格式
**示例 1:**
输入: 添加了基于JWT的用户认证
输出: feat(auth): 实现JWT认证机制

第四步：创建测试用例

编写 2-3 个真实的测试提示词，保存到 evals/evals.json：

{
  "skill_name": "example-skill",
  "evals": [
    {
      "id": 1,
      "prompt": "用户的任务提示",
      "expected_output": "期望结果描述",
      "files": []
    }
  ]
}

评测与迭代

运行测试

使用项目内置的 spawn_subagent 工具测试技能效果：

<spawn_subagent>
<label>file_agent: 测试技能效果</label>
<task_prompt>
先加载技能: 使用 skill 工具加载 "技能名称"。
然后执行测试任务: [具体测试提示词]
将输出保存到: /path/to/test-output/
</task_prompt>
<summary_prompt>总结技能指导下的任务完成质量，指出哪些指导有效，哪些不足。</summary_prompt>
</spawn_subagent>

使用 dispatch_agents 并行测试多个用例：

<dispatch_agents>
<tasks>[
  {"agent_id":"file_agent","task_prompt":"加载技能 X，执行测试用例 1...","label":"测试用例1"},
  {"agent_id":"file_agent","task_prompt":"加载技能 X，执行测试用例 2...","label":"测试用例2"},
  {"agent_id":"file_agent","task_prompt":"不加载技能，执行测试用例 1（基线对照）...","label":"基线对照"}
]</tasks>
</dispatch_agents>

评估结果

定性评估：对比有技能版和基线版的输出质量
定量评估：对客观可验证的技能编写断言检查
- 好的断言：客观可验证、描述性命名
- 主观技能（写作风格、设计）：定性评估更合适

改进技能

改进原则：

从反馈中泛化 — 不要只为测试用例优化
保持精简 — 移除不起作用的内容
解释原因 — 比硬性规则更有效
提取重复工作 — 如果多个测试都写了类似脚本，打包到 scripts/

迭代循环

应用改进到 SKILL.md
用 spawn_subagent 或 dispatch_agents 重新运行所有测试
让用户评审结果
读取反馈，继续改进
重复直到用户满意

描述优化

description 字段是决定技能是否被触发的主要机制。

优化流程

生成触发评估查询：20个（一半应触发，一半不应触发）
- 查询要真实、具体、有细节
- 不触发查询应是"近似命中"而非明显无关
与用户确认查询集
迭代优化
- 评估当前描述的触发率
- 基于失败案例提出改进
- 重新评估新描述
- 选择测试集得分最高的（避免过拟合）
应用最佳描述，向用户展示前后对比

技能触发机制

技能出现在 available_skills 列表中，AI 根据描述决定是否使用。要点：

AI 只在无法自行处理时才会查询技能
简单一步任务可能不会触发
复杂、多步骤、专业化查询能可靠触发
评估查询应足够复杂，使 AI 确实需要参考技能

skill-creator