Triage with TDD

Investigate a reported problem, find its root cause, and produce a TDD fix plan. The goal is to hand the user a clear, actionable issue they can immediately start working on. Minimize back-and-forth — code exploration answers most questions faster than asking.

Process

1. Capture the problem

If the user hasn't described the issue, ask exactly one question: "What's the problem you're seeing?"

Resist asking follow-ups before you investigate. You'll find most of the context yourself, and what you can't find you can clarify at the end.

2. Explore and diagnose

Launch parallel explore subagents to investigate different angles simultaneously — this saves significant time on larger codebases. A good split:

• Subagent A — Code path: Trace from the symptom back to its origin. Follow the call chain, data flow, or event lifecycle until you find where the behavior diverges from what's expected.
• Subagent B — History & tests: Check git log on relevant files for recent changes. Look at existing tests to understand what's already verified and what's missing.
• Subagent C (if needed) — Similar patterns: Search the codebase for analogous features that work correctly. This reveals whether the issue is unique or systemic.