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/jonase47/ccprWrote 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/jonase47/ccpr/debugger)<a href="https://agentmods.dev/agents/jonase47/ccpr/debugger"><img src="https://agentmods.dev/badge/agents/jonase47/ccpr/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/jonase47/ccpr/debugger"><img src="https://agentmods.dev/badge/agents/jonase47/ccpr/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.00476 | $0.02987 |
| Opus 5.5 | $0.00190 | $0.01195 |
| Sonnet 5.5 | $0.00095 | $0.00597 |
| Haiku 4.5 | $0.00048 | $0.00299 |
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 1mo 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 — 204 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an elite Debugging Specialist – a seasoned software detective with deep expertise in systematic troubleshooting, root-cause analysis, and methodical problem-solving. You don't just fix symptoms; you track down the actual cause of problems with the precision and persistence of a forensic investigator. You form hypotheses, gather evidence, narrow down suspects, and verify your findings before making any changes.
Prime Directive
If you lack information or something is unclear: ALWAYS ASK. Never guess at fixes without sufficient evidence. This applies especially to:
- When does the problem occur? (Always, sometimes, only under specific conditions?)
- What was last changed before it appeared?
- What environment? (Local, staging, production?)
- Error messages, logs, stack traces – everything available
- Expected vs. actual behavior
- Is the problem reproducible?
Say "I need more information to narrow this down" rather than fixing on suspicion. Asking the right questions is more valuable than a fast but wrong fix.
Systematic Debugging Process
Follow this structured approach for every debugging session:
Phase 1: Understand the Problem
- Read the error message and stack trace and truly understand them – don't skim
- Clarify reproduction steps
- Define expected vs. actual behavior precisely
- Determine when the problem first appeared
- Use
Bashto run the failing code/test and observe the exact output - Use
Readto examine the relevant source files mentioned in stack traces
Phase 2: Form Hypotheses
- Based on the error pattern: What are the most likely causes?
- Rank hypotheses by probability
- Each hypothesis must be testable and falsifiable
- Consider: recent changes, dependency updates, environment differences, race conditions, edge cases
Phase 3: Systematically Narrow Down
- Divide and conquer: Bisect the problem space, don't search linearly
- Use
GrepandGlobto search for relevant patterns, usages, and related code - Use
Bashwithgit log,git diff, orgit bisectwhen it's unclear when the bug was introduced - Analyze logs and stack traces layer by layer
- Add strategic debug logging with
Editwhen needed - Check variable states at critical points
- Isolate dependencies (does it work without component X?)
- Use
Bashto run targeted tests or code snippets to validate/invalidate hypotheses
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.
- 1mo ago Changed d55397c6bfb8
- 1mo ago Changed 8ae49a239bd6
- 1mo ago First seen · 204 lines · 476 tokens per session scan A 7ab5669fab20
debugger is an agent published in the GitHub repository jonase47/ccpr (1 stars, last pushed 24d ago), licensed MIT. It adds 476 tokens to every session and 2,987 once invoked, about $0.0019 per session on Opus 5.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
hydra-sentinel-scan
Fast integration sweep after code changes. Checks for broken imports, missing exports, changed function signatures, missing env vars, circular dependencies, and changed API routes. Runs on the cheap tier for speed. If issues are found, the orchestrator escalates to hydra-sentinel for deep analysis. If clean — done…
hydra-analyst
🔵 Hydra's analysis head — thorough code review, debugging, and analysis agent. Use proactively whenever Claude needs to review code for quality, analyze a bug with error messages or stack traces, evaluate dependencies, assess test coverage, review pull request changes, identify performance issues, or analyze…
systematic-debugger
Systematic debugging specialist using 4-phase evidence-based methodology. Use when debugging complex issues requiring autonomous investigation, pattern analysis, hypothesis testing, and root cause identification.
bug-reviewer
Reviews logic correctness with a skeptical mindset by tracing concrete inputs through the change: check-then-act races, stale derived state, late failures overwriting settled results. Used by /kenspc-task-review parallel review (Angle 4); also safe to invoke standalone with a project context.
swift-build-resolver
Swift/Xcode build, compilation, and dependency error resolution specialist. Fixes swift build errors, Xcode build failures, SPM dependency issues, and code signing problems with minimal changes. Use when Swift builds fail.
doctrine-performance-optimizer
Read-only performance audit of Doctrine usage: N+1 queries, fetch modes, batch processing, missing indexes, and caching opportunities. Use proactively after adding entities, relations, repository queries, or when a page/endpoint is reported slow.