先约定测试观察的位置，再循环编写一个失败测试与最小实现，让测试围绕用户行为。
安装与准备
在项目目录的终端执行以下命令，安装后在 Claude Code 中输入下方提示。这里选择项目内的可编辑文件安装。
npx skills@latest add mattpocock/skills --skill tdd --skill codebase-design --agent claude-code
使用 Codex 时，把安装命令最后的 claude-code 换成 codex，对话里把 /tdd 换成 $tdd。如果使用完整的 Claude Code 插件，则选择 /mattpocock-skills:tdd，不要再重复安装文件版本。
准备可执行的测试命令和一个明确行为。一起安装 codebase-design，供讨论接口和测试边界时使用；现有 CONTEXT.md 和 ADR 也应提供。
第一次使用
把下面的场景和路径替换成你的项目情况，在 Agent 对话里输入：
/tdd
为购物车优惠券增加“满100减10”的规则。金额以分存储。请先解释可选测试边界及各自覆盖范围，等我确认后，每次只写一个失败测试和对应实现。
怎样推进任务
先选观察业务行为的位置
测试可以从购物车公共接口观察折扣，也可以从结算接口观察最终应付额。让 Agent 解释前者可能漏掉怎样的集成错误、后者需要哪些环境，再决定本次采用哪一个。测试边界决定这次验证的实际价值。
用独立答案启动第一轮
从一个简单已知样例开始，例如 10000 分小计应该减去 1000 分。期望结果来自业务规则，而不是在测试里再写一遍生产代码的算法。先运行并看到失败，再补充让这一条通过的实现。
沿真实边界逐步补齐
接下来讨论刚好不足门槛、重复使用、与其他优惠组合等实际要求，逐条进入循环。不要一次把所有设想中的测试都写好，也不要为了每个内部函数存在而添加测试；重命名内部函数不应破坏行为不变的测试。
完成后检查什么
检查每个测试是否经历过真实失败、断言是否来自独立规则、Mock 是否只放在外部依赖。当前版本把重构交给后续审查阶段，可以在行为稳定后安排 code-review。
常见问题
为什么先问测试边界？ 这是本 Skill 的必要选择；如果术语难懂，让 Agent 用“能发现什么、会漏什么”解释。
为什么没有自动重构？ 当前正文采用 red → green 循环，重构放在 review。
改一行配置也值得用吗？ 优先用于有明确输入输出和独立验收标准的行为。
给运费规则安排一条红到绿路径
与优惠券不同，可以先选“购物车满额免运费”的行为。输入：“用 tdd 在订单对外计算接口验证：商品小计为 9,900 分时仍收运费，10,000 分时免运费。先提议测试边界并等我确认；每次只写一条会因缺少规则而失败的测试，再补最少实现。”预期金额由产品规则直接给出，不要在测试里调用生产计算函数来构造答案。
第一条绿后再加折扣后金额、免费商品或币种等已决定的边界。若 Agent 一次生成十条测试却全是绿的，先检查它们是否真的揭露了新行为；若内部重命名就让整套测试失败，说明测试贴到了私有实现。没有现成可观察边界时先讨论接口，而不是为了写测试强行 Mock 项目自己的模块。
边界输入也是测试决策
在同意测试边界时，不只写“核心路径”。把至少一个会改变判断的边界输入列出来，例如零金额、重复请求、缺少权限或并发更新；先证明测试在错误实现上会红，再看修复后是否转绿。安装该 Skill 的一项外部评估反馈指出，遗漏边界条件会让测试全绿却仍交付错误行为。这个反馈没有公开完整复算材料，因此更适合作为选测试样本的提醒，而不是某个失败率的保证。