debug-with-plan

name	debug-with-plan
description	Use when investigating a bug, test failure, or unexpected behavior and proposing a fix — always runs investigation in Plan Mode so no code changes happen until the root cause and approach are confirmed.

Debugging in Plan Mode

Investigation and fix-proposal are kept separate from execution. Root-cause first, propose second, implement only after explicit approval.

Steps

1. Reproduce first. Get the exact failing command/input/conditions before theorizing. If you can't reproduce it, say so — don't guess at a fix for something you haven't observed.

2. Stay in Plan Mode for the investigation. Read code, run read-only commands (logs, git log/git blame on the suspect area, test runs), form a hypothesis — but make no edits yet.

3. Find the root cause, not the symptom. Ask "why" until you hit something that, if changed, would have prevented the bug from ever being possible — not just the line where it surfaced.

4. Propose, don't just fix. Lay out:

   ## Root cause
   <what's actually wrong, and why it produces the observed symptom>
   
   ## Proposed fix
   <the change, and why this is the right altitude — fixing the cause,
   not papering over the symptom>
   
   ## Alternatives considered
   <if there were other viable approaches, name them and why you didn't pick them>
   
   ## Regression test
   <what test would have caught this, and that you'll add it>
   

5. Exit Plan Mode and implement only after the user approves the proposal.

Notes

• Resist the urge to start editing the moment you spot something suspicious — confirm it's the cause, not a plausible one.
• A fix without a regression test isn't done — see [[impact-review]] for reviewing the blast radius of the change once it's written.