用途
Test-Driven Development (TDD) 是一套用于指导开发过程的技能，其核心目标是让代码在编写之前先由测试定义行为。它适用于新功能开发、缺陷修复、重构以及行为变更等场景。文档明确指出，除一次性原型、生成代码和配置文件等例外情况（需征得人类伙伴同意）外，应始终使用 TDD。
主要能力
该技能提供了一套完整的 TDD 执行框架，包括：
- 铁律：没有失败的测试，就不写生产代码。若先写了代码，必须删除并从头开始，不得保留作为“参考”、不得在写测试时“改编”、不得查看。
- 红-绿-重构循环：
- RED：编写一个最小测试，展示期望的行为。要求测试名称清晰、测试真实行为、只测一件事。
- 验证 RED：必须运行测试并亲眼看到它失败，确认失败原因是功能缺失而非拼写错误等。若测试直接通过，说明测试的是已有行为，需修正测试。
- GREEN：编写最简单、刚好能通过测试的代码，不添加额外功能、不重构其他代码。
- 验证 GREEN：必须运行测试并确认通过，同时其他测试仍通过，输出干净无错误警告。若失败，应修代码而非改测试。
- REFACTOR：仅在绿灯后进行，消除重复、改进命名、抽取辅助函数，保持测试通过，不添加新行为。
- 好测试的标准：最小化（一个测试只测一件事，名称中出现“and”就应拆分）、清晰（名称描述行为）、展示意图（演示期望的 API）。
- 顺序的重要性：文档详细反驳了“先写代码后补测试”的常见理由，指出后补测试会立即通过，无法证明测试有效，可能测错对象、测实现而非行为、遗漏边界情况。
- 常见借口与反驳：以表格形式列出“太简单不用测”“我稍后测”“已经手动测过”“删除几小时工作太浪费”“TDD 太教条”等借口，并逐一给出反驳。
- 红旗信号：列出代码先于测试、测试立即通过、无法解释测试为何失败、合理化“就这一次”等信号，出现即应删除代码重新开始。
- 验证清单：在标记工作完成前，需逐项检查每个新函数/方法都有测试、亲眼看到每个测试失败、失败原因符合预期、编写了最小代码、所有测试通过、输出干净、使用真实代码（仅在不可避免时使用 mock）、覆盖边界和错误情况。
- 遇到困难时的建议：如不知道如何测试，可先写期望的 API 和断言；测试太复杂说明设计太复杂，应简化接口；必须 mock 一切说明代码耦合过紧，应使用依赖注入；测试设置庞大应抽取辅助函数或简化设计。
- 调试集成：发现缺陷时，先写一个能复现该缺陷的失败测试，再遵循 TDD 循环，测试既能证明修复又能防止回归。
使用方式
该技能以文档形式提供，包含 TypeScript 测试代码示例、npm 测试命令、mermaid 流程图以及对比表格。使用者需按照红-绿-重构循环逐步执行，并在每一步进行强制验证。文档强调，违反规则的字面要求就是违反规则的精神。
适用场景
适用于任何需要编写生产代码的软件开发场景，尤其是新功能、缺陷修复、重构和行为变更。不适用于一次性原型、生成代码和配置文件（需人类伙伴同意）。
限制
文档未提供关于该技能的具体安装方式、平台支持、收费模式或集成工具的信息，这些内容暂未提供。