Debugging skills for AI coding agents make the agent preserve evidence, test a stated hypothesis, and verify the original failure before it proposes a fix. This guide compares eight skills across application bugs, complex investigations, feedback-loop construction, runtime debugging, intermittent issues, and performance regressions.
The differentiator is the evidence gate. A useful skill tells the agent what to capture, which explanation to test, what counts as a regression guard, and when another patch is no longer a responsible next step. The entries below come from their source SKILL.md files and one skills.sh install-count snapshot dated August 23, 2026.
How this list was picked
Read at the source. We pulled each skill's SKILL.md from its repository and wrote every description from what the skill actually instructs an agent to do.
Adoption-weighted. Install counts are an August 23, 2026 snapshot from the skills.sh registry, the same registry the LazySkills TUI searches.
Full loop coverage. Broad application failures, complex investigations, feedback loops, runtime debugging, intermittent behavior, and performance regressions each get a distinct entry.
One job per pick. The scope is explicit. Broad root-cause workflows come first, followed by investigation methods, complex-investigation coordination, feedback-loop construction, runtime debugging, intermittent issues, and performance regressions.
Debugging skills at a glance
A comparative index of the top picks. Click any card to navigate directly to its detailed review.
Install counts from the skills.sh registry, snapshot taken August 23, 2026.
Application Bugs and Test Failures
Start here when an application behaves unexpectedly or a test fails. These broad workflows put evidence ahead of a plausible patch and keep the investigation tied to the original failure.
systematic-debugging
233.9K installs obra (Jesse Vincent)
Best for: Any bug, test failure, or unexpected behavior before a fix is proposed
systematic-debugging begins with a mandatory Root Cause Investigation. The agent gathers the complete failure, establishes a reproduction, checks relevant changes, and records what the system actually does before it offers a fix. That gate matters when the symptom looks familiar, because a familiar symptom can still have a different cause in the current codebase.
The remaining phases are Pattern Analysis, Hypothesis and Testing, and Implementation. Each phase has to earn the next one with evidence. The source also gives the agent a hard stop: after three failed fix attempts, stop and question the architecture with a human. That rule turns repeated patches into a signal about the design rather than an invitation to try a fourth guess.
Mandatory Root Cause Investigation before fixes
Four named phases with evidence gates between them
Trigger covers bugs, test failures, and unexpected behavior
Three failed attempts trigger an architecture question with a human
Best for: Failing tests, broken builds, unexpected errors, and behavior that differs from expectation
debugging-and-error-recovery opens with a Stop-the-Line Rule. The agent preserves the evidence before triage, which protects the original error, state, and surrounding context from being overwritten by eager cleanup. The workflow covers failures that depend on timing, environment, state, or random input, where a clean rerun can erase the useful part of the incident.
Recovery has to prove two things. A regression guard protects the repaired behavior, and the original scenario is run again to confirm that the reported failure has actually changed. This makes the skill useful after a build or test failure as well as during an investigation that has already produced a temporary recovery.
Stop-the-Line Rule preserves evidence before triage
Covers timing, environment, state, and random failures
Pairs a regression guard with the original scenario
Applies to tests, builds, errors, and expectation mismatches
Once the failure is captured, the investigation needs a way to compare causes against observations. These skills supply repeatable methods for difficult runtime, performance, and production cases.
debugging-strategies
11.4K installs wshobson
Best for: Bugs, performance issues, unexpected behavior, and production incidents
debugging-strategies gives an agent a loop for turning observations into tests of competing explanations: observe, hypothesize, experiment, analyze, and repeat. Its scope reaches beyond a single failing assertion. The source covers git bisect for locating a change, differential comparison for finding meaningful differences, tracing for following execution, and heap snapshots for memory investigations.
The checklists make the scope practical. Intermittent failures, performance problems, and production incidents each get their own investigation path, so the agent has a prompt to preserve the details that distinguish one class of failure from another. Choose it when the work needs a technique guide, then keep every experiment connected to a stated hypothesis.
Use this specialised workflow when a complex defect has several plausible causes and enough independent investigation paths to justify coordination.
parallel-debugging
8.2K installs wshobson
Best for: Complex issues with several plausible causes and parallel agent investigations
parallel-debugging is for specialised multi-agent work. It frames a complex issue as an Analysis of Competing Hypotheses, then gives separate agents room to investigate plausible causes without collapsing their reasoning into one early guess. The useful output is evidence that another agent can inspect, including file and line citations and a confidence tier for each conclusion.
The workflow includes a four-step arbitration phase before the fix is validated. That boundary keeps parallel exploration from becoming parallel patching. Use this skill when the investigation has enough independent paths to justify coordination. A single reproducible application bug has a smaller context and belongs with a standard debugging workflow.
Specialised workflow for parallel agent investigations
Analysis of Competing Hypotheses structures the search
Findings require file:line citations and confidence tiers
Four-step arbitration happens before fix validation
These skills make a debugging run produce better evidence. Choose a tight reproduction loop or a stack-trace command reference when the next hypothesis needs a reliable red signal.
diagnosing-bugs
453.7K installs Matt Pocock
Best for: Bugs that need a deterministic, agent-runnable red loop before investigation
diagnosing-bugs builds a tight feedback loop before the agent spends time on hypotheses. It minimizes the reproduction until a deterministic red loop can run from the agent's context, then selects an evidence path suited to the failure: tests, a curl or CLI fixture, a browser script, HAR replay, a harness, fuzzing, bisection, differential comparison, or a human-in-the-loop script.
The loop stays useful only when it is safe to repeat. The skill requires cleanup and redaction after instrumentation or fixture work, so temporary evidence does not become a source of noise or leaked data. Choose it when reducing the failure to a reliable, agent-runnable signal is the main debugging job.
Minimizes a failure before forming hypotheses
Requires a deterministic agent-runnable red loop
Supports tests, fixtures, browser scripts, HAR replay, and harnesses
Includes fuzzing, bisection, differential checks, and HITL scripts
Best for: Stack traces, logs, and debugger commands across Python, Node, and Go
debugging-wizard organizes a stack-trace or log investigation as Reproduce, Isolate, Hypothesize and Test, Fix, and Prevent. Its command reference gives the agent concrete paths for Python pdb, Node --inspect-brk, Go delve, and git bisect, so the investigation can move from a captured symptom to a focused runtime check.
The workflow sets boundaries around the investigation. It bans untested guesses, multiple simultaneous changes, and debugging leftovers. Use it when the agent has a trace or log and needs a language-aware debugger command reference that keeps reproduction, isolation, verification, and prevention connected.
Reproduce, Isolate, Hypothesize and Test, Fix, Prevent
Python pdb, Node --inspect-brk, and Go delve references
Use these focused workflows when the failure pattern is the main clue. One captures timing-dependent behavior; the other compares a measured baseline with a post-change regression.
intermittent-issue-debugging
400 installs aj-geddes
Best for: Flaky, sporadic, and timing-dependent bugs
intermittent-issue-debugging gives flaky and sporadic bugs a capture plan. It adds timestamped and error-type logs, then carries correlation IDs across asynchronous chains so the agent can reconstruct the sequence around a failure that does not appear on every run.
The source organizes the work into capture, investigation, and prevention guides. Start by collecting enough context to distinguish timing, ordering, and state effects. Use the investigation guidance to compare successful and failed runs, then turn the observed condition into prevention checks that keep the intermittent failure visible.
Targets flaky, sporadic, and timing-dependent bugs
Adds timestamped and error-type logging
Carries correlation IDs across async chains
Separates capture, investigation, and prevention guidance
Best for: Diagnosing performance regressions against a measured baseline
performance-regression-debugging treats a slowdown as a comparison problem. It establishes baselines for response time, TTI, LCP, memory, and bundle size, then profiles and diffs the relevant commits to locate the change that moved a metric.
The workflow continues through fixing, verification, and prevention. Compare the repaired build with the original baseline, record the evidence for the improvement, and add a guard that keeps the regression visible. Choose it when a performance claim needs measurements before and after a change rather than a hunch about which code is slow.
Baselines response time, TTI, LCP, memory, and bundle size
Profiles and diffs performance across commits
Connects diagnosis with fixing and verification
Adds prevention guidance after the regression is resolved
Use this order when an agent reports a problem. The stages answer different questions, so picking the wrong one can produce a polished answer to the wrong problem.
1.Use testing/TDD when the behavior is still being specified or changed. The testing guide gives the agent a way to define the expected behavior and create a check for it. A failing test then becomes input for debugging.
2.Use debugging when an existing test, build, or runtime scenario fails, or when observed behavior differs from the expectation. Start with systematic-debugging. Choose debugging-and-error-recovery when preserving the original failure and verifying recovery are central.
3.Use code review after a change exists and you need an independent check against its requirements, standards, or architecture. Review can find a defect in a diff; debugging explains a failure. A review finding that you cannot explain should return to the debugging gate.
Choose the evidence loop that fits
Start with broad reproduction and triage, then choose the focused workflow that can produce the next useful signal. The right choice depends on whether the investigation needs a smaller reproduction, a debugger command, timing evidence, or a measured performance comparison.
Loopdiagnosing-bugs builds a deterministic agent-runnable red loop and minimizes the reproduction before the agent forms hypotheses. Choose it when a test, fixture, browser script, HAR replay, harness, fuzzing run, bisection, differential check, or HITL script can expose the failure.
Tracedebugging-wizard fits stack traces and logs when the agent needs a command reference for Python pdb, Node --inspect-brk, Go delve, or git bisect. Its Reproduce, Isolate, Hypothesize and Test, Fix, Prevent sequence keeps the debugger run verifiable.
Flakyintermittent-issue-debugging fits sporadic, timing-dependent bugs. Use timestamped and error-type logs plus correlation IDs across asynchronous chains, then move from capture to investigation and prevention.
Metricsperformance-regression-debugging fits a suspected slowdown. Compare response time, TTI, LCP, memory, and bundle-size baselines with post-change measurements, then profile and diff the commits before fixing.
When the failure will not reproduce
A clean rerun is evidence about one run. It does not explain the run that failed. Start by preserving the original error, logs, state, timing, environment, and input that the agent can still access. The Stop-the-Line Rule in debugging-and-error-recovery is built for this moment: protect the evidence before changing the system or restarting the investigation.
Next, state what can vary. Timing points toward ordering or races; environment points toward dependency, configuration, or machine differences; state points toward data and lifecycle; random input points toward an input-dependent path. The point is to turn intermittent into a testable description. The debugging-strategies checklist supplies experiments for intermittent failures, while its tracing, differential comparison, and history tools help narrow the changing condition.
A repair still needs two checks: a regression guard that protects the discovered behavior and the original scenario run again. If neither check can be made meaningful, document the uncertainty and ask for a human decision about observability or test isolation before patching.
When to stop patching and question the architecture
Repeated failed fixes change the status of the work. The agent has learned that the current explanation does not account for the evidence, so another local edit needs a new justification. systematic-debugging sets a concrete stop condition after three failed fix attempts: stop and question the architecture with a human.
Bring the evidence to that conversation. Include the original failure, the hypotheses tested, the files and lines changed, what each attempt changed in the observed behavior, and the remaining uncertainty. A boundary that loses state, a lifecycle that hides ordering, or a shared assumption that crosses components can make a local patch look correct while leaving the cause intact. The architecture question is whether the system gives the agent a boundary where the behavior can be observed and tested.
For a complex issue with several plausible causes, use parallel-debugging to separate investigations. Require file:line citations and confidence tiers before arbitration. A workflow problem in the coding agent itself needs its own operational investigation rather than an application-debugging card.
Keep them under control with LazySkills
Evidence gates only work if the skills that define them are visible to your agent. LazySkills is a terminal UI that scans your machine, shows every installed skill with per-agent visibility, diagnoses broken configurations, and searches the same registry this page is built on.
How do I stop an AI coding agent from guessing fixes?
Put an evidence gate before implementation. systematic-debugging requires root cause investigation, pattern analysis, and a tested hypothesis before a fix. Tell the agent to preserve the complete failure, state what it observed, and name the experiment that would distinguish its hypothesis from another cause. If three fixes fail, stop the loop and question the architecture with a human.
What should an AI agent do when the bug cannot be reproduced?
Preserve the original evidence and classify what can vary: timing, state, ordering, or input. intermittent-issue-debugging supplies timestamped and error-type logs plus correlation IDs across asynchronous chains. Keep the original scenario available, compare successful and failed runs, and turn the observed condition into a prevention check instead of treating one clean rerun as proof.
Do testing, debugging, and code review use the same skill?
They are separate jobs. Testing and TDD skills shape how an agent creates and runs verification. Debugging skills investigate a known failure and require evidence before a repair. Code review skills inspect a completed change against its requirements and standards. Link them in that order when the task needs the full loop: test, investigate failures, then review the resulting diff.
When should an AI agent stop retrying fixes?
Stop when repeated attempts have not changed the evidence or when the same failure returns after each patch. systematic-debugging gives a concrete threshold: after three failed fix attempts, stop and question the architecture with a human. Preserve the failed attempts, explain the remaining uncertainty, and decide whether the design needs a different boundary.
When is parallel debugging worth using?
Use parallel-debugging for a complex issue with multiple plausible causes and enough independent investigation paths to keep agents productive. Require file and line citations, confidence tiers, and arbitration before validating a fix. A small, reproducible failure usually needs one focused investigation instead.
How can I confirm that a performance change is a regression?
Measure a baseline before calling the change a regression. performance-regression-debugging compares response time, TTI, LCP, memory, and bundle-size baselines with post-change results, then profiles and diffs commits to locate the shift. Verify the repair against the original baseline and add a prevention check so the metric stays visible.
svgdiagram.ai 
