用途：该技能定义 superskills 质量标准所需的红-绿-重构循环，要求在编写任何功能或缺陷修复的实现代码之前先写测试。核心原则是：如果没有亲眼看到测试失败，就不知道它是否在测试正确的东西。违反规则的字面即违反规则的精神。
适用时机：始终用于新功能、缺陷修复、重构与行为变更。例外情况需询问人类伙伴：一次性原型、生成代码、配置文件。
铁律：没有失败的测试，就不写生产代码。若先写了代码，删除它，从头开始，不保留作参考、不在写测试时改编、不看它。
红-绿-重构循环：RED 写一个最小失败测试，名称清晰、测真实行为、只测一件事。然后验证 RED（强制）——运行测试，确认它因功能缺失而失败而非报错，失败信息符合预期；若直接通过说明在测已有行为，若报错则先修复。GREEN 写最简代码使测试通过，不添加额外功能。再验证 GREEN（强制）——确认测试通过、其他测试仍通过、输出干净。随后 REFACTOR 清理重复、改进命名、抽取辅助函数，保持测试全绿且不新增行为。重复进入下一个失败测试。
好测试要求：最小（名称含 and 则拆分）、清晰（名称描述行为）、展示意图（演示期望的 API）。测试应使用真实代码，仅在不可避免时使用 mock。
必要命令：npm test path/to/test.test.ts（用于验证失败与通过）。
为何顺序重要：后写测试会立即通过，无法证明任何事；手动测试是临时的、无记录、无法在代码变更后重跑；删除已写代码不是浪费，保留不可信代码才是技术债。后写测试回答“它做什么”，先写测试回答“它应该做什么”。
红线：先代码后测试、测试立即通过、无法解释测试为何失败、以“就这一次”为由跳过、保留旧代码作参考等，出现即应删除代码并从头开始 TDD。
验证清单：每个新函数/方法都有测试；实现前目睹每个测试失败；失败原因符合预期；为每个测试写最简代码；全部测试通过；输出干净；测试使用真实代码；覆盖边界与错误情况。
卡住时：不知如何测试就写期望的 API、先写断言或询问人类伙伴；测试太复杂说明设计太复杂，简化接口；必须 mock 一切说明耦合过高，使用依赖注入；测试设置庞大则抽取辅助函数或简化设计。缺陷集成：发现缺陷先写复现失败测试，再走 TDD 循环，绝不在没有测试的情况下修复缺陷。添加 mock 或测试工具时需阅读 @testing-anti-patterns.md 以避免常见陷阱。最终规则：生产代码必须存在且先失败过的测试，否则不算 TDD，未经人类伙伴许可没有例外。