Superpowers 系列（九）：方法自举
一个流程系统最怕两件事：第一，规则永远停留在一次经验总结；第二，规则越写越多，却不知道它们是否真的改变了 Agent 行为。
writing-skills 是 Superpowers 里最有元方法价值的部分。它把 Skill 写作本身设计成 TDD：先观察没有 Skill 时 Agent 会怎样失败，再写规则，再验证规则是否改变行为。writing-skills/SKILL.md 的重点不是生成一份说明文档，而是让新 Skill 能被发现、能被执行、能被压力场景验证。
Skill 不是经验故事，而是行为补丁
writing-skills 对 Skill 的定义很清楚：Skill 是可复用技术、模式、工具或参考指南，不是一次问题解决过程的叙事。
这背后有一个重要边界。经验故事回答“我上次怎么做”；行为补丁回答“未来 Agent 在什么情况下应该改变默认动作”。只有后者才能成为工程系统的一部分。
所以一个好的 Skill 应该从失败模式出发：
- Agent 在什么场景会犯错；
- 它会用什么理由跳过规则；
- 哪个规则能最小化地阻止这个错误；
- 如何验证 Agent 真的不再犯这个错。
用 TDD 写 Skill 的真正含义
writing-skills 把 TDD 映射到 Skill 创作。
| TDD 概念 | Skill 创作 |
|---|---|
| 测试用例 | 压力场景 |
| 生产代码 | SKILL.md |
| RED | 没有 Skill 时 Agent 违反规则 |
| GREEN | 有 Skill 后 Agent 遵守规则 |
| Refactor | 关闭新发现的绕过方式 |
这个映射决定了 Skill 是否可验证。它要求流程规则不是凭感觉写出来，而是从真实失败中长出来。
如果你没有看见 Agent 在没有 Skill 时怎样失败，你就不知道 Skill 应该教什么。如果你没有验证 Agent 在有 Skill 后怎样变化，你也不知道 Skill 是否有效。
description 是发现入口，不是流程摘要
writing-skills 里一个很细但很深的点，是 description 不能摘要 workflow，只能写触发条件。
原因是 Agent 可能会偷懒。它看到 description 里写了“执行计划时每个任务做 code review”，就可能只做一次 review，而不再读取正文里真正要求的两阶段审查或完整循环。
这说明 Skill 设计里有一个“发现和执行分离”的原则：
- description 负责让 Agent 找到 Skill；
- Skill 正文负责控制行为；
- 复杂细节放到引用文件或脚本；
- 强制子技能用显式 REQUIRED 标记，而不是用含糊链接。
这个原则对任何 AI 流程文档都成立。入口摘要越像流程，Agent 越容易用摘要代替流程。
Red Flags 和 rationalization table 是抗绕过结构
普通文档会写“请不要跳过测试”。Superpowers 更常见的写法是列出 Agent 会说服自己的具体念头，比如“这个太简单”“我先做这一次”“测试之后补也一样”“我已经手动验证过”。
这类表格的价值不是教育人类，而是拦截模型的自我合理化。Agent 不是不知道规则，而是在具体压力下会生成跳过规则的理由。规则如果不处理这些理由，就很容易被语言绕过去。
方法论自举的价值
Superpowers 的特别之处在于，它不只提供一组 Skill，还提供“怎样继续写 Skill”的方法。也就是说，方法论本身也在方法论里接受约束。
每次发现 Agent 有新的失败模式，都不应该只补一句“下次注意”。更好的做法是写成一个小型规则测试：
失败场景：Agent 看到 description 后跳过 Skill 正文
RED：没有规则时，Agent 只按 description 摘要执行
GREEN：description 只写触发条件后，Agent 读取正文
Refactor：补充新的绕过理由和压力场景这样 Skill 就不只是说明书，而是可验证行为补丁。writing-skills 给出的最大启发，正是把方法论自身也纳入工程化闭环。
参考资料：
系列导航：