--- name: systematic-debugging description: Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes --- # Systematic Debugging ## Overview Random fixes waste time and create new bugs. Quick patches mask underlying issues. **Core principle:** ALWAYS find root cause before attempting fixes. Symptom fixes are failure. **Violating the letter of this process is violating the spirit of debugging.** ## The Iron Law ``` NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST ``` If you haven't completed Phase 1, you cannot propose fixes. ## When to Use Use for ANY technical issue: - Test failures - Bugs in production - Unexpected behavior - Performance problems - Build failures ## The Four Phases ### Phase 1: Root Cause Investigation **BEFORE attempting ANY fix:** 1. **Read Error Messages Carefully** - They often contain the exact solution 2. **Reproduce Consistently** - Can you trigger it reliably? 3. **Check Recent Changes** - What changed that could cause this? 4. **Gather Evidence** - Add diagnostic instrumentation in multi-component systems 5. **Trace Data Flow** - See root-cause-tracing.md ### Phase 2: Pattern Analysis 1. **Find Working Examples** - Locate similar working code 2. **Compare Against References** - Read reference implementation COMPLETELY 3. **Identify Differences** - List every difference, however small 4. **Understand Dependencies** - What settings, config, environment? ### Phase 3: Hypothesis and Testing 1. **Form Single Hypothesis** - "I think X is the root cause because Y" 2. **Test Minimally** - One variable at a time 3. **Verify Before Continuing** - Did it work? If not, NEW hypothesis 4. **When You Don't Know** - Say "I don't understand X" ### Phase 4: Implementation 1. **Create Failing Test Case** - Use test-driven-development skill 2. **Implement Single Fix** - ONE change at a time 3. **Verify Fix** - Test passes? No other tests broken? 4. **If 3+ Fixes Failed** - Question the architecture ## Red Flags - STOP and Follow Process - "Quick fix for now, investigate later" - "Just try changing X and see if it works" - "I don't fully understand but this might work" - Proposing solutions before tracing data flow - "One more fix attempt" (when already tried 2+) **ALL of these mean: STOP. Return to Phase 1.** ## Common Rationalizations | Excuse | Reality | |--------|---------| | "Issue is simple" | Simple issues have root causes too. | | "Emergency, no time" | Systematic debugging is FASTER than thrashing. | | "Just try this first" | First fix sets the pattern. Do it right. | | "I see the problem" | Seeing symptoms != understanding root cause. | ## Supporting Techniques - **root-cause-tracing.md** - Trace bugs backward through call stack - **defense-in-depth.md** - Add validation at multiple layers