Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add vignesh2027/AI-AGENT-SKILLS --skill debugging-and-error-recoverygit clone --depth 1 https://github.com/vignesh2027/AI-AGENT-SKILLSWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/vignesh2027/ai-agent-skills/debugging-and-error-recovery)<a href="https://agentmods.dev/skills/vignesh2027/ai-agent-skills/debugging-and-error-recovery"><img src="https://agentmods.dev/badge/skills/vignesh2027/ai-agent-skills/debugging-and-error-recovery/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/vignesh2027/ai-agent-skills/debugging-and-error-recovery"><img src="https://agentmods.dev/badge/skills/vignesh2027/ai-agent-skills/debugging-and-error-recovery.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00020 | $0.00514 |
| Opus 5 | $0.00010 | $0.00257 |
| Sonnet 5 | $0.00004 | $0.00103 |
| Haiku 4.5 | $0.00002 | $0.00051 |
Grade A, and why
debugging-and-error-recovery scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 10d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 58 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Overview
Debugging is a skill, not luck. Effective debugging is systematic: form a hypothesis, design a minimal test, validate or falsify, repeat. Random changes are not debugging — they are gambling.
When to Use
- When a test is failing and the cause is unclear
- When behavior in production differs from behavior in development
- When you've been debugging the same issue for more than 30 minutes
Process
Step 1: Reproduce reliably
Before investigating: reproduce the issue consistently. If you can't reproduce it, you can't verify you've fixed it.
Step 2: Gather evidence
Read the full error message (not just the last line). Check: logs, stack traces, metrics, recent changes. What changed recently?
Step 3: Form a hypothesis
Write down a specific, falsifiable hypothesis: "I believe the error is caused by X because of Y."
Step 4: Isolate the smallest reproduction
Create the simplest possible test case that reproduces the issue. Remove everything that is not necessary for the bug to manifest.
Step 5: Test the hypothesis
Design an experiment that will either confirm or falsify your hypothesis. This often means: add a log statement, write a unit test, or add an assertion.
Step 6: Falsify or confirm
If the evidence falsifies your hypothesis: form a new hypothesis. If it confirms: find the root cause (not just the symptom).
Step 7: Fix and verify
Fix the root cause, not the symptom. Verify the fix: the minimal reproduction must no longer reproduce. The full test suite must pass.
Step 8: Write a regression test
Write a test that would have caught this bug. Add it to the test suite.
Anti-Rationalizations
"I'll try changing this and see if it works" This is not debugging. Form a hypothesis first.
"The bug is intermittent — I can't reproduce it" Intermittent bugs have causes. Add logging and wait for the next occurrence. Or: analyze the conditions under which it occurred and stress test those conditions.
Verification Requirements
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 10d ago First seen · 58 lines · 20 tokens per session scan A c04d21ae0e34
debugging-and-error-recovery is a skill published in the GitHub repository vignesh2027/AI-AGENT-SKILLS (2 stars, last pushed 12d ago), licensed MIT. It adds 20 tokens to every session and 514 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
cce-routing
Use Cursor Bridge's read-only cursorcontextengine for unfamiliar project understanding when the exact code location is unknown or the task requires tracing behavior, symbols, callers and callees, data flow, registrations, interface implementations, ownership boundaries, or cross-module relationships. Trigger for…
gh-fix-ci
Use when a user asks to debug or fix failing GitHub PR checks that run in GitHub Actions; use gh to inspect checks and logs, summarize failure context, draft a fix plan, and implement only after explicit approval. Treat external providers (for example Buildkite) as out of scope and report only the details URL.
sentry
Query Sentry organizations, projects, and unresolved issues/errors via the Sentry API. Use when the user asks about Sentry errors, issues, or projects.
signoz
Query observability (services, traces, logs, metrics) from a SigNoz instance via its API. Use when the user asks about app performance, errors, latency, or telemetry in SigNoz.
fix-default
A default procedure for handling bug fixes, organised as a three-step scan and a CP process. The input does not explain what the three steps or CP process contain.
rel-ai-debugging
Use when repository behavior is reproducibly wrong and needs causal diagnosis or repair, including errors, broken tests, crashes, regressions, failed contracts, or incorrect runtime behavior. Do not use for general audits or final verification when no active defect is being diagnosed.