New agent proposal: Investigator (Tracy): evidence-based issue diagnosis for the quick-flow track

[anderewrey]

What

A forensic code investigator agent ("Tracy") that approaches issues like a crime scene: reconstructing what happened from available evidence (logs, crash dumps, source code, version control history, issue trackers, test results) and producing a structured investigation file that separates confirmed findings from deductions and hypotheses.

Why

The existing BMad agents cover the forward flow well: Mary analyzes, John manages requirements, Winston architects, Amelia implements, Paige documents. But when something breaks (a bug report, a crash, a regression) there is no agent that works backward from symptoms to root cause before handing off to implementation.

Today, quick-dev (/bmad-quick-dev) expects the user to arrive with a clear understanding of what needs to change. In practice, many tasks start with "something is broken" or "this ticket describes a symptom, not a cause." The investigator fills that gap:

Tracy investigates → structured findings → feeds quick-dev spec → Amelia implements

Key principles

• Evidence grading: every finding classified as Confirmed (directly observed), Deduced (logically follows, reasoning shown), or Hypothesized (plausible but unconfirmed)
• Hypothesis discipline: all hypotheses are explored and their status is updated (Open → Confirmed / Refuted), preserving the full reasoning history
• Stronghold approach: anchor in one confirmed piece of evidence and expand outward, never start from assumptions
• Challenge the premise: user claims are taken as hypotheses, not facts. All is verified independently

Output

A persistent investigation file (_bmad-output/investigations/{slug}-investigation.md) with structured sections: evidence inventory, timeline, confirmed findings, deduced conclusions, hypothesized paths, missing evidence, source code trace, reproduction plan. This file survives context compaction and session interruptions.

How it fits the BMad ecosystem

• Quick-flow complement: Tracy's investigation file provides the grounded understanding that quick-dev needs to produce a correct spec, instead of speccing from a symptom description, you spec from confirmed findings
• Tool-agnostic: uses whatever MCP tools and CLI tools are available in the environment (issue tracker, source control, static analysis, log tools)
• Environment-aware: reads project context documentation if present, proceeds without it if absent
• Session-resilient: the investigation file is the persistent state and Resume Case picks up exactly where the previous session left off
• Party mode participant: Tracy challenges assumptions and demands evidence when other agents propose solutions based on untested premises

Questions for maintainers

• Does this type of agent fit the BMad Method vision?
• Would it belong in the bmm module alongside the other agents, or better as a community module?
• Any overlap with planned work I should be aware of?
• Is the quick-dev integration angle (investigation → spec → implementation) something worth formalizing as a workflow path?

Happy to share the full agent definition and iterate on feedback.

[bmadcode]

I love this idea @anderewrey - agents in general are going through some recent changes and consolidations - I think what you are describing would be a great addition. I need to think on if it should be a stand along agent, or a workflow skill assigned to one of the existing agents. This feels like it belongs before phase 4, maybe in line with PRD - ie instead of PRD start with this if what is needed is working backwards analysis to plan for the quick flow integration - or the user could choose it actually leads to a much larger initiative.

if you are in discord, please reach out or share the idea in their also.

[anderewrey]

See PR #2340