| name | systematic-debugging |
| description | Use when encountering any bug, test failure, or unexpected behavior. Enforces root-cause investigation before fixes. The Iron Law — no fixes without understanding why. |
Systematic Debugging
The Iron Law
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
Quick patches mask underlying issues. Systematic debugging is FASTER than thrashing.
The Four Phases (Must Complete in Order)
Phase 1: Root Cause Investigation (MANDATORY)
- Read Error Messages Carefully — full stack traces, exact line numbers
- Reproduce Consistently — if not reproducible, gather more data before proceeding
- Check Recent Changes — git diff, recent commits, new dependencies
- Gather Evidence (Multi-Component Systems)
For EACH component boundary:
- Log what data enters the component
- Log what data exits the component
- Verify environment/config propagation
Run once to gather evidence showing WHERE it breaks
- Trace Data Flow — where does the bad value originate? trace backward
Phase 2: Pattern Analysis
- Find working examples of similar code in the same codebase
- Read reference implementations completely — don't skim
- List every difference between working and broken
- Understand all dependencies and assumptions
Phase 3: Hypothesis and Testing
- Form one specific hypothesis: "I think X is the root cause because Y"
- Make the smallest possible change to test it
- One variable at a time — never multiple changes simultaneously
- Verify: works → Phase 4; doesn't work → form NEW hypothesis
Phase 4: Implementation
- Write a failing test case that reproduces the bug (before fixing)
- Implement the single fix addressing the root cause
- Verify: test passes, no other tests broken, issue resolved
- If 3+ fixes failed → STOP. Question the architecture.
When 3+ Fixes Fail
This is an architectural problem, not a surface bug:
- Each fix reveals new coupling/shared state elsewhere
- Fixes require "massive refactoring" to implement
- Stop and discuss with the human before attempting more fixes
Red Flags — Return to Phase 1
- "Quick fix for now, investigate later"
- "Just try changing X and see if it works"
- "I don't fully understand but this might work"
- "One more fix attempt" (after already trying 2+)
- Proposing solutions before tracing data flow
Real-World Impact
- Systematic: 15-30 minutes to fix, 95% first-time fix rate
- Random fixes: 2-3 hours of thrashing, 40% first-time fix rate
