测试驱动开发的重点，不是让 Agent 最后补上一组会通过的测试，而是在实现前明确新行为怎样被证明。这个 Skill 围绕红、绿、重构的循环工作，适合输入输出清楚的功能规则，也适合给已知缺陷补回归覆盖。
安装并开始
在 Claude Code 会话内运行下面的插件命令，安装整套 Superpowers，保留各技能之间的衔接。Codex 用户在插件界面搜索并安装 Superpowers；两个客户端需要分别安装。安装后开启新会话，在项目目录里明确提出使用 test-driven-development，再交代任务范围。
/plugin install superpowers@claude-plugins-official
先选一个可以观察的行为
以下是可按项目调整的首次输入：
使用 Superpowers test-driven-development，为现有优惠码校验增加“过期不能使用”的规则。先确认当前测试框架和时间处理方式，写一个明确失败的行为测试，确认失败原因后做最小实现；最后检查边界日期与既有有效优惠码，不重写无关模块。
把需求缩小到一条规则，例如“过期优惠码应返回明确错误”，并说明日期边界如何定义。Agent 应先看项目已有测试风格、构造数据的方法和时间依赖，不要为了示例引入另一套测试工具。如果规则本身还未决定，先澄清再写断言。
红色必须来自缺少的行为
写出最小测试后，实际运行并阅读失败原因。模块导入错误、拼写错误或环境未配置，并不能证明这个测试抓住了待实现规则。测试直接通过时，也要弄清行为是否已经存在、断言是否过弱，而不是为制造红色删掉有效代码。
然后写足够让测试通过的实现。不要顺便添加尚未要求的参数、缓存或通用框架；每增加一种行为，就需要新的例子说明它。真实代码路径通常比只检查 mock 被调用更能证明结果，替身应局限于必要的外部边界。
在绿色时整理实现
新测试和相关旧测试通过后，再调整命名、提取重复或改善结构，并保持测试持续通过。优惠码例子需要特别检查边界时刻、无过期日期和仍有效的旧场景，避免新规则把已有正常流程拒绝掉。测试套件已有失败时，应把基线问题单独列出。
这一轮的产物应包括行为测试、最小实现和实际执行结果，而不是一句“按 TDD 完成”。上游对先写实现再补测试的做法要求很严格，开始前应让 Agent 知道哪些代码是已存在的用户工作，避免把流程要求误用成清理现有成果。
原型、配置或难以自动观察的界面任务，未必适合照搬同样的测试粒度。可以先明确验证方式与例外，再采用合适流程。测试通过只覆盖已表达的行为；断言是否对应真实需求，仍是审阅时最重要的问题。
再做一个权限边界例子
假设需求是“只有订单所属组织的成员可以下载发票”。先列出可观察的最小行为：同组织成员成功，不同组织成员被拒绝，订单不存在仍按项目约定返回结果。第一轮只写“不同组织被拒绝”这一个测试，用当前项目的身份与订单夹具运行，确认失败确实来自缺少组织校验，而不是登录配置或测试数据库没启动。之后在实际下载入口加最小权限检查，确认红变绿，再补正常成员用例。
重构阶段检查是否把权限逻辑放在统一入口，而不是仅在界面隐藏下载按钮。若后台还有批量下载接口，需为它另写用例；一个按钮测试不能证明所有路径都安全。测试替身适合隔离外部发票存储，但不要只断言“权限函数调用过”，仍要检查最终返回状态或文件是否可取得。每一轮保留运行命令和失败、通过的输出，后续审阅者才能确认顺序与行为。
测试套件本身也是交付物时
先分清这次交付的是功能还是测试基础设施。若任务本身是建立验收测试目录，尚未实现的行为测试可以保持红灯，但运行器、fixture 和测试 DSL 也是代码，仍要验证其自身正确性。一个长期使用者的项目里，检测器的小单测全绿，完整 HTTP 轨迹却暴露组合输入下的失效。为关键规则加一条贴近真实请求的复合样本，确认测试确实识别失败；暂缓实现的断言要留有明确标记和负责人，不能为了让 CI 变绿直接删掉。