القائمة
Red-Green-Refactor 测试驱动开发纪律。 Use when: 写新功能代码、修 bug、任何实现工作。 Not for: 纯文档、纯调研、已有充分测试的 trivial 改动。 Output: 失败测试 → 最小实现 → 重构，全程有测试保护。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
约定图发现方法论：进一个 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)。
| 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）。