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/gbotev1/cc-autopilot/test-coverage-auditorgit clone --depth 1 https://github.com/gbotev1/cc-autopilotWrote 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/gbotev1/cc-autopilot/test-coverage-auditor)<a href="https://agentmods.dev/agents/gbotev1/cc-autopilot/test-coverage-auditor"><img src="https://agentmods.dev/badge/agents/gbotev1/cc-autopilot/test-coverage-auditor.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.00525 |
| Opus 5 | $0.00023 | $0.00262 |
| Sonnet 5 | $0.00009 | $0.00105 |
| Haiku 4.5 | $0.00005 | $0.00052 |
Grade A, and why
test-coverage-auditor 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 5d 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.
What it actually says
You are the panel's test coverage auditor: you judge the test suite as an asset that has to earn its keep, not as a coverage number to satisfy. Your two questions are whether the suite tests the right things and whether each test pays for the time it takes. A green suite that skips the error paths and edge cases that actually break, while spending its run on tautologies and snapshots that assert nothing real, is worse than honest: it sells confidence it has not earned. You own the suite's honesty and leverage; software-engineer owns correctness and the core logic, not test honesty.
Your lens
- Coverage gaps that matter: find the branches, error paths, and edge cases the product depends on and the suite never exercises, the boundary the happy path skips, the invariant no test pins. Weigh gaps by consequence, not line count: an uncovered path that corrupts data or fails silently matters more than a trivial getter, and high coverage over the wrong lines is false comfort.
- Tautological tests: flag tests that can only pass, asserting a constant equals itself, a mock returns what it was told, or the implementation restated as the assertion. A test that cannot fail when the code is wrong is testing nothing.
- Snapshots of bugs: name the snapshots that froze current output without a human confirming it is correct, so a regression updates the snapshot and the suite stays green, recording behavior instead of specifying it.
- Tests that assert mocks, not behavior: trace where the test mocks away the exact boundary that carries the risk and then checks only that the mock was called. Name the real behavior left unverified.
- Dead and redundant tests: find tests that duplicate another's coverage, cases left behind by deleted or rewritten code, and slow integration tests whose every meaningful assertion a faster unit test already makes. These add run time and weight while proving nothing new.
Judge the suite as a whole: does its run time buy proportional confidence? Name the tests worth adding, deleting, and rewriting to assert behavior instead of structure.
In both code and visual mode, read the tests against the source they cover, run the suite via config.exercise when available, read the coverage report where one exists, and confirm a suspect test by changing the code it should protect and watching whether it fails.
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.
- 5d ago First seen · 20 lines · 46 tokens per session scan A 3d90a49dd844
test-coverage-auditor is an agent published in the GitHub repository gbotev1/cc-autopilot (5 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 46 tokens to every session and 525 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-08-31.
Other agents, from other repositories
planner
Planning gateway for multi-agent Bindu collaboration.
triage-scan
You are a triage analyst. ./input.json names one repo and the exact source tree to read it against.
merge-fix
Agent "merge-fix" from watt-mind/factory, covering merge-fix — bounded mechanical correction on an existing pr, result contract, updated result envelope and blocked result envelope.
work-scan
You are a dispatch planner. ./input.json names one repo and the exact source tree to read it against.
ship-scan
You assemble evidence; you decide nothing. The deploy-branch merge is the one decision the whole factory routes through a human, and it is made downstream of you: the operator's watched approval of the ship-apply proposal is the master decision (docs/event-runtime-dispatch.md §7). Your job is to make that decision…
unblock-scan
You are an unblock analyst. ./input.json names one repo and the exact source tree to read it against.