技能介绍

问题：Agent 会"顺手"把实现写完

在 Claude Code 这类会话式编程 Agent 里，一个反复出现的场景是：你刚描述完需求，Agent 就打开源文件开始写实现——函数、逻辑、边界处理一气呵成，最后补一个测试来"验证一下"。这个顺序恰恰是 TDD 的反面：测试成了实现的附属品，而不是先于实现存在的、可执行的需求规格。一旦实现先落地，测试很容易被写成对现有代码的复述，回归保护的价值也就随之消失。

TDD Guard 要解决的就是这类"先实现后补测试"的 Agent 行为。它的目标很明确：把 Claude Code 锚定在红-绿-重构（red-green-refactor）循环上——先写一个会失败的测试，确认它真的失败（红），再用最小实现让它通过（绿），最后在测试保护下做重构。

它如何工作

阻断实现优先的行为：当 Agent 试图直接改实现文件、跳过测试先行时，TDD Guard 会介入拦截，把对话拉回到"先定义失败测试"这一步。这不是事后提醒，而是对工作流顺序的前置约束。

锚定红-绿-重构循环：

红：先写一个针对新行为的测试，运行它，并确认失败原因是"功能缺失"，而不是拼写错误或环境问题；
绿：用最小的实现让测试通过，不提前写用不到的代码；
重构：在测试保护下清理代码结构，保持行为不变。

持续陪伴整个会话：约束不是一次性的。在同一个 Claude Code 会话里，每次 Agent 想走捷径、直接进入实现阶段时，Guard 都会把它拉回循环。

适用边界与注意点

依赖现有工具链：需要 Claude Code、Node.js 22+ 以及可用的测试框架；Python/pytest 场景也有相应支持。如果项目还没有可运行的测试基础设施，这一步需要先补齐。
不替代测试本身的质量：Guard 能保证顺序，但不能保证你写出的失败测试有意义。一个方向测错的测试同样会进入红-绿循环，只是绿不了而已。
并非所有改动都适合走全流程：文档、配置、脚手架代码这类改动没有明显的"失败状态"，强行套红绿循环只会制造噪音。
上游行为细节以仓库为准：技能提取自上游 TDD Guard 项目，具体的行为边界建议对照上游文档确认。