systematic-debugging
Systematic Debugging
Slash-command Usage
Invoked via /superpowers:systematic-debugging "<symptom>" or auto-loaded by other skills (BDD, brainstorming) when bug-fix language is detected.
When invoked as a slash command: capture $ARGUMENTS as the symptom statement, then start at Phase 1 (Root Cause Investigation) immediately. Debugging is iterative within a single session, not phase-driven. Do NOT write design documents or task files; the deliverable is the fix + a test that catches the regression, not a docs/plans/ folder.
Output discipline: Report findings inline as you complete each phase. End with: (a) root cause one-liner, (b) fix diff summary, (c) regression test path.
Recommended: run wrapped in /goal
Debugging is iterative and can span several turns of hypothesis → test → fix. Launch it under Claude Code's built-in /goal (v2.1.139+) so the investigation continues until the regression is actually fixed:
/goal "Claude has narrated the three-part completion output (root-cause one-liner, fix diff summary, regression-test path) with the regression test passing" /superpowers:systematic-debugging "<symptom>"
/goal is a user-typed outer wrapper — it must prefix the invocation; a skill cannot enable it for itself mid-run. The evaluator judges only what Claude narrates in the transcript (it does NOT read files or run commands) — phrase the condition against narrated output (the printed test-run result, the three-part summary), never filesystem state, which is unverifiable and will time out. Full semantics, condition phrasing, and bail-out interaction: ../../skills/references/goal-wrapper.md.