Systematic Debugging Skill
Core Principle: No fixes without root cause investigation first.
The 3+ Fix Rule
[!CRITICAL] If you have attempted 3 or more fixes without success, STOP. This indicates an architectural problem, not an isolated bug. Escalate to user with analysis.
Four Phases
Phase 1: Investigate
Before attempting ANY fix:
| Action | Purpose | |--------|---------| | Read error messages completely | Errors tell you what's wrong | | Reproduce the issue | Confirm you're fixing the right thing | | Check recent changes | What changed before it broke? | | Trace data flow | Follow the data from input to error | | Gather diagnostic evidence | Logs, stack traces, state dumps |
Output: Clear statement of what's happening and where
Phase 2: Analyze
Compare broken state to working state:
| Action | Purpose | |--------|---------| | Find working examples | What does correct behavior look like? | | Compare differences | What's different between working and broken? | | Check assumptions | What are you assuming that might be wrong? | | Review dependencies | What does this code depend on? |
Output: List of differences between working and broken states
Phase 3: Hypothesize
Form a specific, testable hypothesis:
| Good Hypothesis | Bad Hypothesis | |-----------------|----------------| | "The null check on line 42 doesn't handle undefined" | "Something's wrong with the data" | | "The API returns 404 when ID contains spaces" | "The API is broken" | | "State updates before render completes" | "It's a timing issue" |
Test minimally: Change ONE thing to test the hypothesis
Output: Specific hypothesis with test plan
Phase 4: Implement
Only after phases 1-3:
- Write failing test that demonstrates the bug
- Implement single fix addressing root cause
- Verify fix works
- Verify no regressions (run full test suite)
Output: Fix with evidence it works
Red Flags: Restart the Process
If you catch yourself doing any of these, STOP and restart from Phase 1:
| Red Flag | What's Wrong | |----------|--------------| | Guessing at fixes | Skipped investigation | | "Let me try this..." | No hypothesis | | Multiple changes at once | Can't isolate cause | | "One more fix should do it" | Sunk cost fallacy | | Pretending to understand | Incomplete analysis |
The 3+ Fix Escalation
After 3 failed fix attempts:
┌─────────────────────────────────────────────┐
│ 3+ Fix Attempts Failed │
├─────────────────────────────────────────────┤
│ This pattern indicates: │
│ - Fundamental design problem │
│ - Missing understanding of the system │
│ - Wrong level of abstraction │
│ │
│ Recommended actions: │
│ 1. Document what was tried │
│ 2. Describe current understanding │
│ 3. Identify knowledge gaps │
│ 4. Escalate to user/architect │
└─────────────────────────────────────────────┘
Debugging Report Template
After investigation, report:
issue:
symptom: "[What the user sees]"
location: "[File:line or component]"
reproducibility: "[Always/Sometimes/Rarely]"
investigation:
error_message: "[Exact error]"
stack_trace: "[Relevant frames]"
recent_changes: "[What changed]"
data_state: "[Relevant data at failure point]"
analysis:
working_comparison: "[What works vs what doesn't]"
differences_found:
- "[Difference 1]"
- "[Difference 2]"
assumptions_checked:
- "[Assumption]: [Valid/Invalid]"
hypothesis:
statement: "[Specific hypothesis]"
test_plan: "[How to test]"
test_result: "[What happened]"
fix:
change: "[What was changed]"
verification: "[How verified]"
regression_check: "[Test results]"
Integration with Orchestration
This skill is invoked when:
orchestrationdetects 3+ failed fix attempts- User explicitly requests debugging help
verificationskill repeatedly fails
Chain: orchestration → (3+ failures) → systematic-debugging → executor
Deviation Logging
Skipped debugging logged:
- id: [auto]
timestamp: [now]
expected: "Systematic debugging after 3+ failures"
actual: "Continued attempting fixes without investigation"
root_cause: skipped_debugging
fix: |
Enforce systematic-debugging skill after 3 failures.
Add counter to orchestration skill.