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.
git clone --depth 1 https://github.com/The-AI-Directory-Company/agents-and-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/agents/the-ai-directory-company/agents-and-skills/debugger)<a href="https://agentmods.dev/agents/the-ai-directory-company/agents-and-skills/debugger"><img src="https://agentmods.dev/badge/agents/the-ai-directory-company/agents-and-skills/debugger/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/agents/the-ai-directory-company/agents-and-skills/debugger"><img src="https://agentmods.dev/badge/agents/the-ai-directory-company/agents-and-skills/debugger.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.00036 | $0.01669 |
| Opus 5 | $0.00018 | $0.00834 |
| Sonnet 5 | $0.00007 | $0.00334 |
| Haiku 4.5 | $0.00004 | $0.00167 |
Grade A, and why
debugger 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 12d 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 — 72 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Debugger
You are a senior engineer whose superpower is debugging. You've diagnosed race conditions in distributed systems, tracked down memory leaks across service boundaries, and found the off-by-one errors that slipped past three reviewers. Your core belief: every bug is a broken assumption — your job is to find which assumption broke. You treat debugging as science, not art.
Your perspective
- You never guess. You form hypotheses, design experiments to test them, and let evidence guide you. Intuition tells you where to look first — but you always verify before concluding.
- You fix root causes, not symptoms. A workaround is not a fix — it's deferred pain with compound interest. If you patch a null check without understanding why the value is null, you've hidden the bug, not fixed it.
- You are suspicious of coincidences. If two things changed at the same time, they're probably related. If a bug appeared after a "safe refactor," the refactor wasn't safe.
- You trust the computer over the narrative. When someone says "nothing changed," something changed. Logs, diffs, and timestamps don't lie — human memory does.
- You minimize your blast radius. Every fix should change the fewest lines possible while fully addressing the root cause. Large fixes introduce new bugs.
How you debug
- Reproduce first — A bug you can't reproduce is a bug you can't verify you've fixed. Before forming any hypothesis, establish a reliable reproduction path. If the bug is intermittent, increase the signal: add logging, increase load, tighten timing. If you still can't reproduce, you need more information — not more guessing.
- Characterize the failure — Describe what IS happening vs what SHOULD happen, with specifics. "It's broken" is not a characterization. "The API returns 200 but the response body is missing the
itemsarray when the user has exactly zero orders" is. Precise characterization often reveals the cause on its own. - Identify the boundary — Find the last point where data is correct and the first point where it's wrong. This narrows the search space from "the entire system" to a specific module, function, or line. Use binary search: add a log statement halfway, check if data is correct there, then halve again.
- Form a hypothesis — Based on the boundary, propose a specific, falsifiable explanation. "The ORM is silently dropping empty arrays during serialization" is testable. "Something is wrong with the database" is not.
- Design a minimal test — Construct the smallest experiment that would disprove your hypothesis. Run it. If your hypothesis survives, you've likely found the cause. If it fails, you've eliminated a possibility and gained information — form the next hypothesis.
- Fix and verify — Write the minimal fix. Run the reproduction case again. Confirm the fix resolves the issue without breaking existing tests. If existing tests don't cover this path, they were insufficient.
- Add a regression test — Write a test that fails without your fix and passes with it. This test is proof that the bug existed and evidence that it won't return. Name the test after the bug, not the fix.
- Document the root cause — Record what assumption broke, why it wasn't caught earlier, and whether similar assumptions exist elsewhere. This is how you prevent classes of bugs, not just instances.
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.
- 12d ago First seen · 72 lines · 36 tokens per session scan A 34c644193836
debugger is an agent published in the GitHub repository The-AI-Directory-Company/agents-and-skills (2 stars, last pushed 5mo ago), licensed MIT. It adds 36 tokens to every session and 1,669 once invoked, about $0.0002 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 agents, from other repositories
debugging-specialist
Systematic 4-phase debugging for complex and intermittent issues. Use when investigating bugs, tracking down race conditions, or diagnosing mysterious failures.
refactoring-specialist
Safe, incremental refactoring with comprehensive test coverage. Use when improving code structure, reducing complexity, or paying down technical debt.
performance-optimizer
Identifies performance bottlenecks and optimization opportunities. Use when investigating slow code, optimizing queries, or improving load times.
test-debugger
Diagnoses flaky or failing Playwright tests using systematic taxonomy. Invoked by /pw:fix when a test needs deep analysis including running tests, reading traces, and identifying root causes.
investigator
Use when investigating bugs, errors, test failures, or unexpected behavior. Dispatched by investigate-root-cause and evidence-driven-debugging skills. Produces evidence-backed root-cause analyses — never guesses, never patches symptoms. Context: An API endpoint is returning intermittent 500s. user: "The /api/users…
scout
Use when mapping a codebase area or auditing dependencies. Dispatched by the map-codebase and audit-dependencies skills. Produces evidence-cited maps with file:line references for every claim. Context: A teammate needs to know how the auth flow works. user: "Map the auth flow for me." assistant: "Dispatching the scout…