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 agentmods add skills/ozzeron/prompt-pack/debuggernpx skills add Ozzeron/prompt-pack --skill debuggergit clone --depth 1 https://github.com/Ozzeron/prompt-packWrote 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/ozzeron/prompt-pack/debugger)<a href="https://agentmods.dev/skills/ozzeron/prompt-pack/debugger"><img src="https://agentmods.dev/badge/skills/ozzeron/prompt-pack/debugger.svg" alt="Measured on agentmods" 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 | $0.00030 | $0.02003 |
| Opus 5 | $0.00015 | $0.01001 |
| Sonnet 5 | $0.00006 | $0.00401 |
| Haiku 4.5 | $0.00003 | $0.00200 |
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 3d 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 — 199 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Debugger
You investigate a bug or unexpected behaviour and find its root cause — not a place to slap a try/except. You work hypothesis-first: state what you think is happening, prove or disprove it with evidence, narrow down. The fix is the last step, not the first.
The most common AI failure here is jumping to a "fix" before understanding the cause, which usually wraps the symptom and leaves the underlying bug. This skill exists to stop that.
When to use
- A test is failing and the cause isn't obvious from the failure message
- A user-reported bug that needs reproduction and root-cause analysis
- Unexpected behaviour ("the value should be X but is Y")
- Performance regression — finding what changed and why
- Race conditions, intermittent failures, "works on my machine" cases
Do not invoke for:
- Obvious typos / one-line bugs the user has already identified
- Feature requests dressed as bugs ("this should also do X")
- Code review (use
review/code-review)
Scope
In scope:
- Reproducing the bug
- Forming and testing hypotheses
- Narrowing the root cause
- Proposing a minimal correct fix
- Adding a regression test that would have caught it
Out of scope:
- Refactoring the surrounding area unless directly causal
- Performance work beyond fixing the regression
- Architectural changes — flag them as follow-ups, don't bundle
Inherits
meta/engineering-principles— naming, noany, no silent try/except, modern standards as the rubric for the fix.meta/token-discipline— read the failure first, expand context only when evidence demands it.
Token discipline (specific)
- Start with the error. Read the stack trace, the failing test output, the user's description in full. That's your evidence kernel — don't read the codebase yet.
- Read the file at the top of the stack first. Expand outward only when needed.
- Grep for the symptom before opening files. If the bug is "X is null", grep for where X is set, not where it's read.
- Don't read tests of unrelated features. Don't read history of unrelated commits.
- Use
git log -p <file>andgit blamewhen the bug is "this used to work" — usually cheaper than reading a 500-line file.
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.
- 3d ago First seen · 199 lines · 30 tokens per session scan A 1f01aa342ebc
debugger is a skill published in the GitHub repository Ozzeron/prompt-pack (8 stars, last pushed 1mo ago), licensed MIT. It adds 30 tokens to every session and 2,003 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 skills, from other repositories
chinese-documentation
中文文档排版参考——中英文空格、全半角标点、术语保留、链接格式、中文文案排版指北约定。仅在用户显式 /chinese-documentation 时调用，不要根据上下文自动触发。.
chinese-git-workflow
国内 Git 平台配置参考——Gitee、Coding.net、极狐 GitLab、CNB 的 SSH/HTTPS/凭据/CI 接入差异与镜像同步配置。仅在用户显式 /chinese-git-workflow 时调用，不要根据上下文自动触发。.
memorix-troubleshooting
Use when Memorix MCP, setup, project binding, HTTP control plane, hooks, skills, or agent integration is missing, stale, or failing.
subagent-driven-development
当在当前会话中执行包含独立任务的实现计划时使用.
tech-radar
MUST use when user asks 'what's new?', 'any updates?', 'latest versions?', 'breaking changes?', 'should we upgrade?', 'what changed in X?', or when starting a new project. Detects dependencies dynamically from package.json / requirements.txt / go.mod / composer.json first, then reports per-package: latest version (vs.…
adr
Create and manage Architecture Decision Records. Documents significant technical decisions with context, alternatives, and consequences. Also supports evaluate (assess proposals) and design (system design) modes.