用途：该技能用于指导实现任何功能或修复缺陷时的开发流程，要求在编写实现代码之前先写测试，并严格遵循“红—绿—重构”循环。核心原则是：没有先看到测试失败，就不知道测试是否测对了东西。
主要能力与流程：
- RED：写一个最小测试，展示期望行为；要求单一行为、命名清晰、尽量使用真实代码（除非不可避免才用 mock）。
- 验证 RED：必须运行测试并观察其失败，确认失败原因是功能缺失而非拼写错误；若测试直接通过，说明测的是既有行为，需修正测试。
- GREEN：编写最简单代码让测试通过，不添加额外功能或提前重构。
- 验证 GREEN：必须运行测试，确认通过且其他测试仍通过、输出无错误与警告；若失败应修代码而非改测试。
- REFACTOR：仅在绿灯后进行，去除重复、改善命名、抽取辅助方法，保持测试绿色且不新增行为。然后进入下一个失败测试。
铁律与限制：没有失败测试就不允许写生产代码；若先写了代码，必须删除并重新从测试开始，不得保留作“参考”、不得边写测试边“改编”，删除就是删除。例外情况仅限一次性原型、生成代码与配置文件，且需询问人类搭档。
适用场景：新功能、缺陷修复、重构、行为变更；也用于集成调试——发现缺陷时先写复现该缺陷的失败测试，再按 TDD 循环修复，从而证明修复有效并防止回归。
反模式与红旗：先写代码后补测试、测试立即通过、无法解释测试为何失败、以“只这一次”“已经手工测过”“删掉太浪费”“TDD 太教条”等理由合理化跳过，均意味着应删除代码重新开始。测试副作用过多、必须 mock 一切、测试设置过大，通常提示设计耦合或接口复杂，应简化设计或使用依赖注入。
完成前检查：每个新函数或方法都有测试；每个测试在实现前都被观察为失败且失败原因符合预期；只写最小通过代码；全部测试通过；输出干净；尽量使用真实代码；覆盖边界与错误情况。无法全部勾选即表示跳过了 TDD，应重新开始。