/bmad-investigate

name: bmad-investigate
description: |
  Forensic bug and issue triage. Produces a graded investigation case file:
  symptoms, evidence (graded A/B/C by confidence), ranked hypotheses, suspected
  components, and a recommended planning response. INVESTIGATES and DOCUMENTS only —
  does NOT fix code, run tests, or implement. Hands off as a story to an external
  dev tool.

  Use when the user says:
  - "investigate this bug" / "triage this issue" / "debug triage"
  - "what's causing [symptom]" / "why is [feature] broken"
  - "something's wrong with [component]" / "users are reporting [problem]"
  - "figure out what happened" / "root cause this"
  - "I need a bug report" / "create an investigation case file"
  - "forensic analysis" / "diagnose this"
  - "error triage" / "issue investigation"
  - "what do we know about [incident/issue]"

  Three intents: Create (new case file), Update (add evidence to open case),
  Validate (check draft for completeness before handoff). Output lands in
  bmad-output/; a fix story is drafted on handoff.
allowed-tools: Read, Write, Edit, Glob, Grep, TodoWrite

BMAD Investigate

**Forensic triage — plan the fix, don't apply it.**

This skill builds a structured, evidence-graded investigation case file so that whoever picks up the story has a clear picture of what is known, what is suspected, and exactly what needs verifying before any code changes. It deliberately stops before implementation; the result of every investigation is a story handed off to an external dev tool.

**Persona flavor:** Mary (Business Analyst) frames the user impact; Winston (Architect) maps the component topology. The skill is a workflow, not a character.

---

Scope Law (read first)

This skill PLANS. It reads planning artifacts and existing code to gather evidence. It does NOT write application code, run tests, lint, build, or review diffs. The last artifact it emits is either an updated planning document or a story file marked `status: ready-for-dev`. If tempted to "fix the bug", "run the suite", or "apply the patch" — STOP. Investigate and hand off.

---

Inputs (load these first)

| Source | Why | |--------|-----| | `bmad-output/project-context.md` | Project constitution — architecture, stack, ownership | | `bmad-output/architecture.md` | Component boundaries, module responsibilities | | `bmad-output/prd.md` or `tech-spec.md` | Requirements the broken behavior should satisfy | | `bmad-output/decision-log.md` | Prior decisions that may relate to the issue | | User-provided symptom description | Primary input — what is failing, when, how | | Logs / error messages the user pastes in | Raw evidence to grade and analyze | | Existing story files in `bmad-output/stories/` | Check for duplicate or related work |

If project-context.md does not exist, ask the user to describe the stack and affected area before proceeding.

---

Three Intents

Ask which intent applies if ambiguous.

• **Create** — new investigation case file from scratch.
• **Update** — add new evidence to an existing case file, re-rank hypotheses.
• **Validate** — check a draft case file for completeness against the case-file contract.

---

Workflow — Create

Use TodoWrite to track progress through these steps.

Step 1 — Clarify the Symptom

Before investigating, confirm exactly what is observable. Ask (or infer from context):

1. **Symptom** — what behavior is wrong? What is the expected behavior? 2. **Trigger** — when does it occur? Every time? Intermittently? Under load? 3. **Scope** — which users, environments, or configurations are affected? 4. **First seen** — when was the issue introduced or first noticed? 5. **Severity** — data loss, service outage, degraded UX, cosmetic?

Record these as the "Symptom Summary" — this is the anchor for all grading later.

---

Step 2 — Load Context

Read all available inputs listed above. Extract:

• **Affected components** — which modules/services does the symptom implicate?

(Cross-reference architecture.md for component responsibilities.)

• **Related requirements** — which FR or NFR does the broken behavior touch?

(Search prd.md for the area.)

• **Recent decisions** — any ADR or decision-log entry touching the suspected area?
• **Similar stories** — any existing story file referencing the same component?

---

Step 3 — Gather and Grade Evidence

Collect all available evidence. Assign each item an evidence grade:

| Grade | Meaning | |-------|---------| | **A** | Directly observed, reproducible, or confirmed by multiple independent sources. High confidence. | | **B** | Single-source, inferred from logs, or plausible but not yet reproduced. Medium confidence. | | **C** | Speculative, based on code reading only, or pattern-matched without direct confirmation. Low confidence. |

Evidence types to gather:

• Error messages and stack traces (paste verbatim; mark as grade A if directly from logs)
• Reproduction steps (grade A if reliably reproduced; B if intermittent)
• Code paths identified via Grep/Glob (grade B — code reading is inference, not proof)
• Configuration or environment differences (grade B unless confirmed in both envs)
• Historical changes — recent commits or PRs that touched the area (grade C without

reproduction confirmation)

• User reports or support tickets (grade B — external, non-reproducible by default)

Use Grep and Glob to search the codebase for error strings, function names, or file paths the user mentions. Read code files to trace call paths. Do NOT run the code — read it.

---

Step 4 — Form Hypotheses

Based on all grade-A and grade-B evidence, draft 2–5 hypotheses. For each:

• **Hypothesis** — a concise statement of the suspected root cause.
• **Supporting evidence** — which evidence items support it (cite grade).
• **Contradicting evidence** — anything that argues against it.
• **Plausibility rank** — High / Medium / Low (derived from weight of A+B evidence).
• **Verification step** — what a dev agent would need t