debug-firstlisted
Install: claude install-skill snowzhaozhj/claude-devtools-rs
# debug-first
> 触发：`/debug-first` 或诊断信号词
> 输出：按 4 步节拍走，每步给"硬约束 + 跳出条件"
> 不修改业务代码——只**约束诊断流程**，结论给用户拍板后再动手
## 为什么有这个 skill
排查 bug 时模型会习惯性"读两眼代码直接猜原因 → 给方案 → 让用户监工验证"。三个常见失败模式：
1. **静态推理 vs 真复现**：代码逻辑能列可能性，但只有真数据告诉你**实际**走的是哪条路径。曾经第一轮我推 "前端 inflight race 是真因"，跑端到端真后端后发现根本是后端 SFTP channel 死掉了 — 推理全错。
2. **环境假设**：以为"复现需要 X 我没有"就停手让用户跑，常被反问"之前不是配过吗"。十次有八次现成 docker / fixture / e2e 脚本就在 `scripts/` 里。
3. **诊断浮于表面**：单次复现就下结论 / 不标置信度 / 把不相关 bug 顺手修扩大 scope，让 reviewer 反复抓 critical race。
## 4 步主流程（按顺序执行）
| Step | 关键动作 | 跳出条件 |
|---|---|---|
| 1 | 复现 + 调高 log + 多时间点 trial | 无外部状态依赖（无 IPC / 文件 I/O / 并发 / 网络 / SSH）的本地纯函数 bug |
| 2 | 跨端数据不一致先 `ps`/`lsof` 排进程残留 | 单进程 / 单 runtime 的 bug |
| 3 | 假设环境缺失前先 `grep` 基础设施 | 已确认环境齐 |
| 4 | 诊断报告标置信度 + 方案分级 | 单 bug 100% 确认 + 一行 fix |
### Step 1: 复现 + 调 log + 多时间点 trial
涉及"多端交互 / 状态机 / 时间窗口 / 并发 / 网络 / SSH"的 bug，**SHALL 真复现 + 看真数据**再猜原因。三件事一起做：
**真复现**：
- 优先用 `e2e-http-verify` skill（已配 `cdt-cli` HTTP server + 浏览器 `?http=1` 端到端真后端）
- SSH 类走 `just verify-ssh-docker` / docker `cdt-ssh-test` 容器
- 浏览器交互类用 chrome-devtools mcp + `evaluate_script` 看真 store 状态
**调高 log level 比读代码快 10×**：怀疑哪个 module 就 `RUST_LOG="<module>=debug"`：
```bash
RUST_LOG="cdt_api=info,cdt_ssh=debug,cdt_watch=info" cargo run -q -p cdt-cli --bin cdt > /tmp/cdt-debug.log 2>&1 &
```
加一次 debug log 后 log 直接打出真因（如 "session closed / projects root does not exist"）—— 比追代码追半天快。前端调试同理（`?debug=1` query / `localStorage.debug = '*'`）。
**多时间点 trial**：状态/时间相关 bug **不要**信单次复现。三种 trial 时机：
- 立即