用途：该技能用于创建新技能、编辑现有技能，或在部署前验证技能是否有效。其核心主张是：编写技能就是把测试驱动开发（TDD）应用到流程文档上——先写测试用例（用子代理构造压力场景），观察失败（无技能时的基线行为），再写技能文档，观察测试通过（代理遵守），最后重构（堵住漏洞）。核心原则：如果没有先观察代理在没有该技能时失败，就无法确认技能教对了东西。
前置要求：使用前必须先理解 superpowers:test-driven-development，该技能定义了 RED-GREEN-REFACTOR 循环，本技能将其适配到文档。Anthropic 官方最佳实践见 anthropic-best-practices.md。
技能定义与类型：技能是针对已验证技术、模式或工具的参考指南，不是某次解决问题的叙事。类型包括技术（有步骤的具体方法）、模式（思考问题的方式）、参考（API、语法、工具文档）。
目录与结构：所有技能置于同一平铺命名空间，如 skills/skill-name/SKILL.md；需单独文件的仅限重型参考（100 行以上）或可复用工具。SKILL.md 前置元数据为 YAML，name 与 description 两个必填字段，总计不超过 1024 字符；name 仅用字母、数字和连字符；description 用第三人称、只描述“何时使用”而非“做什么”，以“Use when…”开头。
关键原则（CSO）：description 只写触发条件，不总结工作流，否则 Claude 可能只按 description 行动而不读正文。触发条件应使用具体症状与情境，保持技术无关，除非技能本身针对特定技术。命名用主动语态、动词开头。控制篇幅：入门工作流每个少于 150 词，高频加载技能总计少于 200 词，其他少于 500 词。引用其他技能用技能名加明确的“REQUIRED SUB-SKILL/BACKGROUND”标记，不使用 @ 强制加载。
流程图仅用于非显而易见的决策点、流程循环和“A 还是 B”的选择，参考类内容用表格，代码示例用代码块，线性指令用编号列表。代码示例只给一个完整可运行、有注释、来自真实场景的例子。
铁律：没有失败的测试就不写技能，新技能与对现有技能的编辑都适用；先写技能后测试则删除重来。不同技能类型用不同测试方式：纪律型测学术问题与多重压力下的合规；技术型测应用、变体与信息缺口；模式型测识别、应用与反例；参考型测检索、应用与覆盖缺口。常见跳过测试的借口及其反驳也已列出。防合理化部分要求明确封堵每个漏洞，例如“不要留作参考”“不要一边写测试一边改编”“删除就是删除”，并加入“违反规则的字面就是违反规则的精神”这一基础原则。