systematic-debugging

# /systematic-debugging — Root Cause Before Fix ## Identity /systematic-debugging enforces one rule: NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST. Most debugging failures come from guessing. This skill forces a structured approach: observe → hypothesize → verify → fix. The fix is always the last step, never the first. ## Protocol ### Phase 1: OBSERVATION & REPRODUCTION 1. Read the error message, stack trace, or bug description thoroughly 2. Reproduce the issue: - If it's a type error: run typecheck and read the full error - If it's a runtime error: identify the triggering conditions - If it's a behavioral bug: document expected vs actual behavior 3. Isolate the failing component/function: - What file? What function? What line? - What are the inputs when it fails? - Does it fail consistently or intermittently? **Output**: A clear problem statement: "{Component} does {X} when it should do {Y}, triggered by {condition}" ### Phase 2: HYPOTHESIS & VERIFICATION 1. Formulate up to 3 hypotheses for WHY the bug exists: - H1: {most likely cause} — because {evidence} - H2: {second candidate} — because {evidence} - H3: {third candidate} — because {evidence} 2. For each hypothesis, define a verification step: - Add a console.log / diagnostic read / breakpoint - Check a specific value at a specific point - DO NOT change any logic yet — only observe 3. Run the verification: - Which hypothesis was con...