tdd

name	tdd
description	用测试驱动开发方式实现或修复功能：先写失败测试，再做最小实现，最后重构。只在用户明确要求 TDD、先写测试、补回归测试或按 Red-Green-Refactor 工作时使用；不要用于单纯解释测试报错或泛泛讨论测试概念。
user-invocable	true
disable-model-invocation	true
allowed-tools	Read, Grep, Glob, Write, Edit, Bash(npm:*, node:*, npx:*, vitest:*, jest:*, pytest:*)
argument-hint	[file-or-description]
compatibility	Works best in repositories with an existing test runner and established test conventions.

TDD (Test-Driven Development) Skill

按小步快跑的 Red -> Green -> Refactor 循环工作，优先建立可复现的行为保护，再修改实现。

开始前

• 根据 $ARGUMENTS 明确目标行为、bug 场景或待实现功能。
• 先读现有实现、相邻测试和项目约定，优先沿用仓库已有的测试框架、fixture 和命名方式。
• 如果用户只要求“补测试”而没有要求改实现，就停在测试层，不主动改生产代码。

RED

1. 写能暴露目标行为的最小失败测试。
2. 对 bug 修复，先写复现 bug 的回归测试。
3. 优先运行最小测试范围，确认它确实失败，并说明失败证明了什么。

GREEN

1. 只做让新测试通过所需的最小实现改动。
2. 先重跑刚刚失败的测试；必要时再补跑相邻测试。
3. 不为了“顺手优化”扩大改动面。

REFACTOR

1. 在测试保护下整理命名、消除重复、简化实现。
2. 任何重构后都重新运行相关测试，确保行为不变。
3. 只有在改动面较大或用户明确要求时，才扩大到更完整的测试集。

工作准则

• 优先断言对外可观察行为，而不是内部实现细节。
• 新增测试尽量贴近现有测试文件；只有在必要时才创建新文件。
• 如果仓库没有测试基础设施，先说明现状，再决定是补最小配置还是只给出建议。
• 不要把覆盖率数字当成目标；以行为信心和回归保护为准。

汇报方式

• 使用 ## RED、## GREEN、## REFACTOR 三段汇报。
• 说明修改了哪些测试文件、哪些实现文件，以及运行了哪些测试命令。
• 最后补充剩余风险、未覆盖场景或后续建议。

使用示例

• /tdd src/utils/format.ts - 为 format.ts 编写测试
• /tdd add user validation - 实现用户验证功能 (TDD 方式)
• /tdd - 为当前 git 变更编写测试