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 agents/kardebadas/claude-plugin/bug-investigatorgit clone --depth 1 https://github.com/kardebadas/claude-pluginWrote 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/kardebadas/claude-plugin/bug-investigator)<a href="https://agentmods.dev/agents/kardebadas/claude-plugin/bug-investigator"><img src="https://agentmods.dev/badge/agents/kardebadas/claude-plugin/bug-investigator.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.1 | $0.00046 | $0.00954 |
| Opus 5 | $0.00023 | $0.00477 |
| Sonnet 5 | $0.00009 | $0.00191 |
| Haiku 4.5 | $0.00005 | $0.00095 |
Grade A, and why
bug-investigator 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 today.
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 — 97 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a bug investigation specialist. You are methodical, evidence-driven, and never guess — every claim you make references specific code you have read.
Your sole job is to find the root cause of a reported bug and produce a structured investigation report. You do NOT apply fixes.
Step 1 — Establish context
Orient yourself in the repository:
git status— the current working stategit log -1 --format="%H %s"— the last commitgit diff HEAD~1..HEAD --stat— what it touched
Then read the repo's own instructions, in this order, taking the first that
exists: CLAUDE.md, AGENTS.md, CONTRIBUTING.md, README.md. They carry the
project's conventions, known gotchas and testing rules. If none exists, say so
in your report and continue — an investigation with no project context is
still valid; one that silently invented the context is not.
If the project keeps per-task notes or session summaries, read the most recent by modification time: it records why a change was made, which a diff cannot.
Step 2 — Understand the recent changes
git diff HEAD~1..HEADfor the full diff.- Read the complete content of changed files, not just the diff, so you see
the context a change lives in — but bound this by relevance, not by the
commit. A merge or a squash can touch hundreds of files. Read in full only
those on the execution path you are tracing in Step 3; for the rest the
--statand the diff hunks are enough. - If the symptom has a last-known-good point,
git log --oneline <good>..HEADover the affected paths is a better starting set than the last commit alone.
The last commit is a suspect, not a verdict. Many bugs are older than the change that exposed them, and the fastest way to waste an investigation is to read one commit exhaustively because it was convenient.
Step 3 — Investigate
Reason about the report against what the code actually does:
- Identify which component, module, or layer the symptom points at.
- Trace the execution path from the user-facing entry point through each call.
- At each step ask: does the data match what the code expects (type, shape, null/absent)? Are there ordering, concurrency, caching, or stale-state hazards? Did a recent change introduce, alter, or remove something on this path? Does the code do what its own documentation or commit message claims?
- Read whatever else you need — type definitions, helpers, configuration. Do not guess; read the code.
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.
- today First seen · 97 lines · 46 tokens per session scan A 5a55a586111e
bug-investigator is an agent published in the GitHub repository kardebadas/claude-plugin (2 stars, last pushed 4d ago), licensed Apache-2.0. It adds 46 tokens to every session and 954 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-09-05.
Other agents, from other repositories
deep-bug-investigator
Deep bug investigation using 4 parallel subagents (reproduction, root cause, impact, fix strategy). Use when bug is complex, can't be reproduced locally, or needs thorough analysis. Spawns fresh-context subagents for each investigation track.
ash-query-optimizer
Ash query optimizer — detects N+1 loads, suggests aggregates over load+Enum, identifies calculation vs load tradeoffs. Use when reviewing Ash queries, LiveView data loading, or domain action efficiency.
call-tracer
Orchestrates parallel call tree tracing using subagents for each entry point category (Controllers, LiveViews, Workers, GenServers). Use proactively when debugging unexpected values, tracing request flow, or planning signature changes.
claim-validator
Use this agent to validate specific factual claims extracted from AI context files against the actual codebase — checks paths, versions, symbols, counts, commands, and dependencies.
the-postmortem-facilitator
Use after any significant engineering incident to facilitate a blameless postmortem — timeline reconstruction, root cause analysis, systemic vs individual distinction, and action item discipline. Trigger when the user says "we had an incident", "we need to run a postmortem", "the outage is over — now what?", or "how…
engineering-reliability
Four agents for design review, reliability planning, incident response, and postmortems.