systematic-debuglisted

# systematic-debug — 系统式 debug 流程 > 你（主代理）已被本 skill 接管。在解决用户描述的问题前，**必须**按以下流程进行根因分析。 > 这个 skill 是 [`rules/02-systematic-not-reactive.md`](rules/02-systematic-not-reactive.md) 与 [`rules/03-root-cause.md`](rules/03-root-cause.md) 的强制执行入口。 ## 强制流程（按顺序执行，不允许跳步） ### Step 0 · 构建可复现信号（feedback loop） > **这是本 skill 最核心的一步。** 借鉴 `mattpocock-skills:diagnose` 的 Phase-1 原则： > "If you have a fast, deterministic, agent-runnable pass/fail signal for the bug, you will find the cause." > 没有可复现信号，后续 Step 3 / Step 4 的"假设 → 证伪"全是空中楼阁——你只能凭印象写"应该是 X"。 > > **未建立可复现信号前，禁止进入 Step 3。** 反复试图绕开 Step 0 跳到 Step 3 是本 skill 的高频违规。 **0.1 · 选一种 loop 形态（按优先级试 10 种）** 按下面顺序尝试，先选满足"快 + 确定 + agent 可跑"三条的最高优先级： 1. **Failing test** —— 在合适的层（unit / integration / e2e）写一个最小测试，断言 bug 行为。最佳。 2. **Curl / HTTP script** —— 对运行中的 dev server 发请求，把响应跟期望 diff。 3. **CLI invocation + snapshot diff** —— 用 fixture 输入跑 CLI，跟已知正确输出 byte-diff。 4. **Headless browser 脚本** —— Playwright / Puppeteer 驱动 UI，断言 DOM / console / network。 5. **Replay captured trace** —— 把真实 request / payload / event log 存盘，在隔离环境里重放。 6. **Throwaway harness** —— 起一个最小子集（单 service + mocked deps），单函数调用触发 bug 路径。 7. **Property / fuzz loop** —— bug 是 "sometimes wrong" 时，跑 1000 个随机输入找失败模式。 8. **Bisection harness** —— bug 出现在已知两个状态间（commit / dataset / version）→ "boot at state X, check, repeat" 自动化，让 `git bisect run` 直接跑。 9. **Differential loop** —— 同一输入分别跑 old vs new（或两个 config），diff 输出。 10. **HITL bash 脚本** —— 最后兜底；若必须人手点击，至少用脚本驱动人，捕获输出回喂给你。 **0.2 · 把 loop 当