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 skills add mimukit/skills --skill debugkitgit clone --depth 1 https://github.com/mimukit/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/skills/mimukit/skills/debugkit)<a href="https://agentmods.dev/skills/mimukit/skills/debugkit"><img src="https://agentmods.dev/badge/skills/mimukit/skills/debugkit/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/skills/mimukit/skills/debugkit"><img src="https://agentmods.dev/badge/skills/mimukit/skills/debugkit.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.00103 | $0.05246 |
| Opus 5.5 | $0.00041 | $0.02098 |
| Sonnet 5.5 | $0.00021 | $0.01049 |
| Haiku 4.5 | $0.00010 | $0.00525 |
Grade A, and why
debugkit 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 4d 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 — 261 lines — stays where its author put it; the contents beside it link to each section on GitHub.
debugkit
The skill you reach for when something is broken and nobody knows why. Every other build skill takes intent as its input: a plan, an issue, a diff, a settled decision. debugkit takes a symptom, and its whole job is to turn that symptom into a cause somebody can act on.
It is a single procedure. There are no modes: the ritual runs the same way on every bug, and the branches inside it are decided by what the evidence allows rather than by what the user asked for.
It diagnoses, it never fixes
debugkit mutates the repo freely to learn, and reverts every one of those mutations. Log lines, bisects, config probes, commented-out branches are all fair game, and none of them survive the run. What survives is the cause, a failing reproduction (a red test stays on disk as the hand-off artifact), and a fix described rather than applied.
This boundary is not modesty, it is what makes the report trustworthy. A skill that finds the cause and also lands the cure has already committed to an answer, so what you read afterwards is a rationalization of an edit that already happened. Keeping the diagnosis and the change in separate hands means there is a moment in between where you can disagree.
Edit is present in this skill's tools precisely because probes edit tracked files. That makes the probe ledger load-bearing rather than decorative: it is the only thing standing between a debugging session and somebody's uncommitted work.
When this fires
"Debug this", "why is this failing", "find the root cause", "what's actually causing this", "this test is flaky", "it broke after the upgrade", "it worked yesterday and now it doesn't", "this endpoint got slower", "/debugkit".
Five boundaries, one line each:
- Not a code review. A review reads a diff for defects in work somebody just wrote. debugkit chases a symptom in code that already ran and misbehaved. A symptom in a diff nobody has executed is a review job, not a debugging one.
- Not a test plan. Planning how to verify a feature happens before the bug exists. debugkit starts after something has already gone wrong.
- Not a prototype. A throwaway spike answers an unsettled intent ("would this design hold up?"). debugkit probes to explain an observed failure. The tools look similar; the question is the opposite.
- Not a feature request. See the intake bar. Behaviour nobody ever built is missing, not broken.
- Not optimization. A performance regression is in scope: "it used to be fast" has a change to bisect and a clean before-and-after, so the ritual runs unmodified. "Make this faster" is not: it has no cause to find, only a profile to read, and every gate below presumes a working state that stopped working.
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.
- 4d ago Changed c9264d446b8e
- 21d ago Changed · +20 lines · -8 tokens per session ecd74f9be929
- 26d ago Changed e2daf36e0742
- 1mo ago First seen · 241 lines · 111 tokens per session scan A 6099852aac40
debugkit is a skill published in the GitHub repository mimukit/skills (2 stars, last pushed yesterday), licensed MIT. It adds 103 tokens to every session and 5,246 once invoked, about $0.0004 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 skills, from other repositories
monitoring-observability
OpenTelemetry, structured logging, distributed tracing, alerting, and dashboards. Use when instrumenting services, designing logs/traces/metrics, defining SLOs and alerts, or debugging production behavior from telemetry.
debug-systematic
Systematic 4-phase debugging methodology for complex, intermittent, or mysterious issues. Use when investigating bugs, race conditions, or unexplained failures.
thinking-scientific-method
When a symptom has several plausible causes, rank falsifiable hypotheses and run the cheapest discriminating observation first; prefer least-assumptive survivors only after evidence fit.
thinking-five-whys-plus
When a fault is localized and the proximate cause is known but the systemic root is not, chain evidence-linked whys with a counterfactual stop and a countermeasure.
thinking-map-territory
When a claim, doc, test, metric, or assumption conflicts with observed behavior, stop theorizing from the map and verify the live code or data; let territory overrule.
windows-ops
Comprehensive Windows workstation operations - diagnose slow boot, failing drives, BSOD crashes, startup bloat, runaway processes, event logs. Use for: Windows is slow, slow bootup, won't boot, blue screen, BSOD, kernel crash, drive failing, SMART errors, disk errors, Event 41, Event 129, storahci reset, BugCheck…