Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →mkurman/systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Passed 21 of 23 test cases with the skill, and 18 of 23 without it.
and 3 more in the full report
3 fixed18 passed either way2 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
I'm encountering an unexpected null reference exception in our user service during peak traffic, and my teammate wants to just throw in a quick patch right away. Can you give me a structured, phase-by-phase plan for investigating and resolving this bug methodically instead of making unverified changes?
| Checked | Without skill | With skill |
|---|---|---|
| The plan includes finding existing working code examples or patterns to compare differences against. | Missed | Passed |
| The plan specifies forming a minimal testable hypothesis before implementing a solution. | Passed | Passed |
| The plan explicitly requires writing a failing test before applying the fix. | Missed | Passed |
The instructions your model reads when the skill loads.
--|---------| | "Issue is simple, don't need process" | Simple issues have root causes too. Process is fast for simple bugs. | | "Emergency, no time for process" | Systematic debugging is FASTER than guess-and-check thrashing. | | "Just try this first, then investigate" | First fix sets the pattern. Do it right from the start. | | "I'll write test after confirming fix works" | Untested fixes don't stick. Test first proves it. | | "Multiple fixes at once saves time" | Can't isolate what worked. Causes new bugs. | | "Reference too long, I'll adapt the pattern" | Partial understanding guarantees bugs. Read it completely. | | "I see the problem, let me fix it" | Seeing symptoms ≠ understanding root cause. | | "One more fix attempt" (after 2+ failures) | 3+ failures = architectural problem. Question pattern, don't fix again. |
| Phase | Key Activities | Success Criteria |
|---|---|---|
| 1. Root Cause | Read errors, reproduce, check changes, gather evidence | Understand WHAT and WHY |
| 2. Pattern | Find working examples, compare | Identify differences |
| 3. Hypothesis | Form theory, test minimally | Confirmed or new hypothesis |
| 4. Implementation | Create test, fix, verify | Bug resolved, tests pass |
If systematic investigation reveals issue is truly environmental, timing-dependent, or external:
But: 95% of "no root cause" cases are incomplete investigation.
These techniques are part of systematic debugging and available in this directory:
root-cause-tracing.md - Trace bugs backward through call stack to find original triggerdefense-in-depth.md - Add validation at multiple layers after finding root causecondition-based-waiting.md - Replace arbitrary timeouts with condition pollingRelated skills:
test cases passed, vs 18 / 23 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.