systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Install
git clone https://github.com/obra/superpowers /tmp/superpowers && ln -s /tmp/superpowers/skills/systematic-debugging ~/.claude/skills/systematic-debuggingFrom README
Systematic Debugging Overview Core principle: ALWAYS find root cause before attempting fixes. Symptom fixes are failure. Violating the letter of this process is violating the spirit of debugging. The Iron Law If you haven't completed Phase 1, you cannot propose fixes. When to Use Use for ANY technical issue: Test failures Bugs in production Unexpected behavior Performance problems Build failures Integration issues Use this ESPECIALLY when: Under time pressure (emergencies make guessing tempting) "Just one quick fix" seems obvious You've already tried multiple fixes Previous fix didn't work You don't fully understand the issue Don't skip when: Issue seems simple (simple bugs have root causes too) You're in a hurry (rushing guarantees rework) Manager wants it fixed NOW (systematic is faster than thrashing) The Four Phases You MUST complete each phase before proceeding to the next.
More from this repo
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying...
dispatching-parallel-agents
Used when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
executing-plans
Used when you have a written implementation plan to execute in a separate session with review checkpoints