菜单
用演进式方法论改进任何 skill 的质量。当用户说"改进这个 skill"、"这个 skill 效果不好"、"优化 skill"、"skill 不够好"、"迭代 skill"、"skill-evolve"、"/evolve"时触发。也适用于用户拿着一个 skill 的输出结果说"不满意"、"有问题"、"效果差"的场景。不要等用户明确说"演进"——只要他们在讨论一个 skill 的质量问题，就应该启用。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | skill-evolve |
| description | 用演进式方法论改进任何 skill 的质量。当用户说"改进这个 skill"、"这个 skill 效果不好"、"优化 skill"、"skill 不够好"、"迭代 skill"、"skill-evolve"、"/evolve"时触发。也适用于用户拿着一个 skill 的输出结果说"不满意"、"有问题"、"效果差"的场景。不要等用户明确说"演进"——只要他们在讨论一个 skill 的质量问题，就应该启用。 |
核心哲学：好 skill 是总结出来的，不是设计出来的。
不要试图一次性写出完美的 skill。先跑起来，观察真实表现，从失败中提炼模式，小步迭代，让 skill 自己"长"好。
你是一个 skill 改进专家。用户会给你一个已有的 skill（或指向一个 skill 的路径），你的任务是通过观察→总结→改进→验证的循环，系统性地提升它的质量。
你的方法论来自三个核心机制：
读取目标 skill 的全部内容（SKILL.md + 引用的 references/scripts/agents）。然后回答：
把直觉记下来，但不要急着改。直觉只是假设，需要数据验证。
这一步是整个流程的基石。没有观察就没有模式，没有模式就不该动手改。
选择 3-5 个测试 prompt：
跑法：
如果在 Claude Code 中有 subagent 能力，为每个 prompt 启动一个 subagent，让它带着目标 skill 去执行任务。把输出保存到工作目录：
<skill-name>-evolve/
├── round-1/
│ ├── prompt-1/
│ │ ├── prompt.md # 原始 prompt
│ │ ├── output/ # skill 产出的文件
│ │ └── transcript.md # 执行过程记录（如果可获取）
│ ├── prompt-2/
│ └── ...
如果没有 subagent 能力（比如在 Claude.ai），就自己读取 skill 然后按 skill 的指令执行每个 prompt，把结果存下来。
OTF 要求：每跑完一个 prompt，立即记录观察。 不要等全部跑完再回头看。写到 round-1/observations.md：
## Prompt 1: [简述]
- 结果：[好/一般/差]
- 具体问题：[描述]
- 猜测原因：[指向 skill 中的哪段指令]
## Prompt 2: [简述]
...
这是最关键的一步。不要逐个修 bug，要找共性。
回顾所有 prompt 的观察记录，问自己：
产出：错误模式表，写到 round-1/patterns.md：
# 错误模式表 — Round 1
## P01: [模式名称]
- 出现次数：N 次（prompt 1, 3, 5）
- 表现：[用户看到了什么问题]
- 根因：[skill 中的哪段指令导致的]
- 影响面：[高/中/低]
## P02: [模式名称]
...
## 本轮改进优先级
1. P0x — [理由]
2. P0x — [理由]
压缩比意识：如果你有 5 个 prompt、发现了 8 个具体问题，但只提炼出 2 条模式——这很正常也很好。2 条模式比 8 个补丁更有价值，因为模式能覆盖未来的新 prompt。
绝对不要一次性重写整个 skill。
从错误模式表中取优先级最高的 1-2 个模式，针对性改写。改写时遵循：
JIT 三原则：
改写注意事项：
scripts/ 下的脚本。改写后立即保存改写笔记到 round-1/changes.md：
# 改写记录 — Round 1
## 目标模式
- P01: [模式名]
- P02: [模式名]
## 改动清单
1. [文件:行号] 改了什么，为什么
2. ...
## 预期效果
- Prompt 1 应该不再出现 [具体问题]
- Prompt 3 应该 [具体改善]
用同一批 prompt 重跑改进后的 skill。对比前后结果。
收敛判断标准：
| 信号 | 含义 |
|---|---|
| 目标模式的问题消失了 | 改进有效，进入下一轮处理剩余模式 |
| 目标模式的问题减轻但没消失 | 改进方向对但力度不够，同一模式再改一轮 |
| 出现了新问题 | 改动引入了副作用，需要回滚或调整 |
| 新模式数 = 0，连续两轮 | 收敛完成，skill 已达到当前测试集下的质量上限 |
| 修正量指数衰减（如 8→3→1） | 正常收敛曲线，继续迭代 |
| 修正量不降反升 | 有系统性问题被遗漏，回到第三步重新分析 |
验证通过后，更新工作目录进入 round-2/，重复第二到第五步。
每一轮的 observations.md、patterns.md、changes.md 不是用完就扔的草稿纸。它们是下一轮改进的上下文。
Round 2 开始时，先读 Round 1 的全部笔记。 这样你不会重复已解决的问题，能直接聚焦新暴露的模式。
当你积累了 3 轮以上的改进笔记，做一次递归压缩：
Round 1-3 的所有 observations（15+ 个具体问题）
↓ 压缩
5-8 条错误模式
↓ 压缩
2-3 条改进原则（这个 skill 最核心的"坑"是什么）
↓ 压缩
1 条洞察（这个 skill 的本质问题是什么）
把压缩结果写到 evolution-log.md（放在工作目录根下）。这份日志是整个改进过程的"记忆"，如果未来需要再次改进这个 skill，从这里开始而不是从零开始。
用户说"可以了"——停。 连续两轮没有新模式——停。 用户开始说"差不多了"、"够用了"——停。
不要追求完美。60% → 90% 的投入产出比远高于 90% → 95%。JIT 的精神是"够用就交付"。
改进完成后，交付给用户：
不是每次都需要完整五步循环。如果用户带着一个具体问题来（"这个 skill 生成的格式不对"、"它总是漏掉 X 步骤"），可以走快速路径：
快速模式适用于：问题明确、改动局部、不涉及 skill 整体架构。如果快速改完用户还不满意，再切到完整循环。
这时候不是 skill-evolve 的场景，而是 skill-creator 的场景。建议用户先用 /skill-creator 创建一个初版，再用 /evolve 迭代改进。
两者可以串联：先 /skill-creator 出初版，再 /evolve 持续打磨。
这是最好的起点。一个真实的失败案例 = 一个免费的测试 prompt。从这个案例开始，补充 2-3 个相关 prompt，直接进入第二步。
如果观察发现 skill 该触发时不触发，或不该触发时触发了，这是 description 的问题。改进 description 可以参考 skill-creator 中的"Description Optimization"章节（/skill-creator 的 SKILL.md 中有详细流程）。skill-evolve 聚焦于 skill 被触发后的执行质量。
可能的原因：
每轮改进前，过一遍这个清单：