用途
该技能用于在实现任何功能或缺陷修复之前，强制采用测试先行的工作方式。资料给出的核心原则是：如果你没有看到测试失败，你就不知道它测的是不是正确的东西。它把 TDD 定义为一种纪律，而不是可选的仪式，并声称违反规则的条文就是违反规则的精神。
主要能力
技能以 Red-Green-Refactor 循环为核心流程，资料中给出了对应的流程图（digraph tdd_cycle），包含 RED、Verify Red、GREEN、Verify Green、REFACTOR 与 Next 六个节点及其流转条件。
- RED：写一个最小的失败测试，展示应该发生什么；要求一个行为、名称清晰、使用真实代码（除非不可避免否则不用 mock）。示例为验证 retryOperation 返回 'success' 且 attempts 为 3。
- Verify RED：强制步骤，运行 npm test path/to/test.test.ts，确认测试失败（不是报错）、失败信息符合预期、失败原因是功能缺失而非拼写错误。若测试直接通过，说明你在测试已有行为，需要修正测试；若测试报错，先修错误直到它正确失败。
- GREEN：编写最简单的代码让测试通过，不添加额外功能、不重构其他代码、不做超出测试范围的「改进」。
- Verify GREEN：强制步骤，确认该测试通过、其他测试仍然通过、输出干净（无错误和警告）。测试失败就改代码而不是改测试；其他测试失败要立即修复。
- REFACTOR：只在变绿之后进行，消除重复、改进命名、抽取辅助函数，保持测试通过，不新增行为。
- 重复：为下一个功能写下一个失败测试。
使用方式
资料把适用场景列为：新功能、缺陷修复、重构、行为变更。例外场景为一次性原型、生成代码、配置文件，但需要征求人类伙伴的意见。
铁律（The Iron Law）为：没有失败的测试就没有生产代码（NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST）。若先写了代码再写测试，资料要求删除它并重新开始：不要保留作参照、不要在写测试时「改造」它、不要看它，删除就是删除，从测试重新实现。
常见自我合理化借口及其反驳在资料中以表格形式列出，包括「太简单不用测」「我之后补测试」「手测过了」「删掉 X 小时很浪费」「TDD 太教条，我要务实」「测试后写也能达到同样目标」等，资料逐一给出反驳：测试后写回答的是「这段代码做了什么」，测试先写回答的是「它应该做什么」。
红旗信号（Red Flags）列出需要立即停止并重新开始的情况，包括：先写代码后写测试、测试立即通过、说不清测试为何失败、事后补测试、「就这一次」的合理化、以「精神而非仪式」为由、保留参照或改造既有代码、沉没成本论、声称自己更务实等。资料结论是这些信号都意味着删除代码，用 TDD 重新开始。
适用场景
资料给出一个缺陷修复示例：缺陷为空邮箱被接受。RED 阶段写测试 rejects empty email，断言 result.error 为 'Email required'；Verify RED 运行 npm test 得到 FAIL: expected 'Email required', got undefined；GREEN 阶段在 submitForm 中对 data.email?.trim() 做判断返回 { error: 'Email required' }；Verify GREEN 得到 PASS；REFACTOR 阶段在需要时为多个字段抽取校验逻辑。资料还说明调试集成方式：发现缺陷时写一个可复现的失败测试，遵循 TDD 循环，测试既证明修复也防止回归，永远不要在没有测试的情况下修缺陷。
限制
资料覆盖的是方法论要求、流程、检查清单与示例，未提供关于具体安装命令、依赖、支持的编程语言、收费或价格、平台支持范围的信息，这些内容在给定资料中暂未提供。文中示例使用 TypeScript 与 npm test、jest.fn，但资料未声明该技能局限于某种语言或测试框架。验证清单列出工作完成前的核对项：每个新函数或方法都有测试、每个测试在实现前都被看到失败、失败原因符合预期、写了最小代码使每个测试通过、所有测试通过、输出干净、测试使用真实代码（mock 仅在不可避免时使用）、边界与错误情况已覆盖；资料称不能勾选全部复选框就说明跳过了 TDD，需要重新开始。此外，资料提到遇到困难时的应对：不会写测试就先写期望的 API 和断言或询问人类伙伴；测试太复杂说明设计太复杂，应简化接口；必须 mock 一切说明代码耦合过紧，应使用依赖注入；测试初始化过多应抽取辅助函数，仍复杂则简化设计。