用途
该技能用于指导软件开发的验证优先实践，强调先明确验证需求，再编写实现。它把测试驱动开发（TDD）作为核心方法，要求开发者先写测试、观察其失败，然后编写最小代码使其通过。其核心原则是：如果你没有亲眼看到测试失败，你就不确定它测的是不是正确的东西。技能同时指出，违反规则的字面要求也就是违反规则的精神。
主要能力
- 明确何时使用：始终适用于新功能、缺陷修复、重构和行为变更；例外情况（一次性原型、生成代码、配置文件）需询问合作者。
- 确立“铁律”：没有失败的测试就不写生产代码。若先写了代码，则删除并重新开始，不能保留作为“参考”，不能“改编”，也不能再看它。
- 定义红灯—绿灯—重构循环：红灯阶段写一个最小失败测试；验证红灯（必须执行，确认失败原因符合预期）；绿灯阶段写最简代码通过测试；验证绿灯（必须执行，确认全部通过且输出干净）；重构阶段在保持绿灯的前提下清理重复、改进命名、提取辅助。
- 提供好测试的标准：最小（一件事）、清晰（名称描述行为）、展示意图（体现期望的 API）。
- 解释顺序为何重要：后补测试立即通过，无法证明测试有效；手工测试是临时的、无记录、不可重复；删除旧代码不是浪费，保留无法信任的代码才是技术债；TDD 本身是务实的，能更早发现缺陷、防止回归、记录行为、支持重构。
- 列出常见自我辩解与现实对照表，例如“太简单不需要测试”“我稍后测试”“已经手工测过”“删除 X 小时很浪费”“保留作参考并先写测试”“需要先探索”“测试难写说明设计不清”“TDD 会拖慢我”“手工测试更快”“已有代码没有测试”。
- 列出红旗信号：测试前写代码、实现后补测试、测试立即通过、无法解释测试为何失败、稍后添加测试、为“仅此一次”找理由等，出现这些信号意味着应删除代码并以 TDD 重新开始。
- 给出缺陷修复示例：先写失败测试复现缺陷，再按 TDD 循环修复；绝不在没有测试的情况下修缺陷。
- 提供验证清单：每个新函数/方法都有测试、实现前看过每个测试失败、每个测试因预期原因失败、编写最小代码通过测试、所有测试通过、输出干净、使用真实代码（仅在不可避免时用 mock）、覆盖边界与错误。
- 提供卡住时的处理思路：不知道如何测试就写出期望的 API、先写断言、询问合作者；测试太复杂说明设计太复杂；必须 mock 一切说明耦合过重，使用依赖注入；测试搭建过大就提取辅助，仍复杂则简化设计。
- 指向测试反模式参考资料 @testing-anti-patterns.md，提醒在添加 mock 或测试工具时避免测试 mock 行为而非真实行为、向生产类添加仅测试用途方法、在不理解依赖的情况下 mock。
使用方式
技能以文档形式提供方法、规则、示例和清单，开发者按其流程手动执行；文档中给出的验证命令示例为 npm test path/to/test.test.ts。是否以命令行工具、插件或提示词形式集成，资料未提供。
适用场景
适用于需要以测试引导设计的软件开发工作，尤其是新增功能、修复缺陷、重构和行为变更。对一次性原型、生成代码和配置文件，技能提示这属于例外，需要询问合作者。
限制
该技能强调规则严格，删除先写的代码并重新开始；例外需合作者许可。它不提供具体语言或框架的完整实现细节，也不替代人工判断。关于收费、价格、平台支持范围等信息，资料未提供。