用途
eng-tdd 是一个用于强制推行测试驱动开发（TDD）纪律的技能。它的目标是确保每一段生产代码都先由一个失败的测试来驱动，从而避免“先写代码、后补测试”带来的虚假安全感和不可复现的验证。
核心原则
该技能提出一条铁律：没有失败的测试，就不写生产代码（NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST）。如果先写了代码，就应当删除它，从测试重新开始。
RED-GREEN-REFACTOR 循环
技能要求按以下步骤循环推进：
- RED：编写一个描述期望行为的最小测试。测试名称应清晰、具体，测试真实行为，避免不必要的 mock。
- 验证 RED：运行测试，确认它因预期原因而失败。
- GREEN：编写最简单的代码让测试通过，不添加额外功能。
- 验证 GREEN：运行整个测试套件，确保新测试和已有测试都通过。
- REFACTOR：在保持全部测试通过的前提下清理代码和测试。
- 针对下一个行为重复上述过程。
好测试与坏测试
技能给出对比：好测试只测一件事、名称清晰、测试真实行为；坏测试名称模糊（如“does work”）、命名为 test1、对 mock 进行断言。
为什么顺序重要
技能解释：代码写完之后再写的测试会立即通过，因此什么也证明不了；手动测试不是可复现的证据；保留预先写好的代码“作为参考”会破坏 TDD，应当删除并从测试重建。
常见借口与反驳
技能列出若干常见借口并给出回应：
- “太简单了”——简单代码也会出错，仍然要测试。
- “我稍后再测”——事后测试确认的是现有行为，而非需求。
- “手动测试就够了”——没有记录也无法重跑，必须自动化。
- “删除工作太浪费”——这是沉没成本；未测试的代码是债务。
- “要务实”——TDD 能避免调试地狱，务实等于可靠。
验证清单
技能提供一份检查清单：每个新行为都有测试守护；在实现前看到每个测试失败；每次失败都是因为缺少行为（而非拼写错误）；编写最少代码让每个测试通过；变更后全套测试通过；仅在绿色状态下重构；测试覆盖边界和错误情况。任何一项未通过，就说明跳过了 TDD，需要重新开始。
集成缺陷修复
对于缺陷修复，技能要求：先用一个失败的测试复现缺陷；应用修复使测试通过；保留该测试以防止回归。
适用场景与限制
该技能适用于每个功能、缺陷修复、重构或行为变更。例外情况仅在获得人工明确批准时允许（如一次性原型、生成代码等）。最终规则是：生产代码只能与一个在代码编写之前就失败的测试同时存在，否则就要用 TDD 重做。
关于该技能的具体安装方式、支持的平台或工具集成，资料中暂未提供。