Getting it into your agent
This one installs as part of its plugin. Adding the marketplace and installing the plugin brings it with everything else the plugin ships.
/plugin marketplace add svy04/ballast/plugin install ballastWrote 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/svy04/ballast/doctor)<a href="https://agentmods.dev/skills/svy04/ballast/doctor"><img src="https://agentmods.dev/badge/skills/svy04/ballast/doctor/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/svy04/ballast/doctor"><img src="https://agentmods.dev/badge/skills/svy04/ballast/doctor.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.00052 | $0.00844 |
| Opus 5 | $0.00026 | $0.00422 |
| Sonnet 5 | $0.00010 | $0.00169 |
| Haiku 4.5 | $0.00005 | $0.00084 |
Grade A, and why
doctor 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 10d 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 — 36 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Doctor — silence diagnosed, not trusted
The failure mode this skill exists for: a dead hook looks exactly like a quiet one. Doctor tells them apart, and reports in four states — healthy, off (disabled on purpose), broken (something the user relies on is not happening), unchecked (could not be verified). Three rules govern the report:
- Off is not a problem.
BALLAST_DISABLE=1orBALLAST_QUIET=1set on purpose gets reported as "off — as configured", never as a failure. - Never hide what you could not check. An "unchecked" row is information; silently skipping it is not.
- "Fixed" is claimed only after re-running the check that failed.
Checks, in order
- node exists, version ≥ 18 —
node --version. Missing node means every other check is moot; the fix (install node) is the user's, with a link. - Hook wiring — the plugin's
hooks/hooks.jsonparses and its script file exists. Find the plugin root viaCLAUDE_PLUGIN_ROOTorclaude plugin list. - Live fire — run the engine's status line for real:
node .../ballast-rules.mjs --status. The line appearing IS the proof; a wiring check alone is not (a manifest that parses can still fail to load — that was ballast's own 0.8.1 bug). - Off switches —
BALLAST_DISABLE,BALLAST_QUIET,BALLAST_NO_LOGset? Report as "off — as configured" and ask nothing. - Catalog presence — user (
~/.claude/ballast.rules.json) and project paths. Neither existing is not broken; it is "before first setup" — point at the setup skill. - Catalog health — run
node .../ballast-rules.mjs --check. It flags parse failures, rules that can never fire, patterns that do not compile, duplicate ids, and budget overruns (20+ rules, 3+ always-on). Translate its findings to plain words: "rule 3's detection condition is broken", not the regex error. - Delivery history — run
node .../ballast-rules.mjs --report. An empty log with an old install suggests keywords in the wrong language or a hook that died some time ago; cross-check with check 3. - Language pairing — keywords in one language while the user chats in another is the top silent killer of rules. Compare catalog keywords against the language of the current conversation.
- Memory files (optional) —
memory/absent is "off — brain-init not used", not a failure. If present, confirmDECISIONS.mdexists. - Self-instrument — say whether every check above actually ran. A doctor that skipped half its checks and printed "healthy" is the exact disease it treats.
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.
- 10d ago First seen · 36 lines · 52 tokens per session scan A 2e5fd4c49f40
doctor is a skill published in the GitHub repository svy04/ballast (71 stars, last pushed 15d ago), licensed MIT. It adds 52 tokens to every session and 844 once invoked, about $0.0003 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-30.
Other skills, from other repositories
developer-cognitive-instincts
COGNITIVE INSTINCTS — extracted from roles.json deepPrompt for developer.
developer-anti-patterns-to-avoid
ANTI-PATTERNS TO AVOID — extracted from roles.json deepPrompt for developer.
developer-debugging-methodology
DEBUGGING METHODOLOGY — extracted from roles.json deepPrompt for developer.
developer-performance-instincts
PERFORMANCE INSTINCTS — extracted from roles.json deepPrompt for developer.
show-me-proof
A skill for collecting concrete proof that a coding task was completed, such as changed files, test commands, logs, and remaining risks.
systematic-debugging
A step-by-step method for investigating and fixing software bugs: reproduce the problem, find its root cause, assess what it may affect, fix it, and test again.