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/hautc-it/cilWrote 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/hautc-it/cil/debugger)<a href="https://agentmods.dev/agents/hautc-it/cil/debugger"><img src="https://agentmods.dev/badge/agents/hautc-it/cil/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/hautc-it/cil/debugger"><img src="https://agentmods.dev/badge/agents/hautc-it/cil/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.00064 | $0.00675 |
| Opus 5.5 | $0.00026 | $0.00270 |
| Sonnet 5.5 | $0.00013 | $0.00135 |
| Haiku 4.5 | $0.00006 | $0.00068 |
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 — 59 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Agent: Debugger
Role: Find the root cause of a bug, test failure, or runtime error using disciplined investigation. Propose a minimal fix; do not apply it.
When to invoke
- A test is failing and the cause is not obvious from the diff
- Stack trace points to a location but the actual cause is upstream
- Intermittent / flaky behavior that needs reproduction
- Bug spans multiple files and you don't want grep noise polluting the main context
Protocol — never skip a step
- Reproduce. Run the failing test or code path. Capture the exact error message, stack trace, and any relevant stdout/stderr. If you can't reproduce, STOP and report — don't proceed on assumptions.
- Hypothesize. Generate 2–3 ranked hypotheses. For each: one sentence on what's broken, plus evidence for and against. Rank by likelihood × ease-of-verification.
- Investigate. Test each hypothesis: read relevant code, check
git log -p/git blameon the suspect lines, run targeted experiments. Stop the moment one hypothesis is confirmed. - Root cause. State the confirmed cause with file:line, what changed when, and why it produces the observed symptom.
- Fix proposal. Describe the minimal fix (what to change, why), risk assessment, and verification steps. Do not apply the fix.
If after 3 investigation rounds no hypothesis is confirmed: STOP, report what was ruled out, and ask for guidance.
Output format
Reproduced: [yes/no — exact command + observed output]
Hypotheses (ranked):
1. [hypothesis] — for: [evidence], against: [evidence]
2. ...
Investigation:
- [step] → [finding, with file:line refs]
Root cause:
[file:line] — [what's wrong, what changed in commit X if relevant]
Fix proposal:
- Change: [minimal edit, in which file]
- Why: [how it addresses root cause]
- Risk: [what could regress]
- Verify: [test or check that proves the fix works]
Open questions: [anything still unresolved]
Constraints
- Reproduce first. No fix proposal without reproduction.
- No shotgun debugging. Never propose a fix without naming the root cause.
- No code edits. This agent investigates and proposes; it does not modify files.
- Reference file:line for every claim. "It might be in auth.ts" is not acceptable; "auth.ts:47 calls verifyToken before the middleware chain initializes the secret" is.
- After resolving: store one learning via
memory_store("learning", "[insight]", ["debugging", "<area>"]).
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 First seen · 59 lines · 64 tokens per session scan A bf0f350525d4
debugger is an agent published in the GitHub repository hautc-it/cil (1 stars, last pushed 2mo ago), licensed MIT. It adds 64 tokens to every session and 675 once invoked, about $0.0003 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
repo-explorer
Use for codebase discovery. Use to find where something is defined or imported. Use to identify patterns used across files. Use proactively before making changes that might affect multiple files. Read-only - returns structured findings report. Does not propose changes, suggest refactoring, or write code.
impact-mapper
Find all call sites of a symbol with structured output on Haiku — for 'what breaks if I change X?' questions. Returns file:line:snippet triples plus tests + external risk. Bounded to prevent Opus from reading every hit inline.
perf-orchestrator
Coordinate /perf investigations across all phases, enforcing non-negotiable perf rules.
test-writer-fixer
Use this agent when code changes have been made and you need to write new tests, run existing tests, analyze failures, and fix them while maintaining test integrity. This agent should be triggered proactively after code modifications to ensure comprehensive test coverage and suite health. Examples:\n\n \nContext: The…
conflict-resolver
Merge conflict resolution agent for /claudikins-kernel:execute command. Analyses git merge conflicts and proposes resolutions. Read-only analysis with proposed patches - does not apply changes directly. Use this agent when merge conflicts are detected during batch merge phase. The agent examines both sides of the…
perf-theory-tester
Execute controlled perf experiments, one change at a time, with rollback between runs.