vs-tdd 是一项测试驱动开发（TDD）技能，核心理念是 Red → Green → Refactor，无例外。先写会失败的测试，再实现代码使其通过，最后按需重构。
适用场景：缺陷修复（先用失败测试证明缺陷存在，再改生产代码）、新功能（先用测试定义行为，再实现）、Autopilot 集成（autopilot 可在每个执行步骤调用本技能）。
工作流程分为五阶段。阶段一：理解。阅读待改代码，查找模块既有测试文件，匹配项目测试模式，可用 find 命令定位测试文件；阅读 1–2 个既有测试文件以了解测试运行器、断言风格、夹具与 mock 设置、命名与文件位置约定，并从 CLAUDE.md、package.json 或 Makefile 确定测试命令。不要自创测试风格，应匹配现有模式。
阶段二：红——先写失败测试。测试即规格。缺陷修复场景中，测试须复现缺陷所走的确切代码路径，运行后必须失败；若通过，说明测试未覆盖该缺陷，需重写，并确认失败信息与真实缺陷一致。新功能场景中，先写正常路径测试，再补边界情况（空输入、null、边界值、错误路径），运行时必须全部失败。写测试规则：每个测试一个逻辑断言；测试名描述行为而非实现；不要 mock 你不拥有的东西，只 mock 边界（HTTP、数据库、文件系统）；若项目完全无测试，按最接近的约定新建测试文件并在决策日志中记录。
阶段三：绿——实现使测试通过，写最少代码，不多写。运行测试必须通过；若失败，读错误修实现（而非改测试），最多重试 3 次，仍失败则重新评估测试预期是否正确。随后运行完整测试套件检查回归；若有失败，区分是本次改动导致还是既有失败，前者需修复，后者需验证在基线分支同样失败并记录。
阶段四：重构（可选）。测试为绿后才清理，仅在需要时进行：消除重复、改善命名、简化写法。每步重构后重跑测试，若破坏则回退该重构。不要重构未改动的代码、仅仅是风格不合的工作代码、或清晰且通过的测试代码。
阶段五：提交。通常两次提交：先只提交失败测试，再提交使测试通过的实现；改动极小时可合并为一次。使用精确暂存文件，不要用 git add .。
规则：永远先写测试；永远不要为通过而修改测试；实现前就通过的测试不构成 TDD，说明测试太弱，需加强直到失败再实现；匹配项目既有测试模式，TDD 重在纪律而非引入个人偏好的框架。
Autopilot 集成：调用时阶段一、二仅覆盖该步骤范围，阶段三即该步骤实现，阶段四跳过（由审查阶段处理清理），阶段五遵循 autopilot 的提交约定。Autopilot 传入步骤描述、受影响文件与测试命令；TDD 返回测试文件路径、实现文件路径与护栏结果。