用途：在实现任何功能或修复 Bug 之前，先编写失败测试，再写最小实现代码使其通过，适用于新功能、Bug 修复、重构和行为变更；一次性原型、生成代码和配置文件等例外需征得人类合作者同意。
主要能力：给出完整 TDD 流程规范。铁律是“没有预先失败的测试就不写生产代码”。核心循环为 RED（写一个最小失败测试）→验证失败（必须亲自看到失败，且失败原因符合预期，而非报错或笔误）→GREEN（写最简单代码通过）→验证通过（其他测试仍通过、输出无警告无错误）→REFACTOR（在保持绿色前提下消除重复、改善命名、提取辅助函数，不新增行为）→重复下一轮。
必要用法：先跑测试确认失败，例如 npm test path/to/test.test.ts；实现后再跑同一命令确认通过。测试应一次只验证一个行为、名称清晰、测试真实代码，除非不可避免否则不用 mock。Bug 修复时先写复现该 Bug 的失败测试，再按循环修复，测试同时证明修复有效并防止回归。加入 mock 或测试工具时需阅读 @testing-anti-patterns.md，避免测试 mock 行为而非真实行为等反模式。
限制与边界：文档列出大量常见自我合理化说辞（如“太简单不用测”“稍后补测试”“已手工测过”“删掉几小时代码太浪费”等），并主张一律删除先写的代码、从测试重新开始。完成前需核对清单：每个新函数都有测试、每测试都先被看到失败且原因正确、实现最小化、全部通过、输出干净、尽量用真实代码、覆盖边界与错误。无法勾选全部即视为跳过了 TDD，需重来。资料未提供具体安装命令、支持语言范围、收费或价格信息。