菜单
面向棘手缺陷和性能回退的诊断循环。适用于用户说 “diagnose” / “debug this”，或报告某些东西 broken、throwing、failing、slow 时。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
使用并行子代理为模块生成多个显著不同的接口设计。适用于用户想设计 API、探索接口选项、比较模块形状，或提到 “design it twice” 时。
交互式 QA 会话，用户以对话方式报告缺陷或问题，代理创建 GitHub issues。后台探索代码库以获取上下文和领域语言。适用于用户想报告缺陷、执行 QA、以对话方式提交 issues，或提到 “QA session” 时。
通过用户访谈创建带小提交的详细重构计划，然后作为 GitHub issue 提交。适用于用户想规划重构、创建重构 RFC，或把重构拆成安全的增量步骤时。
从当前对话提取 DDD 风格的 ubiquitous language glossary，标记歧义并提出标准术语。保存到 UBIQUITOUS_LANGUAGE.md。适用于用户想定义领域术语、构建词汇表、收紧术语、创建通用语言，或提到 “domain model” / “DDD” 时。
询问当前情境适合哪个技能或流程；它是本仓库所有 skills 的路由器。
从固定点（commit、branch、tag 或 merge-base）开始，按 Standards（代码是否符合本仓库记录的编码标准？）和 Spec（代码是否符合来源 issue/PRD 的要求？）两个轴线审查变更。两个审查会在并行子代理中运行，并并排报告。适用于用户想审查 branch、PR、进行中的变更，或要求 “review since X” 时。
| name | diagnosing-bugs |
| description | 面向棘手缺陷和性能回退的诊断循环。适用于用户说 “diagnose” / “debug this”，或报告某些东西 broken、throwing、failing、slow 时。 |
面向棘手 bugs 的纪律。只有在明确说明理由时才跳过阶段。
探索 codebase 时，先读取 CONTEXT.md（如果存在），建立相关 modules 的清晰 mental model，并检查你将触碰区域的 ADRs。
这就是这个 skill 的核心。 其他所有内容都是机械步骤。如果你拥有一个针对该 bug 的 tight pass/fail signal，即它会在 这个 bug 上变红，你就能找到原因；bisection、hypothesis-testing 和 instrumentation 都只是消费这个 signal。没有它，盯着代码看多久都救不了你。
在这里投入不成比例的精力。要强硬、要有创造力、拒绝放弃。
git bisect run。scripts/hitl-loop.template.sh 驱动 人，让 loop 仍保持结构化。捕获的输出反馈给你。构建正确的 feedback loop，bug 就修好了 90%。
把 loop 当作产品。只要有了 一个 loop，就继续 tighten 它：
一个 30 秒且 flaky 的 loop 几乎不比没有 loop 好；一个 2 秒 deterministic loop 才是 tight 的调试超能力。
目标不是 clean repro，而是 higher reproduction rate。循环触发 100x、parallelise、加 stress、缩小 timing windows、注入 sleeps。50%-flake bug 可以调试；1% 不行。持续提高复现率，直到它可调试。
停下来并明确说明。列出你尝试过什么。向用户请求：(a) 能复现的环境访问权限，(b) 捕获的 artifact（HAR file、log dump、core dump、带 timestamps 的 screen recording），或 (c) 添加临时 production instrumentation 的许可。不要 在没有 loop 时继续 hypothesise。
Phase 1 完成条件：loop tight 且 red-capable。你能指出 一个 command（script path、test invocation、curl），并且你已经至少运行过一次（贴出 invocation 和 output），且它满足：
scripts/hitl-loop.template.sh。如果你发现自己在 command 存在前就读代码构建理论，停下；直接跳到 hypothesis 正是这个 skill 要防止的失败。 没有 red-capable command，就没有 Phase 2。
运行 loop。看它变红，也就是 bug 出现。
确认：
一旦变红，就把 repro 缩到 仍会变红的最小场景。逐个削减 inputs、callers、config、data 和 steps，每次削减后重新运行 loop；只保留 failure 的 load-bearing 部分。
原因：minimal repro 会缩小 Phase 3 的 hypothesis space（可怀疑的 moving parts 更少），并成为 Phase 5 中干净的 regression test。
完成条件：每个剩余元素都是 load-bearing，移除任意一个都会让 loop 变绿。
在 reproduce 并 minimise 之前不要继续。
在测试任何假设前，生成 3-5 个 ranked hypotheses。单假设会锚定在第一个看似合理的想法上。
每个 hypothesis 必须 falsifiable：说明它会做出什么 prediction。
Format: "If is the cause, then will make the bug disappear / will make it worse."
如果无法说明 prediction，这就是 vibe；丢弃或打磨它。
测试前把 ranked list 展示给用户。 用户常常有 domain knowledge，可以立即重排（"we just deployed a change to #3"），或知道哪些 hypotheses 已被排除。便宜 checkpoint，大幅省时。不要因此阻塞；如果用户 AFK，就按你的排序继续。
每个 probe 都必须映射到 Phase 3 的某个具体 prediction。一次只改变一个变量。
Tool preference：
给每条 debug log 加唯一 prefix，例如 [DEBUG-a4f2]。最后 cleanup 就能一次 grep。未打 tag 的 logs 会存活；带 tag 的 logs 要删除。
Perf branch。 对 performance regressions，logs 通常不对。改为先建立 baseline measurement（timing harness、performance.now()、profiler、query plan），然后 bisect。先 measure，再 fix。
在 fix 前写 regression test，但前提是存在 correct seam。
Correct seam 是 test 能以 call site 中真实发生的方式触发 real bug pattern 的地方。如果唯一可用 seam 太 shallow（bug 需要多个 callers，但 test 只有 single-caller；unit test 无法复制触发 bug 的 chain），那里的 regression test 会给出 false confidence。
如果不存在 correct seam，这本身就是发现。 记录下来。Codebase architecture 阻止你锁住 bug。把它标记给下一阶段。
如果存在 correct seam：
声明完成前必须做：
[DEBUG-...] instrumentation 已移除（grep prefix）然后问：什么本可以预防这个 bug？ 如果答案涉及 architecture change（没有好 test seam、callers 缠绕、hidden coupling），带着具体细节交给 /improve-codebase-architecture skill。这个建议要在 fix 之后提出，不要在之前提出；现在你比开始时知道得更多。