root-cause-debugging
/root-cause-debugging
Find and fix the real cause of bugs, never the symptom — disciplined reproduce-minimize-hypothesize-instrument loops for hard bugs and performance regressions, backward call-stack tracing to the original trigger, test-pollution bisection with a find-polluter script, expert investigation protocols, and competing-hypothesis tracing lanes. Use when a bug's cause is unclear, errors surface far from their origin, fixes keep not sticking, tests pollute each other, or you're tempted to patch a symptom or add a retry. Iron Rule: no fix without reproduction, no claim without evidence. Not for full-site
- Author
- krzemienski ↗
- Repository
- proofpunk ↗
- Licence
- MIT
- Last repository change
- 14.09.2026
Assessment and security
- Files in this package
- 12
- Scripts
- 2
- HTML comments
- 0
- URLs in SKILL.md
- 0
No signals detected. Repository changed on 14.09.2026, without references to retired models or APIs.
MIT, open: use and modify while retaining author attribution.
- 2 scripts in this package. Review them before installing, as Claude may execute them.
Scripts: scripts/find-polluter.sh, scripts/hitl-loop.template.sh
What it does and when to use it
Find and fix the real cause of bugs, never the symptom — disciplined reproduce-minimize-hypothesize-instrument loops for hard bugs and performance regressions, backward call-stack tracing to the original trigger, test-pollution bisection with a find-polluter script, expert investigation protocols, and competing-hypothesis tracing lanes. Use when a bug's cause is unclear, errors surface far from their origin, fixes keep not sticking, tests pollute each other, or you're tempted to patch a symptom or add a retry. Iron Rule: no fix without reproduction, no claim without evidence. Not for full-site
Original author description
Find and fix the real cause of bugs, never the symptom — disciplined reproduce-minimize-hypothesize-instrument loops for hard bugs and performance regressions, backward call-stack tracing to the original trigger, test-pollution bisection with a find-polluter script, expert investigation protocols, and competing-hypothesis tracing lanes. Use when a bug's cause is unclear, errors surface far from their origin, fixes keep not sticking, tests pollute each other, or you're tempted to patch a symptom or add a retry. Iron Rule: no fix without reproduction, no claim without evidence. Not for full-site
How it works
- Run checklist
- Non-Negotiables
- Measured additions (2026-08-12, aperant-tui gate runs)
- Reference Routing
- Workflow
- Anti-Patterns
- Example
- Skill calls
SKILL.md preview
--- name: root-cause-debugging description: > Find and fix the real cause of bugs, never the symptom — disciplined reproduce-minimize-hypothesize-instrument loops for hard bugs and performance regressions, backward call-stack tracing to the original trigger, test-pollution bisection with a find-polluter script, expert investigation protocols, and competing-hypothesis tracing lanes. Use when a bug's cause is unclear, errors surface far from their origin, fixes keep not sticking, tests pollute each other, or you're tempted to patch a symptom or add a retry. Iron Rule: no fix without reproduction, no claim without evidence. Not for full-site bug hunts (use full-functional-audit) flaky-test discipline (use stack-testing), or pre-release audits (use production-readiness). --- # Root-Cause Debugging ## Run checklist Copy this checklist and track your progress: - [ ] Reproduce the bug reliably (no fix without reproduction) - [ ] Minimize the repro; trace backward to the original trigger - [ ] Form competing hypotheses; instrument to discriminate between them - [ ] Fix the root cause, never the symptom (no retries-as-fix) - [ ] Verify with evidence; check for test pollution The Iron Rule's other half: fixing the real system requires finding the real cause. A patch applied to a symptom — a retry, a `sleep()`, a swallowed exception, a widened timeout — is a mock of a fix and is forbidden here. ## Non-Negotiables 1. **Reproduce first.** No reproduction, no fix. If you cannot make it fail on demand, your job is building the reproducer, not editing the code. 2. **One hypothesis at a time, tested.** From `references/debug-like-expert.md`: state the hypothesis, predict what evidence confirms/refutes it, gather THAT evidence, then update. 3. **Trace backward from the crash to the trigger** — `references/root-cause-tracing.md`: the line that throws is almost never the line that's wrong. Follow invalid data back to its origin. 4. **Evidence over vibes.** Instrument, log, bisect. Every "I think it's X" gets a measurement. Cite what you SEEN, per `../../references/evidence-contract.md`. 5. **Verify the fix against the original reproduction**, then re-run the surrounding suite — a fix that breaks neighbors is a new bug, and its blast radius must be re-validated (see the shared runbooks at `../../references/*-validation.md`). ## Measured additions (2026-08-12, aperant-tui gate runs) 1. **Verify contracts against the emitter, not the name.** Before writing a listener/subscriber/client, grep the actual emit/call sites. A 'task-started' event that "obviously exists" did not exist anywhere in the vendored runtime — the listener would have timed out on every successful start and reported real work as failed (defect D5). The integration test passed only because the failure path happened to share an event name. Assumed contracts fail silently; verified contracts fail loudly. 2. **Typecheck-green means nothing at runtime boundaries.** An SDK major upgrade renamed `usage.promptTokens` → `usage.inputTokens`; the code typechecked (optional chaining with `?? 0`) and silently recorded zero tokens forever (defect D11). After any dependency major bump, prove one real end-to-end data flow and LOOK at the numbers before trusting the build. 3. **Module-system mismatches hide behind type stubs.** `@types/node` declares `__dirname` for files that run as ESM under tsx — typecheck green, instant `ReferenceError` at boot (defect D6). Boot the real entry point once before shipping any init-time path logic. ## Reference Routing | Situation | Read | |---|---| | Hard bug or performance regression, no obvious cause | `references/diagnose.md` (+ `scripts/hitl-loop.template.sh`) | | Error deep in a call chain / invalid data of unknown origin | `references/root-cause-tracing.md` (run `scripts/find-polluter.sh` for test pollution bisection) | | Full expert investigation protocol | `references/debug-like-expert.md` + `references/expert-debugging-mindset.md` (mindset), `references/expert-investigation-techniques.md` (techniques), `references/expert-hypothesis-testing.md` (hypothesis testing), `references/expert-verification-patterns.md` (verification), `references/expert-when-to-research.md` (when to research) | | Competing explanations, want them raced against each other | `references/trace-competing-hypotheses.md` | ## Workflow 1. **Stabilize the repro** — deterministic input, environment, steps. 2. **Minimize** — cut the repro to the smallest case that still fails. 3. **Hypothesize + instrument** — one hypothesis, one measurement, iterate. 4. **Trace to origin** — backward through the call chain to where bad state was born, not where it exploded. 5. **Fix the origin**, delete any symptomatic hacks the bug had attracted. 6. **Prove it** — original repro now passes, full suite re-run, evidence sealed via the `end-user-testing` skill. ## Anti-Patterns - "Fixed it" without a reproducer that flipped red→green → UNVERIFIED. - Adding `sleep`/retry/try-except around the symptom → symptomatic hack. - Testing three hypotheses in one edit → you learn nothing from the result. - Fixing where the error is raised instead of where the data went bad. ## Example **Input:** User: 'Tests fail only on Tuesdays — flaky, just retry them.' **Output:** No retries: reproduce (cron shifts TZ), minimize, hypothesis 'TZ-dependent date math' beats 'random flake' via instrumentation, root cause fixed in the date util, evidence attached. ## Skill calls | Calls | When | What it hands over | |-------|------|--------------------| | `end-user-testing` | evidence of reproduction + fix | fresh-evidence standard | Called by: `codebase-truth-audit`, `full-functional-audit`, `implement`, `stack-testing`, `proofpunk`.
Files in this package (12)
- SKILL.md 6 KB
- references/debug-like-expert.md 11 KB
- references/diagnose.md 7 KB
- references/expert-debugging-mindset.md 9 KB
- references/expert-hypothesis-testing.md 12 KB
- references/expert-investigation-techniques.md 10 KB
- references/expert-verification-patterns.md 11 KB
- references/expert-when-to-research.md 10 KB
- references/root-cause-tracing.md 7 KB
- references/trace-competing-hypotheses.md 10 KB
- scripts/find-polluter.sh 1 KB
- scripts/hitl-loop.template.sh 1 KB
Versions
| Repository | Score | Licence |
|---|---|---|
| This page · krzemienski/proofpunk | 100 | MIT |
| RobinBeraud/claude-qa-skills | 100 | MIT |
| plori-ai/skills | 100 | MIT |
| Mosin112/engineering-harness | 100 | MIT |
| reddygopalkrishna/developer-agent-skills | 100 | MIT |
| DavidZapataOh/overdrive | 90 | MIT |
| alisinadevelo/md-files | 90 | MIT |
Database snapshot: 13.11.2026 · package version 376b9f8b01aa (SHA-256 digest of the entire package)
Downloads in the last 30 days: 0 · ranking
Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.
Similar skills
- 100debugging
Finds and fixes bugs through systematic root cause analysis, stack trace interpretation, browser DevTools automation, CI/CD pipeline debugging, performance profiling, test pollution detection, and AI-powered error analysis. Use when the user asks to debug, fix a bug, investigate… - 90debugging
Systematic root-cause debugging: reproduce, investigate, hypothesize, fix with verification. Use when asked to "debug this", "fix this bug", "why is this failing", "troubleshoot", or mentions errors, stack traces, broken tests, flaky tests, regressions, or unexpected behavior. - 90debug-to-root-cause
Use whenever something is broken, flaky, or behaving unexpectedly — find the root cause systematically (reproduce, isolate, hypothesize, verify) and fix the cause, not the symptom. Never shotgun-edit. - 100root-cause-tracing
Systematically trace bugs backward through call stack to find original trigger. Use when errors occur deep in execution and you need to trace back to find the original trigger. - 100investigate
Systematic debugging with root cause investigation. Four phases: investigate, analyze, hypothesize, implement. Iron Law: no fixes without root cause. Use when asked to "debug this", "fix this bug", "why is this broken", "investigate this error", or "root cause analysis".… - 100investigate
Systematic debugging with root cause investigation. Four phases: investigate, analyze, hypothesize, implement. Iron Law: no fixes without root cause. Use when asked to "debug this", "fix this bug", "why is this broken", "investigate this error", or "root cause analysis".…