systematic-debugginglisted

<!-- Adapted from superpowers (https://github.com/obra/superpowers), MIT (c) Jesse Vincent. --> # Systematic Debugging ## Overview Random fixes waste time and create new bugs. Quick patches mask underlying issues. **Core principle:** ALWAYS find the root cause before attempting fixes. Symptom fixes are failure. **Violating the letter of this process is violating the spirit of debugging.** ## Fits in the pipeline Used inside **Stage 6 (Build)** and the **Stage 7 per-feature QA gate** — the adversarial-tester and qa-engineer lenses lean on it. A confirmed root cause feeds a failing test via `test-driven-development` before the fix lands. Priority: **user > skills > default**; `_shared/vibegod-principles.md` apply (#1 investigate before answering, #4 general correct solutions — never code to the symptom). ## The Iron Law ``` NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST ``` If you haven't completed Phase 1, you cannot propose fixes. ## When to Use ANY technical issue: test failures, production bugs, unexpected behavior, performance, build failures, integration issues. **ESPECIALLY when:** under time pressure (emergencies make guessing tempting); "just one quick fix" seems obvious; you've already tried multiple fixes; a previous fix didn't work; you don't fully understand the issue. **Don't skip when:** the issue seems simple (simple bugs have root causes too); you're in a hurry (rushing guarantees rework); someone wants it fixed NOW (systematic is faster than thr