TDD（测试驱动开发）是一套以测试先行驱动代码设计的开发方法论，资料来自 obra/superpowers（MIT 许可）。其核心铁律是：没有先行的失败测试，就不写生产代码。
用途 TDD 用于指导日常编码流程，通过“红-绿-重构”循环保证每一步代码都有测试覆盖，并让设计在测试压力下逐步演化。它强调小步快跑、持续验证，适合需要长期维护、对正确性要求较高的代码库。
主要能力 该方法论提供了一套可操作的循环步骤：
RED——编写失败测试：先确定下一个要实现的最小行为，编写断言该行为的测试，运行测试套件并确认新测试因正确原因失败。如果测试一开始就通过，说明它没有测试新行为，需要重写。
GREEN——让测试通过：编写最少的生产代码使失败测试通过，不添加额外逻辑、不处理未来情况、不做优化。运行测试套件，所有测试必须为绿色；如果其他测试被破坏，先修复再继续。
REFACTOR——清理代码：审视刚写的代码，消除重复、改进命名、简化结构。每次重构后运行测试套件，保持全绿。重构阶段不添加新行为，新行为需要重新进入 RED 步骤。
使用方式 资料给出了若干实践规则：
- 尽可能每个测试只包含一个断言，聚焦的测试能给出更清晰的失败信息。
- 按行为命名测试，例如 should reject expired tokens，而不是 test_validate_3。
- 保持循环短小，目标是每次迭代几分钟，而不是几小时。
- 如果让测试通过时卡住了，说明步骤太大，先写一个更简单的测试。
- 在每个 GREEN 或 REFACTOR 步骤后提交，小提交是廉价的保险。
适用场景
- 新功能：始终适用。
- 缺陷修复：先写一个能复现缺陷的测试，再修复。
- 重构已有且无测试的代码：在改动任何东西之前，先添加特征测试（characterization tests）。
限制与反模式 资料明确列出需要避免的做法：
- 先写生产代码再补测试（test-last 不是 TDD）。
- 在让任何一个测试通过之前就写多个测试。
- 跳过 REFACTOR 步骤，技术债务会无声累积。
- 过度 mock：如果测试中的 mock 比断言还多，需要重新思考设计。
关于该技能的具体安装方式、运行环境、支持语言或平台、收费与价格等信息，资料中暂未提供。