bug-debugger
Skill4 starsChanged 27 days agoMITView on GitHub
Use when something is broken, a test fails, an error or stack trace appears, behavior is wrong or intermittent, a regression appeared after a change, or a fix attempt did not work — any language or framework.
In this repository30 other files it gives its agents.
- accessibility-auditSkill
- api-design-reviewSkill
- api-test-writerSkill
- architecture-diagramSkill
- bug-report-writerSkill
- changelog-writerSkill
- codebase-onboardingSkill
- code-reviewSkill
- database-schema-designSkill
- dependency-upgradeSkill
- design-handoff-specSkill
- design-reviewSkill
- dockerize-appSkill
- figma-design-compareSkill
- flaky-test-fixerSkill
- git-commit-writerSkill
- github-actions-ciSkill
- playwright-e2e-testsSkill
- prd-writerSkill
- proof-of-done-liteSkill
- readme-writerSkill
- refactor-plannerSkill
- security-auditSkill
- seo-auditSkill
- test-case-generatorSkill
- test-plan-writerSkill
- test-writerSkill
- ux-research-synthesisSkill
- ux-writingSkill
- web-performance-auditSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 19
Trace to the root: Ask why the bad value or state exists, and keep asking until you reach the place where it was first wrong.
- Distinctive: line 33
If the root cause is not found yet, report what was ruled out and the next experiment instead of guessing a fix.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Bug Debugger
Overview
Find the root cause before changing code. Reproduce, narrow down with evidence, fix the cause, and prove the fix with a test that failed before and passes after. Guess-and-patch loops waste more time than they save.
Method
- Reproduce. Get the exact command, input or steps that show the bug. Write it down. If it is intermittent, find the condition that makes it frequent (load, timing, data, order).
- Read the evidence fully. The whole error message and stack trace, the first error in the logs (not the last), the failing assertion's expected vs actual.
- Check what changed.
git log -p --since=<date> -- <path>, recent dependency updates, config or environment differences. For a known good commit,git bisect run <test command>. - Form one hypothesis that explains all the evidence. State it in one sentence.
- Test the hypothesis cheaply: a log line, a breakpoint, a minimal script, or a failing unit test. Confirm or discard it. Never change two things at once.
- Trace to the root. Ask why the bad value or state exists, and keep asking until you reach the place where it was first wrong. Fix there, not where it crashed.
- Write a failing test that reproduces the bug, then fix, then watch the test pass and run the full suite.
- Remove debugging code (temporary logs, prints, breakpoints).
Output contract
Bug: <one line>
Reproduce: <command or steps>
Root cause: <what was wrong, file:line, and why it happened>
Fix: <the change>
Proof: <test name> failed before, passes after; full suite: <result>If the root cause is not found yet, report what was ruled out and the next experiment instead of guessing a fix.
Quick reference
| Symptom | Look first at |
| Works locally, fails in CI or prod | Environment variables, versions, time zone, file paths, case sensitivity |
| Intermittent | Shared state, ordering, async without await, timeouts, caching |
| Wrong value | Where the value is first computed or transformed, not where it is displayed |
| Started after an update | Changelog of the updated dependency; lockfile diff |
undefined / null errors | The caller that passed it, and the data source |
| Slow or hanging | Unbounded loops, missing timeouts, locks, N+1 queries |
Common mistakes
- Changing code before reproducing the bug.
- Reading only the last line of a stack trace.
- Fixing the symptom (adding a null check) while the bad data still comes from upstream.
- Trying a third fix after two failed ones without new evidence. Step back and re-read the evidence.
- Declaring it fixed without a test that failed before the fix.
Made by Wageesha Tripathi · LinkedIn · Email · More skills
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.