From duet
Systematic debugging that applies the scientific method to failures. Use when the user says "debug this", "why is this failing", "help me find the bug", "this doesn't work", "track down the issue", or is stuck on a problem and thrashing without progress.
How this skill is triggered — by the user, by Claude, or both
Slash command
/duet:debuggingThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Apply the scientific method to software failures. Observe before theorizing. Form hypotheses, design experiments, narrow the cause. Refuse to jump to fixes until the cause is isolated.
Apply the scientific method to software failures. Observe before theorizing. Form hypotheses, design experiments, narrow the cause. Refuse to jump to fixes until the cause is isolated.
Never skip from Observe to Fix. The loop exists because human intuition about bug causes is wrong more often than right.
Apply these rules in order. Most debugging failures trace to violating one of the first three.
See references/nine-rules.md for detailed application of each rule.
Before forming any hypothesis:
- What is the exact error message or unexpected behavior?
- When did it start? What changed?
- Does it reproduce consistently?
- What is the smallest reproduction case?
List every plausible cause. Rank by:
Start with the most testable, not the most likely. Fast elimination beats slow confirmation.
Each experiment should:
When the cause lives in a large change:
## Bug
[What happened vs what was expected]
## Root Cause
[The specific defect and why it produced this symptom]
## Evidence
[What experiments confirmed this, what was ruled out]
## Fix
[The change and why it addresses the root cause]
## Prevention
[What would catch this earlier next time]
Shotgun debugging — Changing multiple things at once hoping something works. You'll never know what fixed it, or if it's actually fixed.
Debugging by coincidence — "It works now" without understanding why. The bug is still there.
The usual suspects — Blaming the framework, the OS, the compiler. It's almost always your code.
Rubber ducking without listening — Explaining the problem but not hearing your own assumptions. Slow down at the part that feels obvious.
Fix and forget — Fixing the symptom without asking why the system allowed this failure in the first place.
A good diagnosis:
/testing — Test failures trigger debugging; debugging reveals missing tests/performance — Performance regressions are bugs; profiling is debugging for speed/review — Reviews catch bugs before they need debuggingskills/FRAMEWORKS.md — Full framework indexRECIPE.md — Agent recipe for parallel decomposition (2 workers)npx claudepluginhub tslateman/claude-plugins --plugin duetSystematic debugging methodology for finding and fixing bugs through root cause analysis. Covers reproduce-investigate-hypothesize-fix-prevent workflow, evidence-based diagnosis, and bug category strategies.
Provides systematic debugging framework for root cause analysis after 2+ failed fixes, complex failures, intermittent bugs, and circular debugging.
Enforces systematic root cause analysis before fixes for bugs, test failures, unexpected behavior, performance issues, and build failures.