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 emaballarin/ccplugins/plugin install wsWrote 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/emaballarin/ccplugins/test-audit)<a href="https://agentmods.dev/skills/emaballarin/ccplugins/test-audit"><img src="https://agentmods.dev/badge/skills/emaballarin/ccplugins/test-audit/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/emaballarin/ccplugins/test-audit"><img src="https://agentmods.dev/badge/skills/emaballarin/ccplugins/test-audit.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.00057 | $0.01202 |
| Opus 5.5 | $0.00023 | $0.00481 |
| Sonnet 5.5 | $0.00011 | $0.00240 |
| Haiku 4.5 | $0.00006 | $0.00120 |
Grade A, and why
test-audit 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 12d 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 — 123 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/ws:test-audit — prune and consolidate a test suite
Audits the tests in the scope the operator names: tests that re-assert source,
duplicate stronger proof, couple behaviour to implementation, or keep test-only
production seams alive — and the duplicated setup /ws:test-gate deliberately
left behind. Optimise for confidence, not deletion count. Continue a broad audit
as separate coherent batches.
The value bar, junk patterns, retention bar, and the notes file live in
${CLAUDE_PLUGIN_ROOT}/references/test-value.md; read it first. Campaign mode prunes one
subsystem's whole test surface — every test file one package or area owns —
in one change; before starting one, read references/campaign.md, beside this file.
1. Scope and seed
- The scope is exactly what the operator named.
- Read the root and scoped
AGENTS.md/CLAUDE.mdandPROJECT.mdfirst. - Seed the candidate list with every
ws:test-gateentry in the notes file that falls inside the scope.
2. Discovery — read-only
Hunt for the junk patterns and for duplicated setup. For a broad scope, run parallel read-only discovery lanes through subagents, split along production-owner boundaries — core packages, plugins or extensions, apps and scripts and tooling, plus one cross-cutting pattern sweep. Outside campaign mode, prefer a few high-confidence candidates over a large speculative inventory.
Before judging a candidate, read the complete test and its production owner, the owner's entry point, callers, callees, sibling implementations, overlapping tests, CI routing, and relevant history. When the test claims dependency-backed behaviour, inspect the dependency's source or types directly.
While reading production owners, flag code that looks experimental or unsettled — behind an experiment flag or config switch, described as experimental in comments, docs or commit messages, or still churning in recent history. It stays in scope; it goes at the top of the report, saying what it is and what state it looks to be in, because consolidating around a shape that may not survive is premature.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 12d ago Changed bf319a799bd1
- 19d ago First seen · 123 lines · 57 tokens per session scan A bb3e6c7bb5ae
test-audit is a skill published in the GitHub repository emaballarin/ccplugins (4 stars, last pushed 7d ago), licensed MIT. It adds 57 tokens to every session and 1,202 once invoked, about $0.0002 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-09-27.
Other skills, from other repositories
review-testing
Review test code for quality, design, and completeness after implementing a feature or fixing a bug. Use when the user asks to "review my tests", "check my test quality", "are these tests good enough", "review testing", or after completing a feature implementation that includes tests. Also use when tests feel brittle…
r-testthat
Best practices for writing R package tests with testthat version 3+. Use this skill when writing or organizing tests for an R package or when improving existing tests that use testthat. It covers test structure and expectations, self-sufficient test design, proper cleanup with withr, fixtures, mocking external…
phx-work
Execute Elixir/Phoenix plan tasks with progress tracking. Use after phx-plan to implement features with mix compile and mix test verification after each step, or --continue to resume interrupted work.
lab:autoresearch
Self-improving loop for plugin skills. Reads program.md, proposes one mutation per iteration, evaluates against deterministic scorer, keeps improvements via git, reverts failures. Targets weakest skill+dimension. Use with /loop for overnight runs.
codex-loop
Fix Elixir/Phoenix code until Codex CLI review comes back clean — bounded review, fix, verify loop before opening a PR. Use when codex is installed and you want an external cross-model critic on your changes before pushing.
verify
Verify Elixir/Phoenix changes — compile, format, and test in one loop. Use after implementation, before PRs, or after fixing bugs.