菜单
Use when asked to find bugs, hunt for correctness issues, sweep a codebase for defects, or verify a repo behaves as intended. Not for style or architecture review; this is defect-finding only.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when reviewing a diff or module for hidden assumptions - things the code takes for granted that nothing guarantees - or when asked "what could break this later", "what does this assume", or to harden code that works today. Complements bug-hunt: bug-hunt finds defects with triggers today; this finds the ones waiting for tomorrow.
Use when a diff carries side effects - database writes, migrations, file mutations, network calls, payments, queue messages - to check whether running it twice is safe. Also when reviewing retry logic, crash recovery, or anything a scheduler, queue, or impatient caller might re-run. Silent when the diff touches no side-effecting surface.
Use at the start of any work session and whenever you verify a change in a Brigade-wired repo or workspace - routes work through Brigade so verification, outcomes, evidence export, and handoffs are captured (verify with capture → outcome from run → evidence brief next time) instead of leaving Brigade installed-but-dormant. Triggers on starting a task, running tests/checks, or finishing a session.
Create an Obsidian-formatted markdown note documenting the current session topic. Use when the user says /note, 'save this to Obsidian', 'write a note about X', or asks to document a troubleshooting session, system concept, coding pattern, or workflow. Writes to ~/notes/<slug>.md and syncs to the configured Obsidian inbox. If an argument is provided after /note, use it as the topic; otherwise review the conversation.
Use when the user asks for ultra work, scout work, broad pre-implementation scouting, or parallel investigation before a large Brigade task. Designed for Codex and other SKILL.md harnesses that can delegate or split work.
Use when about to claim anything works, is fixed, is complete, or passes - before committing, replying to the user, or moving to the next task. Also use when relaying a subagent's or tool's success report, and especially at the end of a long session when the pull to say "done" is strongest.
| name | bug-hunt |
| description | Use when asked to find bugs, hunt for correctness issues, sweep a codebase for defects, or verify a repo behaves as intended. Not for style or architecture review; this is defect-finding only. |
A correctness sweep that only reports bugs it failed to refute. Finders generate candidates; verifiers try to kill them; survivors make the report. The single biggest failure mode of agent bug-hunting is plausible-but-wrong findings, so verification is not optional.
Read-only. Finding bugs and fixing them are separate engagements.
Sweep with each lens. With parallel subagents available, one finder per lens; otherwise sequential passes.
| Lens | Hunting for |
|---|---|
| Logic | Inverted conditions, off-by-one, wrong operator, unreachable branches, broken invariants |
| Error handling | Swallowed exceptions, missing error paths, errors that corrupt state before propagating, misleading messages |
| Edge cases | Empty/nil/zero inputs, unicode, huge inputs, boundary values, first/last iteration |
| Concurrency | Races, missing locks, shared mutable state, TOCTOU, async ordering assumptions |
| API misuse | Contract violations against libraries and the project's own interfaces, ignored return values, resource leaks, lifecycle errors |
Focus finders on code that is reachable and load-bearing: entry points, hot paths, recently changed files (git log --since is a good prior). A bug in dead code is info, not a finding.
Two deep lenses live as their own skills: latent-premises for unguarded assumptions that hold today with no trigger yet, and retry-safety for side effects that double-apply on a re-run. Reach for them when the sweep keeps surfacing "could break later" candidates that fail the trigger rule.
Every candidate gets an adversarial pass before it may appear in the report. The verifier's job is to REFUTE the finding, default skeptical:
(unverified)).When tests can be run safely (no external dependencies, sandboxed), a failing reproduction test is the gold standard for confirmation and should be included in the finding as a sketch, not committed.
Same spine as line-check so findings compose. Severity: critical (data loss, corruption, security-adjacent) / high (wrong results on common inputs, crashes) / medium (wrong on edge cases) / low (latent, needs unlikely conditions) / info. Effort is the fix cost: S / M / L.
# bug-hunt report: <repo> (<date>)
## Verdict
Paragraph: overall correctness posture, the scariest confirmed bug.
## Scorecard
| Lens | Score (0-5) | Summary |
## Findings
### [SEVERITY] Short imperative title
- **Lens:** which lens found it
- **Where:** file:line
- **What:** the defect, concretely
- **Trigger:** the concrete input or sequence that hits it
- **Why it matters:** consequence
- **Fix:** specific action
- **Effort:** S / M / L
## Backlog
Numbered, leverage-sorted: `N. [SEVERITY/EFFORT] title (lens)`
## Not checked
Lenses or areas skipped and why; candidates that were refuted (count only).