Writing Skills（撰写与测试 Skill 本身）
把 TDD 的红绿重构套用到「写 Skill 文档」这件事上：先用无 skill 基线测试暴露真实失败模式，再针对性写文档，而不是凭直觉写
为创建、编辑和部署前验证 Agent Skill 提供了明确的 TDD 映射、结构规范、发现优化、测试类型和反合理化方法，面向 Skill 作者及维护者，任务价值较高。边界也有说明，例如区分技术、模式和参考型 Skill；但内容主要是方法论，缺少适用于不同运行时的最小可执行示例和明确的适用限制。
流程具有较强的顺序性：先做 RED 基线，再写最小 Skill，随后 GREEN 和 REFACTOR，并要求压力场景、重复验证和记录合理化。可靠性仍有限，因为选定 Skill 没有提供可直接运行的测试实现、固定测试环境、模型矩阵结果或失败恢复方案；同时依赖未在本文件中定义的 superpowers:test-driven-development，可能导致跨环境复现不一致。
该 Skill 本身主要提供文档指导，没有网络、凭据、文件外传或高权限工具调用。安全不足在于它多次要求在测试前写代码时‘Delete it’并从头开始，且没有备份、恢复、用户确认或未提交工作保护措施；强制性的‘No exceptions’可能造成不必要的数据丢失。其外部影响通常限于代理工作区，但仍应谨慎处理。
文档给出了 TDD 映射、压力场景示例、成功标准和测试清单，具备一定可追溯性。证据缺口明显：没有附带实际 RED/GREEN/REFACTOR 运行记录、模型或版本、通过率原始数据、独立复核结果，也无法从静态材料确认‘100% compliance’等示例性或历史性主张。研究引用和官方指南主要作为外部背景，未在本评估中独立核验。
目录结构、frontmatter、文件拆分、引用深度、快速参考和测试步骤较完整，且配有示例文件、渲染脚本及压力场景模板。使用成本偏高：需要理解额外的 TDD Skill、准备 subagent/API 或测试 harness，并自行建立基线；没有清晰的输入输出契约、跨模型兼容性说明、故障排查和明确的停止/退出条件。frontmatter description 还描述了工作流，违反了正文要求的仅描述触发条件原则。
仓库材料显示 MIT 许可证和 package.json 版本 6.1.1，README 提供了贡献、测试和更新入口，具备部分维护信号。缺少该 Skill 自身的版本、变更记录、发布责任人、兼容性矩阵和明确的单 Skill 更新策略；发布者未通过 FollowSkills 企业注册表验证，因此不能将身份或品牌作为治理和可靠性证据。
- 不要在未备份或未获确认的情况下执行‘删除代码’规则；至少限定为可恢复的未提交工作，并提供恢复路径。
- 在部署前应自行运行并记录基线、GREEN、REFACTOR 和多模型测试；当前材料不能证明这些测试已实际完成。
- 确认 superpowers:test-driven-development 及所引用的辅助文件在目标运行时可访问，否则流程可能无法启动。
- 修正 description，使其只表达触发条件，不要在元数据中概述工作流。
它能做什么 & 适用场景
这是这批 skill 里篇幅最长（689 行）、也是唯一一个「用来写 skill 的 skill」。核心类比是：Skill 文档 = 生产代码，压力测试场景 = 测试用例，没有 skill 时 agent 违反规则 = RED，装上 skill 后 agent 照做 = GREEN，找新漏洞再补 = REFACTOR。要求写文档前先跑一次「不给 skill、看 agent 自然会怎么做」的基线测试，把实际出现的合理化借口原句记下来，再针对性地在文档里补上反驳，而不是凭经验先验地猜测 agent 可能会怎么钻空子。
先判断这个技巧是否值得写成 skill（不是一次性方案、以后会反复用到、适用范围够广）；描述字段（description）只能写「什么时候用」，不能写「怎么做」——文档举了一个实测案例：描述里一旦写了工作流摘要，agent 会直接照描述执行走捷径，跳过阅读文档主体的详细步骤；给出具体的目录结构规范、SDO（Skill Discovery Optimization，让未来的 agent 能搜到这个 skill）技巧、token 效率要求（高频加载的 skill 要控制在 150-200 词内）；核心的 RED-GREEN-REFACTOR 流程要求先跑压力场景基线测试、记录原始合理化借口、针对性写最小化的文档、再测试验证 agent 现在会遵守；还给出一张「问题类型 → 该用哪种文档形式」的对照表（比如「明知故犯」类问题该用禁止句式+反驳表，「输出形状不对」类问题该用给出正例模板而不是禁止清单，形式用反了实测效果会更差）。
- 发现一个值得沉淀的技巧或经验，判断是否值得专门写成一个新 skill，还是应该放进项目自己的说明文件里
- 已经写了一份 skill 文档，但发现 agent 遇到压力场景（时间紧张、沉没成本）时还是会绕过规则，需要按 RED-GREEN-REFACTOR 循环补漏洞
- 在给 skill 写 description 字段时，避免写成「工作流摘要」导致未来的 agent 只看描述走捷径、跳过阅读文档本体
优缺点一览
- 「先跑无 skill 基线测试、记录真实合理化借口」这个方法论本身是这个 skill 最有价值的部分——避免写文档时凭空想象 agent 会怎么钻空子，而是基于观察到的真实行为
- 「问题类型决定文档形式」这张对照表给出了实测依据（提到「禁止式」表述在某些场景下测试表现甚至不如完全不给指导），比泛泛的写作建议更有说服力
- 对 description 字段「只能写触发条件、不能写流程摘要」的规则给出了具体的失败案例复现，解释非常具体，不是空泛断言
- 只在会自动读取和遵循 SKILL.md 指令的 harness 里可靠工作（Claude Code、Codex CLI 等）；纯聊天式界面里等于一份说明文档，需要人工照做。
- 689 行是这批里最长的一份，且要求的是「用子代理跑多轮压力测试」这种本身就需要额外资源投入的验证流程，个人或小团队采纳的门槛不低
- 这套方法论假设你有能力批量派发压力测试子代理来验证文档效果，对没有子代理调度能力的使用者，RED-GREEN-REFACTOR 环节很难真正落地，退化成只能凭经验写文档
如何安装
作为 obra/superpowers 插件的一部分安装，不能单独安装某一个 skill：
- Claude Code：官方市场
/plugin install superpowers@claude-plugins-official；或先注册 Superpowers 自建市场/plugin marketplace add obra/superpowers-marketplace，再/plugin install superpowers@superpowers-marketplace - 也支持 Antigravity、Codex App/CLI、Cursor、Factory Droid、GitHub Copilot CLI、Kimi Code、OpenCode、Pi 等 harness，具体命令见仓库 README
装好后这个 skill 会和其余 13 个 Superpowers skill 一起启用，由 using-superpowers 统一引导、按场景自动触发，无需单独调用。
如何使用
在创建新 skill、修改已有 skill、或者在正式使用前想验证一个 skill 是否真的有效时触发；要求先理解 test-driven-development 这个前置 skill，因为整套方法论是它的迁移应用。
对比同类
跟凭经验直接写一份 SKILL.md、不做任何验证相比，这个 skill 提供了一套可操作的验证方法（基线测试→记录真实失败模式→针对性文档→复测），理论上能显著降低「写了但没用」的风险；跟其余 13 个面向具体开发环节的 Superpowers skill 不同，这一个是元层面的——它教你怎么写好其余那些 skill，脱离 Superpowers 体系单独使用价值有限。