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 livlign/claude-skills/plugin install dotnet-coverage-kitWrote 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/livlign/claude-skills/coverage-init)<a href="https://agentmods.dev/skills/livlign/claude-skills/coverage-init"><img src="https://agentmods.dev/badge/skills/livlign/claude-skills/coverage-init/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/livlign/claude-skills/coverage-init"><img src="https://agentmods.dev/badge/skills/livlign/claude-skills/coverage-init.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.00171 | $0.10346 |
| Opus 5 | $0.00086 | $0.05173 |
| Sonnet 5 | $0.00034 | $0.02069 |
| Haiku 4.5 | $0.00017 | $0.01035 |
Grade C, and why
coverage-init scanned grade C with 1 finding 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 9d 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.
Recursive force deletehighDestructive command
rm -rf with a variable or a broad path is one typo away from removing the wrong tree.
2. **Clear `coverage/sweep/` first** (`rm -rf coverage/sweep`) so a prior or crashed run How it starts
The opening of the file, as written. The whole thing — 523 lines — stays where its author put it; the contents beside it link to each section on GitHub.
coverage-init
Run once per repo. Discovers the repo's shape and drafts the per-repo config. It DRAFTS; a human reviews and corrects before any test generation. Never proceed to generation in the same turn.
Precondition — run on the latest production branch (master)
The manifest, the detected structure, and the baseline number must reflect the code that ships, not an in-flight feature branch. Before doing anything else:
- Confirm the repo is on the production branch (master). If checked out on a feature/topic branch, stop and ask the user to switch — do not init against feature work.
- Pull it up to date with the remote (
git fetch+ fast-forward) so the baseline matches the current tip of master. - Confirm a clean working tree. Uncommitted local changes skew detection and the baseline; if the tree is dirty, stop and report rather than measuring against unknown edits.
State the branch and commit you initialized against in the step 11 report, so the eventual
baseline.ref is traceable to a real production commit.
Steps
-
Detect SDK-style. Confirm projects are SDK-style
.csproj(dotnet-coverage only supports these). If any target project is a legacy non-SDK.csproj, stop and report it — that project needs coverlet instead and is out of scope for this kit. -
Inventory projects. List
.csprojfiles and their references. Identify the test project(s) and what they reference. Identify likely roles (domain, application, infrastructure, presentation, workers) from project names, references, and folder layout. Detect whether MediatR is present (handlers vs pipeline behaviors). -
Derive the TARGET-set hypothesis from the repo's architecture — do NOT apply a fixed template. The target is the code whose coverage is counted toward the headline ("Adjusted") number. This step only forms the hypothesis of where target code lives; the sweep (step 4) classifies the actual files. Based on step 2:
- Clean / layered (distinct
*.Domain,*.Applicationassemblies): candidate target is those layer assemblies; Infrastructure/Api/Web are informational. - Service-oriented / flat (no layer assemblies; logic in service projects or sub-folders
of an API project): candidate target is the business-logic projects/sub-folders
(e.g.
Account.API/Service/**), by name + content — do not promote a whole API project if its logic is confined to a sub-folder. - No discernible structure:
uncategorized; do not invent layering.
- Clean / layered (distinct
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.
- 9d ago First seen · 523 lines · 171 tokens per session scan C 351043f5585a
coverage-init is a skill published in the GitHub repository livlign/claude-skills (18 stars, last pushed 1mo ago), licensed MIT. It adds 171 tokens to every session and 10,346 once invoked, about $0.0009 per session on Opus 5. A static security scan graded it C with 1 finding (recursive force delete). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
hyper-tdd
Use when about to write or modify behavior-bearing code — functions, business logic, bug fixes — before writing any production code. Also when the user invokes /hyperclaude:hyper-tdd. Forces a failing test first so you watch it fail for the right reason.
pwp-test
Testing strategy and implementation protocol — structured quality assurance that catches real bugs. Use this skill whenever the user asks to write tests, add test coverage, set up a testing strategy, or asks 'how should I test this'. Also use when they say 'add tests', 'write tests for this', 'test coverage', 'what…
capture
Capture a REAL Claude Code /v1/messages body as a replay fixture, so the HTTP replay arm (.skills/replay) faithfully reproduces Claude Code's cachecontrol breakpoint structure (a hand-authored fixture makes the 1h-TTL knob look like a no-op). Starts a clawback proxy with --capture-body, drives ONE real claude turn…
drive
Drive the REAL claude binary through clawback's PTY channel at a scripted inter-turn gap schedule — the faithful load arm. Because the bytes on the wire are produced by genuine Claude Code, this is the only driver that exercises the 1h-TTL nested-cache-control rewrite (arm A2) authentically. Use for headline/moat…
replay
Drive a reproducible HTTP replay load against a running clawback proxy. Replays one captured /v1/messages fixture at a load profile's inter-turn gap schedule, with built-in carry-over control (fresh path-mode session id + per-block cache nonce). Auth is an OAuth bearer (CLAWBACKOAUTHTOKEN), never an Anthropic API key…
submit-smoke
Cheaply prove the PTY turn-submission mechanism actually lands turns BEFORE any timed or headline run spends real tokens. Runs .skills/submit-smoke/scripts/submitsmoke.sh — one tiny passthrough Haiku block — and checks two independent signals: the driver's own "confirmed N/M" tally AND the count of real (non-ping)…