用途
tdd-obra 是一个测试驱动开发（TDD）技能，用于强制实施严格的“测试优先”开发方法。其核心原则是：“先写测试。观察它失败。写最小代码使其通过。”如果开发者没有亲眼看到测试失败，就无法确认测试是否在检验正确的行为。该技能旨在通过 RED-GREEN-REFACTOR 循环，防止回归并确保代码正确性。
主要能力
- 强制执行 RED-GREEN-REFACTOR 循环：先写一个失败测试（RED），验证其失败原因符合预期；再写最小实现代码使测试通过（GREEN），并确认所有现有测试仍然通过；最后在保持测试通过的前提下重构代码（REFACTOR）。
- 提供“铁律”：没有失败的测试，就不产生任何生产代码。任何在测试之前编写的代码都必须完全删除，不允许保留作为参考。
- 包含验证清单：每个函数都有测试、每个测试都先被观察失败、测试因预期原因失败、最小代码通过测试、所有测试无警告通过、使用真实代码并尽量减少模拟、覆盖边界情况和错误。
- 提供常见错误处理表：例如测试立即通过（说明先写了代码，需删除重来）、测试报错而非失败（修复测试设置）、测试通过但功能损坏（检查断言）、测试不稳定（修复测试隔离）。
- 定义度量指标：测试优先率 100%、RED 验证 100%、覆盖率 >80%、关键路径覆盖率 100%、测试独立性 100%。
使用方式
快速入门步骤：
- 编写一个失败测试——用最小测试展示期望行为。
- 验证 RED——运行测试，确认它失败（而不是报错）。
- 编写最小代码——仅够通过测试。
- 验证 GREEN——所有测试通过。
- 重构——在保持绿色通过的前提下清理代码。
适用场景包括：开始新功能或模块、修复缺陷（先写复现缺陷的失败测试）、重构现有代码、任何生产代码开发、代码审查验证。
缺陷修复模式：写失败测试复现缺陷 → 验证测试因预期原因失败 → 实现最小修复 → 验证所有测试通过 → 如需要则重构 → 将测试与修复一起提交。
适用场景
- 新功能或新模块开发
- 缺陷修复
- 重构现有代码
- 生产代码开发
- 代码审查验证
限制
该技能强调严格纪律，不接受任何合理化借口，例如“太简单不用测试”“我稍后测试”“已经手动测试过”“测试拖慢我”“我知道这能工作”等。这些都被视为需要完全重新开始 TDD 流程的红旗信号。测试后写的方法无法验证“应该做什么”，只能验证“已经构建了什么”，因此不被认可。
相关技能
- systematic-debugging：用方法论调试
- writing-plans：规划实现
- subagent-driven：结构化开发
版本历史
1.0.0（2026-01-19）：初始版本，改编自 obra/superpowers。