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 skills/paultyng/skill-issue/review-coveragenpx skills add paultyng/skill-issue --skill review-coveragegit clone --depth 1 https://github.com/paultyng/skill-issueWrote 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/paultyng/skill-issue/review-coverage)<a href="https://agentmods.dev/skills/paultyng/skill-issue/review-coverage"><img src="https://agentmods.dev/badge/skills/paultyng/skill-issue/review-coverage.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.00073 | $0.02899 |
| Opus 5 | $0.00036 | $0.01450 |
| Sonnet 5 | $0.00015 | $0.00580 |
| Haiku 4.5 | $0.00007 | $0.00290 |
Grade B, and why
review-coverage scanned grade B 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 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.
Reads agent configuration directoriesmediumAgent snooping
.claude/, .codex/, .gemini/ hold keys, settings and other credentials a mod has no legitimate need for.
- Findings must cite probed evidence (`path:line`, grep output, command result), not pattern-matched suspicion. Per `~/.claude/rules/probe-not-assume.md`. How it starts
The opening of the file, as written. The whole thing — 214 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Coverage Review
Structured Go test-coverage review producing actionable findings: which new or modified functions in the scope are not exercised by the test suite. Reports per-package coverage and (when a baseline exists) per-package coverage delta.
Workflow
1. Scope and resolve
- Confirm scope with the user: full codebase, specific packages/directories, changed files only (PR or branch diff), or specific concern.
- Resolve scope to a file/package list. Based on what the user requested:
- Changed files (PR or branch): Run
git diff --name-only --diff-filter=d <base>...HEADto get changed files (default<base>ismain). If the user references a PR number, usegh pr diff <number> --name-onlyinstead. Filter to.gofiles. Derive affected Go packages from the file paths (unique parent directories containing.gofiles). - Explicit paths/packages: The user may specify directories (e.g.
internal/auth/), Go package patterns (e.g../internal/auth/...), or individual files. When given a directory or package pattern, include all.gofiles under it. - Full codebase: No filtering. Coverage analysis applies to every package (default).
- Changed files (PR or branch): Run
- Filter the resolved file list:
.gofiles only- Exclude
_test.go - Exclude generated code: anything under
gen/,internal/store/db/, or files whose first 100 lines contain// Code generatedorDO NOT EDIT
- Derive affected Go packages (unique parent dirs with surviving
.gofiles). - If invoked from review-all: receive
file_list,package_paths,has_changes,base_ref, andREVIEW_DIRfrom the orchestrator. Skip your own scope confirmation and use the provided values directly. - Set
has_changestrue when scope is "changed files" or when explicit paths have a diff against the base ref. False for full-codebase reviews with no diff baseline. When false, the skill still reports per-package coverage but cannot compute a "changed functions" delta.
2. Run baseline coverage
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 · 214 lines · 73 tokens per session scan B 6639b83e3fb1
review-coverage is a skill published in the GitHub repository paultyng/skill-issue (9 stars, last pushed 25d ago), licensed MIT. It adds 73 tokens to every session and 2,899 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it B with 1 finding (reads agent configuration directories). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
increase-test-coverage
Increase Go test coverage to 90%+ using a Research → Plan → Implement pipeline. Analyzes coverage gaps, generates table-driven tests with httptest mocks, and validates results with go test -coverprofile. Designed for Go MCP server projects using the official go-sdk and gitlab.com/gitlab-org/api/client-go/v2.
building-glamorous-tuis
Build terminal UIs with Charmbracelet (Bubble Tea, Lip Gloss, Gum). Use when: Go TUI, shell prompts/spinners, "make CLI prettier", adaptive layouts, async rendering, focus state machines, sparklines, heatmaps, kanban boards, SSH apps.
lang-go
Go toolchain: golangci-lint, go vet, go test, go mod. CI gate commands, file layout, interface patterns. Use when working on a Go project.
Go Testing Patterns
Go testing with testing package, table-driven tests, subtests, benchmarks, test fixtures, httptest, and testify assertions.
Testing
Standards for unit testing, table-driven tests, and mocking in Golang.
golang-testing
Go testing patterns including table-driven tests, subtests, benchmarks, fuzzing, and test coverage. Follows TDD methodology with idiomatic Go practices.