Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →fradser/systematic-debugging
Diagnoses a reported bug, error, test failure, or unexpected behavior through a 4-phase root-cause analysis before any code changes.
Passed 5 of 11 test cases with the skill, and 3 of 11 without it.
and 6 more in the full report
6 fixed4 passed either way10 still failing2 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
The dashboard is rendering a blank page in production. It's probably the new cache layer we added yesterday, let's just revert that change and see if it works.
| Checked | Without skill | With skill |
|---|---|---|
| Rejects the speculative fix. | Missed | Passed |
| Requires investigating and confirming the root cause before reverting the cache layer. | Missed | Passed |
The instructions your model reads when the skill loads.
Invoked via /superpowers:systematic-debugging "<symptom>" or auto-loaded by other skills when bug-fix language is detected.
When invoked as a slash command: capture $ARGUMENTS as the symptom statement and start at Phase 1 immediately. 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.
/goalLaunch it under Claude Code's built-in /goal (v2.1.139+) so the multi-turn hypothesis → test → fix 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 (a skill cannot enable it for itself mid-run), and its evaluator judges only what Claude narrates in the transcript — phrase the condition against narrated output (the printed test-run result, the three-part summary), never filesystem state. Full semantics and condition phrasing: ../../skills/references/goal-wrapper.md.
Inspect $ARGUMENTS for "named root cause + named fix" signals. Bail out — skip the 4-phase pipeline, apply the fix and write a regression test directly — when ALL of these match:
$ARGUMENTS names a specific root cause (file:line, config key, or specific value), AND$ARGUMENTS names a specific corrective change ("change X to Y", "add the missing flag", "fix the typo"), ANDExamples that bail out:
.foo.com, should be foo.com — fix it"await at api.ts:42, add it"DB_HOST should be DATABASE_HOST in deploy.yaml"Examples that DO NOT bail out (proceed to Phase 1):
test cases passed, vs 3 / 11 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.