bug-investigatelisted

# Bug Investigate ## Overview Finds the root cause of a bug and reports it. **That is the whole job.** No plan, no fix, no edits. Knowing what is wrong is often the thing that is actually needed — because the fix is obvious once you know, because the decision about *whether* to fix is someone else's, or because the answer changes what gets built rather than what gets patched. **This is the same investigation `superb:bug-fix` runs as its first step.** The difference is where it stops. If you already know you want the bug fixed end to end, use `superb:bug-fix` and let it carry the result into a plan. ## Step 0 — Assemble the report The investigator needs five things, and the invocation argument usually supplies one or two: | Field | Example | | ----- | ------- | | Symptom | "uploads over ~5MB fail silently" | | Reproduction | the steps, or `unknown` | | Error text | stack trace, log line, or `none surfaced` | | Affected surface | endpoint, screen, command, job | | Last known good | a date, a release, a commit, or `never worked` | Ask for whatever is missing in **one batched question**, not five. `unknown` is a fine answer and belongs in the brief; a silently empty field is not, because the investigator will fill it with a guess. ## Step 1 — Investigate Take the first branch that applies: | Condition | What to do | | --------- | ---------- | | A subagent mechanism, and `superb:bug-investigator` is in your available agent types | Dispatch **`superb:bug-investigator`**