bug-huntlisted

# bug-hunt > 触发：仅用户显式 `/bug-hunt` 或自然语言点名"扫 X 找 bug / audit X" > 输出：带 file:line 证据 + 触发链 + 置信度 + 严重度 + 修复风险等级的 bug 列表 > 边界：**不动代码**——只产报告让用户拍板下一步走 PR 还是开 issue ## 为什么这个 skill 存在 LLM 主动找 bug 最常见的 3 个失败模式（社区共识 + 本仓踩过的坑）： 1. **幻觉 bug**："感觉这里有问题"但说不出具体证据 / 触发条件，用户去查发现是 LLM 误读上下文。本 skill **真实性闸门**强制每条 finding 必过 4 项交叉验证。 2. **报告噪音淹没真 bug**：把 nit / 风格 / 假设性优化全部当 bug 上报，用户筛 100 条找 1 条 critical。本 skill **置信度 × 严重度双轴**只报 (高置信 OR 高 severity)，nit 直接不报。 3. **盲扫整库无 scope**：让 LLM 自由发挥扫整个仓 → 结果跨域不深、误报多、用户没耐心读。本 skill **scope-first 强制**——scope 不清晰就先问用户，不瞎扫。 ## 主流程（5 步顺序执行） ### Step 1: 收 scope（不清晰必须问） scope 必须落到下面 4 类之一，**模糊就停下问用户**，不瞎扫： | scope 类型 | 例子 | 适合什么 | |---|---|---| | **crate** | `cdt-watch` / `cdt-api` | 单一职责模块整审 | | **files / glob** | `src-tauri/src/ipc/*` / `crates/cdt-ssh/src/connection*.rs` | 怀疑某文件群 | | **commit range** | `main..HEAD` / `HEAD~10..HEAD` | 最近 N 次提交回顾 | | **capability** | `file-watching` / `session-parsing`（落到 `openspec/specs/<cap>/spec.md`）| spec 维度审"行为 vs 实现" | **禁止**：扫整个仓 / 扫"所有 Rust 代码" / scope 写成"找找看"。 scope 收到后做一次 sanity check： ```bash # 估算扫描体量 find <scope> -name "*.rs" -o -name "*.svelte" -o -name "*.ts" 2>/dev/null | wc -l # 大于 50 文件的 scope 提醒用户拆分 ``` ### Step 1.5: 路由决策（Workflow vs 直接扫） 根据 scope 体量选路径： | scope 体量 | 路径 | 理由 | |---|---|---| | < 10 文件 | **直接扫**（现有 Step 2-5 流程） | 小 scope 不值得 workflow 的 agent spawn 开销 | | 10-50 文件 | **调 Workflow**（`.claude/workflows/bug-hunt.js`） | 吃满 fan-out + schema + 上下文隔离收益 | | > 50 文件 | 先提醒用户拆分（Step 1 已规定） | —