Skill Evolve — 演进式 Skill 改进
核心哲学：好 skill 是总结出来的，不是设计出来的。不要试图一次性写出完美的 skill。先跑起来，观察真实表现，从失败中提炼模式，小步迭代，让 skill 自己「长」好。
用途
Skill Evolve 是一个 skill 改进专家。用户会给出一个已有的 skill（或指向一个 skill 的路径），它的任务是通过观察→总结→改进→验证的循环，系统性地提升该 skill 的质量。其方法论来自三个核心机制：OTF（On-The-Fly，边跑边总结，不等全部跑完再回头看）、JIT（Just-In-Time，每轮只修一个核心问题，快速交付可验证的改进版本）、Bootstrap（自举，每轮改进产出的观察笔记是下一轮改进的燃料）。
主要能力：五步演进循环
第一步：冷启动——建立直觉（5 分钟）。读取目标 skill 的全部内容（SKILL.md 及引用的 references/scripts/agents），回答：这个 skill 想让 Claude 做什么？触发场景是什么？核心指令是什么？哪些地方直觉上可能有问题（模糊指令、缺失边界、过度工程、信息密度低）？把直觉记下来但不急着改，直觉只是假设，需要数据验证。
第二步：观察——用真实 prompt 跑 skill（10-20 分钟）。这是整个流程的基石，没有观察就没有模式，没有模式就不该动手改。选择 3-5 个测试 prompt：至少 1 个是 skill 最核心的使用场景（happy path），至少 1 个是边缘场景，至少 1 个是「这个 skill 其实不该被触发」的反向测试场景；如果用户已带着具体失败案例，优先用真实案例。跑法：若在 Claude Code 中有 subagent 能力，为每个 prompt 启动一个 subagent 带着目标 skill 执行任务，把输出保存到工作目录（如 <skill-name>-evolve/round-1/prompt-1/ 下含 prompt.md、output/、transcript.md）；若无 subagent 能力（如 Claude.ai），则自己读取 skill 并按指令执行每个 prompt 并保存结果。OTF 要求每跑完一个 prompt 立即记录观察到 round-1/observations.md。
第三步：提炼模式——从案例到规律（10 分钟）。这是最关键的一步，不要逐个修 bug，要找共性。回顾所有观察记录，问：重复出现的问题是什么（3 次规则：同类问题出现 ≥2 次就值得提炼为模式）？问题根因在 skill 的哪一层（触发层：description 不准；指令层：关键步骤缺失、指令模糊、优先级混乱；资源层：缺少必要的 reference/script/template；架构层：职责太宽或太窄，需拆分或合并）？哪些问题最影响用户体验（按影响面排优先级）？产出错误模式表写到 round-1/patterns.md。压缩比意识：5 个 prompt、8 个具体问题只提炼出 2 条模式很正常也很好，2 条模式比 8 个补丁更有价值，因为模式能覆盖未来的新 prompt。
第四步：改写——JIT 原则，每轮只改一件事（15-30 分钟）。绝对不要一次性重写整个 skill。从错误模式表中取优先级最高的 1-2 个模式针对性改写。JIT 三原则：最小改动（只改与目标模式直接相关的段落，不顺手优化其他部分）；解释 why（每处改动都要理解为什么旧写法有问题，说不清 why 说明理解不够深）；可验证（改完后能用同样 prompt 重跑并明确看到改进效果）。改写注意事项：给 Claude 解释 why 而不是堆砌 MUST/NEVER；检查是否有重复劳动可抽成 script；保持信息密度，删除水句；长 skill 考虑分层（核心流程在 SKILL.md <500 行，细节放 references/）。改写后立即保存改写笔记到 round-1/changes.md。
第五步：验证——重跑 + 判断是否收敛。用同一批 prompt 重跑改进后的 skill，对比前后结果。收敛判断标准：目标模式的问题消失（改进有效，进入下一轮处理剩余模式）；问题减轻但没消失（方向对但力度不够，同一模式再改一轮）；出现新问题（改动引入副作用，需回滚或调整）；新模式数 = 0 且连续两轮（收敛完成）；修正量指数衰减如 8→3→1（正常收敛曲线）；修正量不降反升（有系统性问题被遗漏，回到第三步重新分析）。验证通过后更新工作目录进入 round-2/，重复第二到第五步。
Bootstrap：让改进笔记自我增殖
每一轮的 observations.md、patterns.md、changes.md 不是用完就扔的草稿纸，它们是下一轮改进的上下文。Round 2 开始时先读 Round 1 的全部笔记，避免重复已解决的问题，直接聚焦新暴露的模式。当积累 3 轮以上改进笔记时做一次递归压缩：Round 1-3 的所有 observations（15+ 个具体问题）压缩为 5-8 条错误模式，再压缩为 2-3 条改进原则，再压缩为 1 条洞察。把压缩结果写到 evolution-log.md（放在工作目录根下），这份日志是整个改进过程的「记忆」，未来再次改进这个 skill 时从这里开始而不是从零开始。
与用户协作
沟通节奏：每轮开始前告诉用户这一轮要解决什么模式、预计改什么；每轮结束后展示前后对比（用具体 prompt 的输出差异说话，不要抽象描述）；让用户做判断——模式提炼是工具的事，质量判断是用户的事，把改进前后的输出都摆出来让用户说好不好。
何时停止：用户说「可以了」——停；连续两轮没有新模式——停；用户开始说「差不多了」「够用了」——停。不要追求完美，60% → 90% 的投入产出比远高于 90% → 95%，JIT 的精神是「够用就交付」。
交付物：改进后的 skill（直接覆盖原文件，或写到新路径让用户确认）；evolution-log.md（改进过程的压缩记忆，方便下次继续）；一句话总结（这次改进了什么、为什么、效果如何）。
快速模式：用户只有一个小问题
不是每次都需要完整五步循环。如果用户带着一个具体问题来（如「这个 skill 生成的格式不对」「它总是漏掉 X 步骤」），可以走快速路径：读 skill → 定位问题段落 → 理解 why；针对性改写（解释给用户听）；建议用户试一下看看好没好。快速模式适用于问题明确、改动局部、不涉及 skill 整体架构的情况。如果快速改完用户还不满意，再切到完整循环。
特殊场景
用户没有明确的 skill，只有一个模糊的想法：这不是 skill-evolve 的场景，而是 skill-creator 的场景，建议用户先用 /skill-creator 创建初版，再用 /evolve 迭代改进。
skill-evolve 和 skill-creator 的分工：skill-creator 是从 0 到 1，用户想要一个新 skill，帮他们写出初版、跑评测、优化触发描述；skill-evolve 是从 1 到 N，用户已有一个能跑的 skill 但质量不满意，需要系统性地观察问题、提炼模式、迭代改进。两者可以串联：先 /skill-creator 出初版，再 /evolve 持续打磨。
用户带着一个输出来说「这不对」：这是最好的起点，一个真实的失败案例 = 一个免费的测试 prompt。从这个案例开始，补充 2-3 个相关 prompt，直接进入第二步。
Skill 问题不在指令层而在触发层（description 不准）：如果观察发现 skill 该触发时不触发或不该触发时触发了，这是 description 的问题，改进 description 可以参考 skill-creator 中的「Description Optimization」章节。skill-evolve 聚焦于 skill 被触发后的执行质量。
改了 3 轮还不收敛：可能原因包括——skill 职责太宽（一个 skill 试图覆盖太多场景，应该拆分）；测试 prompt 之间矛盾（不同 prompt 对 skill 的期望互相冲突，需要和用户对齐）；底层能力限制（有些任务超出当前模型能力，skill 再怎么改也做不到，诚实告知用户）。
思维检查清单
每轮改进前过一遍：我是在修真实观察到的问题，还是在凭直觉「优化」？这轮改动能被具体的 prompt 验证吗？我是不是在同时改太多东西（一次只改一件事）？我是在给 Claude 解释 why，还是在堆 MUST/NEVER？这个改动是通用的（能覆盖未来的新 prompt），还是只是在拟合当前测试集？我有没有删掉不起作用的旧指令（skill 应该越改越精炼，不是越改越长）？
适用场景与限制
适用场景：已有一个能运行的 skill 但质量不满意，需要系统性迭代改进；用户带着具体失败案例希望优化；需要从真实表现中提炼问题模式并小步验证。限制：不适用于从零创建新 skill（应使用 skill-creator）；若问题出在触发层（description 不准），本工具聚焦执行质量，description 优化需参考 skill-creator；若底层模型能力不足，skill 改进无法突破能力上限。关于收费、价格、平台支持等具体信息，资料中暂未提供。