| name | tdd-workflow |
| description | TDD 跨语言通用纪律——强制 Red-Green-Refactor：写失败测试→最小实现通过→测试保护下重构；新增/修改/删除三类变更均先动测试再动实现。触发：新增/修改/删除业务逻辑源文件（.go/.py/.ts/.tsx/.vue/.js/.rs/.java/.kt）、用户提到 TDD/写测试。跳过：纯 struct/interface/常量定义、生成代码、纯文档、纯配置、vendor/node_modules。 |
测试驱动开发（TDD）纪律
适用于：所有语言、所有业务逻辑代码的新增 / 修改 / 删除变更。
核心：测试是设计工具，不是验证工具。 先写测试迫使你以调用方视角想清楚行为契约。
0. 触发与跳过
TRIGGER：新增/修改/删除业务逻辑源文件（.go/.py/.ts/.tsx/.vue/.js/.rs/.java/.kt 等）；用户提到 TDD/写测试/test-first。
SKIP：纯 struct/interface/enum/常量定义、生成代码、纯文档、纯配置、vendor/node_modules。
1. Red-Green-Refactor 循环（强制）
RED → 写一个失败测试，明确行为预期 → 跑测试确认 FAIL
GREEN → 写最小实现让测试通过 → 跑测试确认 PASS
REFACTOR → 测试保护下重构 → 跑测试确认仍 PASS
RED 要点：真的失败（断言不通过，不是编译错误）；一次只引入一个最小行为预期。
GREEN 要点：最小实现（允许傻瓜实现）；不提前写未覆盖的代码。
REFACTOR 要点：不新增行为；每次小改动后跑测试。
2. 三种变更场景
新增功能
RED（写失败测试）→ GREEN（最小实现）→ REFACTOR → 下一个行为。禁止先写实现再补测试。
修改功能
RED（先改/增测试反映新预期）→ 确认 FAIL → GREEN（改实现）→ 确认全 PASS。禁止先改实现再调测试。
删除代码
检查无依赖 → 先删测试 → 再删实现 → 跑完整测试套件。禁止先删实现导致编译失败再被动删测试。
3. 覆盖率
整体期望 80%+（期望而非硬拦截，显著下降需在 PR 说明中解释）。
优先级：业务逻辑层 > 关键纯函数 > 错误分支 > 边界条件 > 集成边界。
不强求：纯定义文件、框架样板、一次性脚本。
4. 测试作为行为契约
- 需求不清时：先写测试明确预期 → 拿给用户确认 → 再实现
- 测试要满足：可读（名字描述行为）/ 独立（不依赖顺序）/ 可重现 / 快
5. 禁止的反模式
- ❌ 先写实现再补测试
- ❌ 超大集成测试代替基础单测
- ❌ "函数被调用一次"当通过
- ❌ 只覆盖 happy path
- ❌ 测试失败时放宽断言
6. 与语言特化 skill 的关系
本 skill = "做不做、按什么顺序做"（通用纪律）。golang-testing 等 = "具体怎么写"（语言惯用法）。
