diagnosing-bugs
Helps your agent find and fix difficult code errors. It's useful when something isn't working as expected or is slow. This ensures software runs correctly.
What it does
This tool helps find the cause of difficult bugs in computer programs. It creates a testing loop that clearly shows when the bug happens, making it easier to fix.
When to use it
- ✓When a program shows an unexpected error.
- ✓When a program is slower than usual.
- ✓When something in the program isn't working as expected.
Example of what to ask your AI
“Diagnose why my code is failing when I try to log in.”
Want more? Open the sections below.
How to use
The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.
Skill link
Ready-to-paste message
How it works
First, it creates a quick test that fails exactly when the bug occurs. Then, it simplifies the problem to the minimum needed for the bug to appear. Finally, it suggests possible causes for the bug.
Installation
Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.
In the terminal (Claude Code, Codex, Cursor), in your project folder:
npx skills add sickn33/agentic-awesome-skills --skill diagnosing-bugsOr download just the file:
curl -L https://raw.githubusercontent.com/sickn33/agentic-awesome-skills/main/plugins/agentic-awesome-skills-claude/skills/diagnosing-bugs/SKILL.md -o SKILL.mdTechnical content (original SKILL.md)
Original text by the author, straight from GitHub.
Diagnosing Bugs
When to Use
Use when this workflow matches the user request: Use this skill for its documented workflow.
Source: mattpocock/skills (MIT).
A discipline for hard bugs. Skip phases only when explicitly justified.
When exploring the codebase, read CONTEXT.md (if it exists) to get a clear mental model of the relevant modules, and check ADRs in the area you're touching.
Phase 1 — Build a feedback loop
This is the skill. Everything else is mechanical. If you have a tight pass/fail signal for the bug — one that goes red on this bug — you will find the cause; bisection, hypothesis-testing, and instrumentation all just consume it. If you don't have one, no amount of staring at code will save you.
Spend disproportionate effort here. Be aggressive. Be creative. Refuse to give up.
Ways to construct one — try them in roughly this order
- Failing test at whatever seam reaches the bug — unit, integration, e2e.
- Curl / HTTP script against a running dev server.
- CLI invocation with a fixture input, diffing stdout against a known-good snapshot.
- Headless browser script (Playwright / Puppeteer) — drives the UI, asserts on DOM/console/network.
- Replay a captured trace. Save a real network request / payload / event log to disk; replay it through the code path in isolation.
- Throwaway harness. Spin up a minimal subset of the system (one service, mocked deps) that exercises the bug code path with a single function call.
- Property / fuzz loop. If the bug is "sometimes wrong output", run 1000 random inputs and look for the failure mode.
- Bisection harness. If the bug appeared between two known states (commit, dataset, version), automate "boot at state X, check, repeat" so you can
git bisect runit. - Differential loop. Run the same input through old-version vs new-version (or two configs) and diff outputs.
- HITL bash script. Last resort. If a human must click, drive them with
scripts/hitl-loop.template.shso the loop is still structured. Captured output feeds back to you.
Build the right feedback loop, and the bug is 90% fixed.
Tighten the loop
Treat the loop as a product. Once you have a loop, tighten it:
- Can I make it faster? (Cache setup, skip unrelated init, narrow the test scope.)
- Can I make the signal sharper? (Assert on the specific symptom, not "didn't crash".)
- Can I make it more deterministic? (Pin time, seed RNG, isolate filesystem, freeze network.)
A 30-second flaky loop is barely better than no loop; a 2-second deterministic one is tight — a debugging superpower.
Non-deterministic bugs
The goal is not a clean repro but a higher reproduction rate. Loop the trigger 100×, parallelise, add stress, narrow timing windows, inject sleeps. A 50%-flake bug is debuggable; 1% is not — keep raising the rate until it's debuggable.
When you genuinely cannot build a loop
Stop and say so explicitly. List what you tried. Ask the user for: (a) access to whatever environment reproduces it, (b) a captured artifact (HAR file, log dump, core dump, screen recording with timestamps), or (c) permission to add temporary production instrumentation. Do not proceed to hypothesise without a loop.
Completion criterion — a tight loop that goes red
Phase 1 is done when the loop is tight and red-capable: you can name one command — a script path, a test invocation, a curl — that you have already run at least once (paste the invocation and its output), and that is:
- Red-capable — it drives the actual bug code path and asserts the user's exact symptom, so it can go red on this bug and green once fixed. Not "runs without erroring" — it must be able to catch this specific bug.
- Deterministic — same verdict every run (flaky bugs: a pinned, high reproduction rate, per above).
- Fast — seconds, not minutes.
- Agent-runnable — you can run it unattended; a human in the loop only via
scripts/hitl-loop.template.sh.
If you catch yourself reading code to build a theory before this command exists, stop — jumping straight to a hypothesis is the exact failure this skill prevents. No red-capable command, no Phase 2.
Phase 2 — Reproduce + minimise
Run the loop. Watch it go red — the bug appears.
Confirm:
…
FAQ
What is a 'feedback loop'?
It's a test you can run repeatedly to see if the bug still happens. It needs to be fast and clearly show whether the bug is present or not.
What if the bug only happens sometimes?
The tool tries to increase the chance of the bug appearing by repeating the test many times or adding more 'stress' to the program, until it's easy to reproduce.
What if I can't create a test that shows the bug?
The tool suggests stopping and asking the user for more information, like access to the environment where the bug occurs or log files.
Details
Original description by the author
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.
Popularity
- GitHub stars
- 48k
- Ranking position
- #2841
- License
- MIT
- Updated
- 10/15/2026
Comments
- …
More skills from this repository
00-andruia-consultant
Helps your agent start or improve AI projects. It analyzes code, suggests tools, and creates action plans in Spanish.
sickn33/agentic-awesome-skills
007
Lets your agent perform security audits and threat modeling. It's useful for protecting projects against attacks and vulnerabilities.
sickn33/agentic-awesome-skills
10-andruia-skill-smith
Helps your agent create or improve AI tools. It defines how tools work, writes documentation, and validates the structure.
sickn33/agentic-awesome-skills
20-andruia-niche-intelligence
Lets your agent create a summary about a specific industry. It's useful for understanding the context, rules, usage patterns, and risks of a project, using reliable sources.
sickn33/agentic-awesome-skills
Similar skills
cpp-testing
Makes your agent write and improve tests for C++ code. It helps set up testing tools and fix errors.
affaan-m/ECC
csharp-testing
Helps your agent create tests for C# and .NET code. It uses best practices to ensure tests are efficient and reliable.
affaan-m/ECC
django-tdd
Enables your agent to apply testing strategies for Django with pytest-django and TDD. It's useful for writing robust tests and ensuring code quality, especially for DRF APIs.
affaan-m/ECC