用途：当用户想以 TDD 方式开发功能或修复缺陷，或提到“红-绿-重构”时使用。核心原则是测试通过公共接口验证行为，而非实现细节；代码可以完全重写，测试应保持稳定。好的测试是集成式的，走真实代码路径，像规格说明一样描述系统能做什么；坏的测试耦合内部实现、mock 内部协作者或直接查数据库，重构即失败。
明确反对“水平切片”：不要先写完所有测试再写所有实现。正确做法是垂直切片与追踪弹：一个测试→一个实现→重复。每个测试根据上一轮学到的东西编写。
工作流：1）规划。探索代码库时使用项目领域词汇，尊重相关 ADR；写代码前与用户确认接口变更、优先测试哪些行为、识别深模块机会、设计可测试接口、列出要测试的行为并获批准，可问“公共接口应是什么样？哪些行为最重要？”。2）追踪弹。写一个测试确认一件事：RED 写首个行为测试并失败，GREEN 写最少代码使其通过。3）增量循环。对每个剩余行为重复：RED 写下一个测试并失败，GREEN 写最少代码通过；一次一个测试，只写够通过当前测试的代码，不预判未来测试，聚焦可观察行为。4）重构。全部通过后，抽取重复、深化模块、应用 SOLID、审视新代码揭示的问题，每步重构后运行测试；绝不在 RED 状态下重构，先到 GREEN。
每轮检查：测试描述行为而非实现；只用公共接口；能经受内部重构；代码对当前测试最小；不添加推测性功能。资料提及 tests.md 和 mocking.md 作为示例与 mock 指南，但未提供具体内容；未提供安装命令、平台、收费或价格信息。