bug-diagnosis ยท git:20260714.b87d8d4 ยท 2026-07-14 ยท sha256 61b687ed8801144f

bug-diagnosis git:20260714.b87d8d4A

Immutable. This exact content is served forever at /api/v1/blob/61b687ed8801144f.

---
name: bug-diagnosis
description: "Diagnose a bug systematically instead of guessing โ€” reproduce, isolate, form hypotheses, and test them to root cause. Use when debugging, chasing a defect, an intermittent failure, or 'why is this happening?'. Produces a structured diagnosis: a reliable repro, the narrowed-down location, ranked hypotheses with how to test each, and the root cause + fix once found."
homepage: https://mohitagw15856.github.io/pm-claude-skills/skill/bug-diagnosis.html
metadata:
  {
    "openclaw": { "emoji": "๐Ÿชš" }
  }
---

# Bug Diagnosis Skill

The slowest way to fix a bug is to start changing code and hope. This skill runs a disciplined diagnostic
loop: **reproduce it reliably, isolate where it happens, hypothesize why, and test the cheapest hypothesis
first** โ€” narrowing until the root cause is proven, not guessed. It produces a fix *and* an explanation of why
the bug existed.

## Required Inputs

Ask for these only if they aren't already provided:

- **The symptom** โ€” what's wrong: expected vs. actual behavior, error/stack trace, when it started.
- **Repro steps** โ€” how to trigger it (or "can't reliably reproduce yet").
- **Context** โ€” recent changes, environment, frequency (always / intermittent / specific inputs).
- **What's been tried** โ€” so we don't repeat dead ends.

## Output Format

### Diagnosis: [bug]

**1. Reproduce** โ€” the minimal, reliable steps to trigger it. If it's intermittent, the plan to make it deterministic (fixed input/seed, added logging, narrowed conditions). *No fixing until it reproduces.*

**2. Isolate** โ€” narrow *where* it happens: bisect (git bisect / comment-out / binary search the input), check the boundaries (what's the last known-good point vs. first bad). State the smallest scope that still shows the bug.

**3. Hypotheses (ranked)** โ€” likely causes, most-probable-and-cheapest-to-test first:

| Hypothesis | Why plausible | How to test it (the cheap check) | Verdict |
|---|---|---|---|

Test them in order; record what each rules in or out.

**4. Root cause** โ€” the proven cause (not a symptom), with the evidence that confirms it.

**5. Fix & guard** โ€” the fix, **a test that fails before it and passes after** (lock the bug out), and any nearby instances of the same mistake.

## Quality Checks

- [ ] A reliable reproduction exists before any fix is attempted
- [ ] The location is isolated by bisection/narrowing, not guessed
- [ ] Hypotheses are ranked by likelihood ร— cheapness and tested in order
- [ ] The stated cause is the *root* cause with evidence โ€” not just the surface symptom
- [ ] A regression test is added that fails before the fix and passes after

## Anti-Patterns

- [ ] Do not start changing code before the bug reliably reproduces
- [ ] Do not fix the symptom and stop โ€” trace to the underlying cause
- [ ] Do not change several things at once โ€” you won't know what fixed it (or hid it)
- [ ] Do not skip the regression test โ€” an unguarded bug comes back
- [ ] Do not ignore "what's been tried" โ€” re-running dead ends wastes the loop

## Based On

Systematic debugging method (reproduce โ†’ isolate โ†’ hypothesize โ†’ verify) โ€” Zeller's *Why Programs Fail* / scientific-method debugging.