用途
tdd-discipline 是一个测试驱动开发（Test-Driven Development）方法论的技能，用于在实现功能或修复缺陷时提供一套可执行的开发纪律。它把 TDD 的核心循环固化为明确步骤，并给出违反规则时的处理方式，帮助开发者在编码过程中始终保持“先测试、后实现”的顺序。
主要能力
- 核心循环：RED → GREEN → REFACTOR，循环往复。
- RED（编写失败测试）：一次只测试一个行为；测试名称要清晰（例如 "rejects empty email" 符合要求，"test1" 不符合）；尽量使用真实代码，减少 mock；并且必须实际运行测试以确认它失败，不能跳过验证。示例命令为
npm test path/to/test.test.ts。验证要点包括：测试是否失败（是失败而非报错）、失败信息是否符合预期、失败是否由功能未实现导致（而非拼写错误）。 - GREEN（编写最少代码）：只写让测试通过的最简代码，不添加功能，不进行重构，遵循 YAGNI（You Ain't Gonna Need It）。
- REFACTOR（整理）：消除重复、改进命名、抽取辅助代码，同时保持测试持续通过，且不新增行为。
使用方式
按照 RED → GREEN → REFACTOR 的顺序推进，每个循环只针对一个行为。RED 阶段必须运行测试并确认失败原因符合预期；GREEN 阶段只做最小实现；REFACTOR 阶段只做结构整理。技能中给出的运行示例为 npm test path/to/test.test.ts。
违规处理
如果未写测试就先写了代码，规则是删除该代码并从头开始。资料明确列出不可取的做法：留作参考、边写测试边套用已有代码；而正确的是不再查看该代码。
适用场景
始终适用的场景包括：新功能实现、缺陷修复（先写复现缺陷的测试）、行为变更。
缺陷修复时的 TDD 流程为：编写复现缺陷的测试 → 确认 RED（验证测试能捕获该缺陷）→ 编写修复代码 → 确认 GREEN → 作为回归测试永久保留。
限制
资料列出可由使用者自行判断的例外场景：一次性原型、配置文件、生成代码。此外，文档也列出了常见借口及其反驳，例如“太简单不需要测试”“以后再补测试”“TDD 太慢”“已经手动测试过”“不舍得删除数小时的工作”，用以说明这些理由并不成立。关于该技能的具体安装方式、支持的运行环境、依赖与版本要求，资料中暂未提供。