用途
该技能用于按严格的测试驱动开发（TDD）流程推进开发工作，适用于涉及 TDD 工作流、TDD 周期的任务，或需要相关指导、最佳实践与检查清单的场景。若任务与 TDD 工作流、TDD 周期无关，或属于该范围之外的领域与工具，则不应使用本技能。
主要能力
技能定义了一套完整的 TDD 工作流，核心是强制「红-绿-重构」（RED-GREEN-REFACTOR）纪律，并通过协调的智能体编排在每一个阶段严格执行失败优先验证、增量实现与持续重构。支持单测试方式与测试套件方式，并带有可配置的覆盖率阈值。
配置项包括：
覆盖率阈值
- 最低行覆盖率：80%
- 最低分支覆盖率：75%
- 关键路径覆盖率：100%
重构触发条件
- 圈复杂度 > 10
- 方法长度 > 20 行
- 类长度 > 200 行
- 重复代码块 > 3 行
使用方式
工作流按阶段推进，每个阶段使用指定的 Task 工具与子智能体类型（subagent_type），以 $ARGUMENTS 作为任务输入。
阶段 1：测试规格与设计
- 需求分析：使用 comprehensive-review::architect-review，分析需求、定义验收标准、识别边界情况并创建测试场景，输出测试规格、验收标准与边界情况矩阵；验证所有需求都有对应测试场景。
- 测试架构设计：使用 unit-testing::test-automator，基于测试规格设计测试架构，定义测试结构、夹具、mock 与测试数据策略，确保可测试性与可维护性；验证架构支持隔离、快速、可靠的测试。
阶段 2：RED——编写失败测试
- 编写（失败的）单元测试：使用 unit-testing::test-automator 编写初始必须失败的单元测试，包含边界情况、错误场景与正常路径，不实现生产代码；关键点：验证所有测试都因预期错误信息而失败。
- 验证测试失败：使用 tdd-workflows::code-reviewer 验证所有测试正确失败，确保失败原因是缺少实现而非测试本身错误，确认无假阳性；此关口未通过前不得继续。
阶段 3：GREEN——让测试通过
- 最小实现：使用 backend-development::backend-architect 编写刚好能让测试通过的最少代码，不添加额外功能或优化；约束：不写超出测试所需的代码。
- 验证测试通过：使用 unit-testing::test-automator 运行全部测试并验证通过，检查覆盖率指标，确保没有测试被意外破坏；此关口所有测试必须通过才能继续。
阶段 4：REFACTOR——提升代码质量
- 代码重构：使用 tdd-workflows::code-reviewer 在测试保持通过的前提下重构实现，应用 SOLID 原则、消除重复、改进命名、优化性能，每次重构后运行测试；约束：全程测试保持绿色。
- 测试重构：使用 unit-testing::test-automator 重构测试，去除测试重复、改进测试名称、抽取公共夹具、增强可读性，确保覆盖不变；验证覆盖率指标不变或提升。
阶段 5：集成与系统测试
- 编写（失败的）集成测试：使用 unit-testing::test-automator 编写最初必须失败的集成测试，测试组件交互、API 契约与数据流；验证测试因缺少集成逻辑而失败。
- 实现集成：使用 backend-development::backend-architect 实现集成代码让集成测试通过，聚焦组件交互与数据流；验证全部集成测试通过。
阶段 6：持续改进循环
- 性能与边界用例测试：使用 unit-testing::test-automator 添加性能测试与更多边界用例，包括压力测试、边界测试与错误恢复测试；指标：提高测试覆盖率与场景覆盖。
- 最终代码审查：使用 comprehensive-review::architect-review 全面审查，验证是否遵循 TDD 流程，检查代码质量、测试质量与覆盖率，提出改进建议；在保持测试通过的前提下实施关键建议。
增量开发模式
逐个测试开发时：编写一个失败测试→只让该测试通过→必要时重构→对下一个测试重复。通过添加 --incremental 标志启用该方式。
测试套件模式
面向完整测试套件开发时：为一个功能/模块编写全部（失败的）测试→实现代码让全部测试通过→重构整个模块→添加集成测试。通过添加 --suite 标志启用批量测试开发。
校验检查点
RED 阶段校验：所有测试在实现之前编写；所有测试以有意义的错误信息失败；失败源于缺少实现；没有测试意外通过。
GREEN 阶段校验：所有测试通过；没有超出测试需求的额外代码；覆盖率达到最低阈值；没有为了通过而修改测试。
REFACTOR 阶段校验：重构后所有测试仍通过；代码复杂度降低；重复被消除；性能提升或保持；测试可读性提升。
覆盖率报告：每个阶段后生成覆盖率报告，包括行覆盖率、分支覆盖率、函数覆盖率与语句覆盖率。
失败恢复：若 TDD 纪律被破坏，立即停止，识别违反了哪个阶段，回滚到最后一个有效状态，从正确阶段恢复，并记录经验教训。
TDD 指标跟踪
跟踪并报告：各阶段（红/绿/重构）耗时、测试-实现循环次数、覆盖率进展、重构频率、缺陷逃逸率。
应避免的反模式
在测试之前编写实现；编写已经通过的测试；跳过重构阶段；在无测试的情况下实现多个功能；为了让测试通过而修改测试；忽略失败的测试；在实现之后补写测试。
成功标准
100% 的代码以测试先行方式编写；所有测试持续通过；覆盖率超过阈值；代码复杂度在限制内；被覆盖代码零缺陷；测试文档清晰；测试执行快速（单元测试 < 5 秒）。
适用场景
当任务明确属于上述 TDD 工作流范围时使用，例如需要以红-绿-重构循环实现某项行为，并展示失败测试、最小修复与最终通过检查。示例用户请求：使用红-绿-重构循环实现该行为，并展示失败的测试、最小修复与最终通过的检查。
限制
仅在任务明确匹配上述范围时使用本技能。不应将输出视为环境特定验证、测试或专家评审的替代。如果缺少必需输入、权限、安全边界或成功标准，应停止并请求澄清。
更多细节示例可打开 resources/implementation-playbook.md 查看。