Test-Driven Development（测试驱动开发）
铁律：没有先写失败测试就不能写生产代码，写了也要删掉重来，不允许「补测试」
该技能明确面向新功能、缺陷修复、重构和行为变更，提供可复用的 RED-GREEN-REFACTOR 流程、测试质量标准和调试回归方法，对软件开发代理具有直接任务价值。边界也有说明，包括原型、生成代码和配置文件需询问人类伙伴，但“始终使用”仍可能不适合所有项目或测试成本场景。
流程步骤清晰且可重复：先写单一失败测试、确认失败原因、实现最小代码、确认全部测试通过、再重构。包含对测试错误、立即通过、其他测试失败和复杂 mock 的处理建议。证据缺口是依赖具体测试框架、项目命令和运行环境，主要示例使用 npm test、TypeScript、Jest/Vitest 风格，未提供跨语言或命令适配规则，也没有该技能自身的执行结果。
技能不要求网络访问、凭据、敏感数据或高权限工具，主要影响代码和测试流程，未发现恶意行为、隐蔽外传或凭据窃取。风险在于“代码先于测试就删除”“删除意味着删除”的强制指令可能造成未提交工作丢失；未说明备份、版本控制确认、恢复步骤或用户再次确认，因此对可逆性和最小破坏性的保障不足。
SKILL.md 提供了流程图、命令示例、正反测试示例、检查清单、反模式表和失败处理建议，能支持方法论主张。仓库 README 提到技能行为测试使用 drill eval harness，但提供的材料没有展示该选定技能的测试结果、覆盖范围或独立复核；示例和“更快、更可靠”等效果主张缺少量化数据，事实与推断未完全分离。
触发条件、核心输入（待实现行为或缺陷）和完成标准较明确，结构适合代理逐步执行，并提供“卡住时”的解决表。缺口包括未说明不同语言、测试运行器、单元测试与集成测试的选择，npm test 命令并非通用；也未明确测试耗时、资源成本、无法运行测试时的退出条件或如何向用户报告阻塞。
选定技能有名称和描述，仓库材料提供 MIT 许可、版本 6.1.1、修订版本和 README 中的更新及问题反馈渠道。未验证发布者身份，不能给予官方治理加分；技能文件自身没有版本、变更记录、负责人、兼容性矩阵或明确的更新责任和响应 SLA，因此维护可追溯性有限。
- 不要在未确认工作已提交、可恢复或经用户明确同意的情况下执行“删除先写代码”的规则；优先保留补丁、使用版本控制或创建恢复点。
- npm test、TypeScript 和特定 mock 约定不是通用接口；部署到其他语言、测试框架或无法运行测试的环境前，应补充适配和退出策略。
- README 对评估框架的描述不能替代该选定技能的实际测试结果；本评估未执行测试，不能把仓库测试基础设施视为独立验证。
它能做什么 & 适用场景
标准 RED-GREEN-REFACTOR 循环的严格版本，核心是「没有失败测试就不能写代码」这条铁律，并且明确规定如果真的先写了代码，唯一允许的处理方式是删掉重新开始——不能留着当参考、不能一边补测试一边偷看已写的实现。文档花了大量篇幅逐条反驳「补测试也一样」「我已经手动测过了」「删掉重写太浪费」这类常见借口，逐条说明为什么补测试不等于先写测试。
RED：写一个测试，说明期望行为，要求单一职责、命名清晰、尽量用真实代码而非 mock；验证 RED：跑一次确认测试确实失败，而且是因为功能缺失而不是拼写错误等无关原因；GREEN：写刚好能让测试通过的最简代码，不允许顺手加额外功能或参数；验证 GREEN：跑测试确认通过且没有连带破坏其他测试、输出干净无警告；REFACTOR：只在测试全绿之后做清理（去重复、改名字、抽取辅助函数），过程中保持测试始终为绿。附带一份「测试反模式」参考文档，讲如何避免测 mock 行为而不是测真实行为、往生产类里加仅测试用的方法等常见坑。
- 实现任何新功能或修 bug 前，先写一个描述期望行为的失败测试，跑一次确认它真的失败
- 已经手写了一段实现代码，按流程要求删掉、从测试开始重新做，而不是回头补测试
- 修复 bug 时先写一个复现该 bug 的失败测试，再按 RED-GREEN-REFACTOR 循环修复，同时预防未来回归
优缺点一览
- 对「测试写在代码之后是否算 TDD」这个团队里常有分歧的问题给出了明确且有论据的立场（测试后写只能证明「这是什么」，测试先写才能证明「应该是什么」），减少模糊地带
- 红绿重构三阶段都要求「验证」而不是「假设」，比如明确要求跑测试确认它确实失败、失败原因正确，而不是写完就默认它会失败
- 反模式参考文档单独拆出来，覆盖了「测 mock 行为」「往生产类塞测试专用方法」等真实常见的测试质量问题
- 只在会自动读取和遵循 SKILL.md 指令的 harness 里可靠工作（Claude Code、Codex CLI 等）；纯聊天式界面里等于一份说明文档，需要人工照做。
- 「必须删除已写代码重新开始」的要求非常严格，对已经写了大段代码、只是缺测试的场景，执行成本不低，需要团队认同这种严格程度才适合采用
- 对探索性原型、一次性脚本等场景，SKILL.md 本身也承认需要跟人协商例外，不是无条件适用
如何安装
作为 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 统一引导、按场景自动触发，无需单独调用。
如何使用
在实现任何功能或修复任何 bug、写生产代码之前自动触发；systematic-debugging 的 Phase 4（实施修复）明确要求调用这个 skill 来写复现测试。
对比同类
跟「写完代码再补测试」这种常见但更宽松的实践相比，这个 skill 的立场更接近经典 Kent Beck 式 TDD 的严格版本，牺牲了一些灵活性换取「测试真的验证过需求」的确定性；跟不写测试直接交付相比，价值不言而喻，取舍主要在于「是否接受删除重写已完成代码」这条硬性要求。