Menu
Red-Green-Refactor 测试驱动开发纪律。 Use when: 写新功能代码、修 bug、任何实现工作。 Not for: 纯文档、纯调研、已有充分测试的 trivial 改动。 Output: 失败测试 → 最小实现 → 重构，全程有测试保护。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | tdd |
| description | Red-Green-Refactor 测试驱动开发纪律。 Use when: 写新功能代码、修 bug、任何实现工作。 Not for: 纯文档、纯调研、已有充分测试的 trivial 改动。 Output: 失败测试 → 最小实现 → 重构，全程有测试保护。 |
| triggers | ["写代码","test first","TDD","红绿重构"] |
先写测试。看它失败。写最少代码通过。
铁律：没有失败的测试，就没有实现代码。
| 异议 | 真相 |
|---|---|
| "写完再补测试，也能验证" | 测试写在实现后会立即通过——你永远不知道它是否真的在测你要的东西 |
| "我手工测了所有 case" | 手工测试没有记录、不能重跑、下次改动时你会忘了测什么 |
| "删掉 X 小时的工作太浪费" | 沉没成本谬误。留着无法信任的代码才是浪费 |
| "TDD 是教条，务实应该灵活" | TDD 本身就是务实的——它比事后调试快，能防止回归，是真正的捷径 |
Tests-after 回答"这段代码做了什么"；tests-first 回答"这段代码应该做什么"。两者不等价。
RED → 写一个会失败的测试
↓ 必须亲眼看到它失败（失败原因要对，不是 typo）
GREEN → 写最少代码让测试通过
↓ 必须亲眼看到它通过（其他测试也要绿）
REFACTOR → 消除重复、改善命名
↓ 保持绿灯，不添加行为
重复 →
关键决策点：
Bug 修复和新功能一样，必须先写失败测试。入口动作：先填诊断胶囊。
诊断胶囊模板 → refs/bug-diagnosis-capsule.md
# 0. 填诊断胶囊（现象/证据/假设/诊断策略/超时策略/预警策略）
# 1. 写一个复现 bug 的测试（此时必须红）
# 2. 确认测试以"预期的理由"失败
# 3. 修复代码
# 4. 确认测试通过 → 填胶囊第 8 栏（验收）
# 5. 确认无回归
永远不要在没有测试的情况下修 bug。
任务开始
↓
写一个描述期望行为的测试
↓
跑测试 → 失败？→ 继续
→ 通过？→ 你在测已有行为，修测试
↓
写最少实现代码
↓
跑测试 → 通过？→ 继续
→ 失败？→ 修代码（不改测试）
↓
全量测试通过？→ Refactor → 重复
rejects empty email 好于 test1听到自己说以下任何一句 → 删掉代码，从测试重新开始：
所有这些都是理由化（Rationalization）。没有例外。
| 错误 | 正确做法 |
|---|---|
| 先写实现，再补测试 | 删掉实现，从失败测试开始 |
| 跳过"看它失败"步骤 | 必须跑测试亲眼看失败 |
| 测试立即通过就继续 | 停下来——测试没有测到真正的行为 |
| 修 bug 时直接改代码 | 先写复现 bug 的失败测试 |
| GREEN 阶段过度实现 | 只写能通过当前测试的最少代码 |
| mock 了所有东西 | 代码耦合度太高，用依赖注入简化 |
debugging：TDD 是预防性的（写代码前）；debugging 是修复性的（bug 出现后）。两者的交叉点：debugging 发现 bug 后，Phase 4 必须先写失败测试再修（此时切换回 TDD 模式）quality-gate：TDD 是开发过程中的纪律；quality-gate 是提交前的验收检查完成功能实现后 → 直接加载 quality-gate 做提交前验收。不要停下来问operator（§17）。
约定图发现方法论：进一个 repo 先识别 repo-specific conventions，再定义 domain/extractor 接 Convention Graph 引擎。Use when: 进入陌生 repo、要画约定图、要找“改 X 影响谁”的约定层关联、 F242/Convention Graph Layer 工作。Not for: 普通符号跳转/LSP、文档索引检索、记忆图谱、直接使用 codegraph/GitNexus。Output: domain 定义 + extractor 计划 + gap/freshness/provenance 报告。 GOTCHA: 沉淀的是“怎么画图”的方法，不是把 cat-cafe 的 extractor 硬搬到所有 repo。
跨 thread 协同：发现平行 session → 通知（3+2 件套）→ 争用协调 → 确认。 Use when: 平行 session 之间需要协同、收到跨线程消息、通知改动影响、共享文件争用。 Not for: 跨猫工作交接（用 cross-cat-handoff）、需要新建 thread 时（用 propose_thread / thread-orchestration）。 GOTCHA: 收到跨线程 ACTION 不等于接活；先做 thread/feat ownership gate，不属于当前 thread 就 cross-post 退回。 Boundary with F128: 发现跨 scope 问题 → 先 list_threads 查有没有已有 thread → 有 = 本 skill（cross_post）→ 没有 = propose_thread。 Output: cross-post 通知 + 争用协调完成。
Feature 立项、讨论、完成的全生命周期管理。 Use when: 开个新功能、new feature、F0xx、立项、feature 完成、验收通过、讨论新功能需求。 Not for: 代码实现、review、merge（那些有专门的 skill）。 Output: Feature 聚合文件 + BACKLOG 索引 + 真相源同步。
明星开源项目拆解：从宣传/PPT/README 进入源码，验证真实架构、明星特性、算法含量、营销水分、可学习点和不 follow 的 tradeoff。 Use when: operator要求拆解热门 GitHub 项目、竞品 agent/runtime、外部 skill/tool 框架，或问“它到底有什么真本事/我们能学什么”。 Not for: 普通资料搜索（用 deep-research）、社区 issue/PR 运营（用 opensource-ops）、只需要架构头脑风暴（用 collaborative-thinking）。 Output: feature-discussions/YYYY-MM-DD-{project}-deep-dive/ 下的代码证据报告 + 对比结论 + 候选 lesson/skill。 GOTCHA: 不许只看 README 下判断；每个明星特性必须追到代码路径、状态突变点、反馈闭环和算法输入输出。
开发完成后的自检门禁：愿景对照 + spec 合规 + 验证。 Use when: 开发完了准备提 review、声称完成了、准备交付。 Not for: 收到 review 反馈（用 receive-review）、merge（用 merge-gate）。 Output: Spec 合规报告（含愿景覆盖度）。
接球前真相核验三问：claim → resolver → verdict (sourceTier T0/T1/T2 + actionFamily)， 防止把传球者当无审视真相源（F167 Phase O 第一性原理）。 Use when: 即将调 hold_ball / register_pr_tracking / register_issue_tracking / merge / takeover / 改 owner / 任何 irreversible action / 基于 "operator signoff" 或 "你是 owner" 类 claim 行动之前。 Not for: 纯阅读 cross_post（无 actionFamily 后续）；本 thread 日常 @mention 无副作用； implementation continuation（自检通过的下一步）。 Output: claim grounding verdict (verified/mismatch/insufficient) + 接球决策 (proceed / block / push back to source thread)。