Borrowing it
Nothing to install: this file belongs to Nizoka/pdfnative-mcp. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/Nizoka/pdfnative-mcp/main/.claude/skills/release-audit/SKILL.mdgit clone --depth 1 https://github.com/Nizoka/pdfnative-mcpWrote 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/nizoka/pdfnative-mcp/release-audit)<a href="https://agentmods.dev/skills/nizoka/pdfnative-mcp/release-audit"><img src="https://agentmods.dev/badge/skills/nizoka/pdfnative-mcp/release-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/nizoka/pdfnative-mcp/release-audit"><img src="https://agentmods.dev/badge/skills/nizoka/pdfnative-mcp/release-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.00000 | $0.02077 |
| Opus 5.5 | $0.00000 | $0.00831 |
| Sonnet 5.5 | $0.00000 | $0.00415 |
| Haiku 4.5 | $0.00000 | $0.00208 |
Grade A, and why
release-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 1mo 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 — 66 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Release audit
Audit the release described by $0 (default: the newest release-notes/v*.md) against everything that changed since $1 (default: the previous v* tag from git tag -l). The audit produces findings, never fixes: every fix goes through the normal edit → gate loop afterwards, and the ledger records what was fixed.
Read ledger.md first for the ledger and verdict formats. Each phase below hands a template to the agents it spawns; the agents return findings, you file them.
Ledger location
.audit/<version>/ — git-ignored (check .gitignore covers it before writing; it is NOT under test-output/, which Claude Code is denied to Read), so nothing here is ever committed. One Markdown file per report: auditor-a, auditor-b, verifier-1, auditor-d, verifier-2, then the ledger and the verdict (formats in ledger.md).
Phase A and B — two auditors, in parallel
Spawn both with the Agent tool in the same message (distinct angles; neither sees the other's report):
- Auditor A — claims vs code. Template:
auditor-a.md. Every claim in the release note and the top CHANGELOG entry is checked againstsrc/tools/, the shared fragments undersrc/,tests/,examples/andscripts/; at least one assertion per claim is reproduced with a command (a test, a script, atools/callagainst the BUILT server), not inferred from reading. - Auditor B — docs and agent surfaces. Template:
auditor-b.md. The README tool matrix,docs/AGENT_CONTRACT.md,llms.txt,docs/AI_GUIDE.md,docs/API_STABILITY.md§5, the livetools/listdescriptions,SERVER_INSTRUCTIONSand the prompts,server.json,docs/assets/ecosystem.jsoncounters, the sample baseline, the conformance corpus — every surface an agent or a human reads — compared with the behaviour that actually shipped.
Both write their report in the finding format of ledger.md (id, severity, claim, evidence command, observed, expected).
Phase C — adversarial verifier
Spawn one verifier (template: verifier.md) with both reports. It re-derives every finding from scratch — re-runs the evidence command, reads the cited lines — and stamps each one CONFIRMED | DOWNGRADED | REJECTED | DUPLICATE with a one-line justification. Auditors have about 10 % false findings; the verifier exists to keep them out of the ledger. A finding the verifier cannot reproduce is REJECTED, not "probably fine".
What ships with it
4 files 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.
- 1mo ago First seen · 66 lines · 0 tokens per session scan A 95e0a579e4ca
release-audit is a skill published in the GitHub repository Nizoka/pdfnative-mcp (2 stars, last pushed 7d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 2,077 tokens. 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-26.
Other skills, from other repositories
codew-release-qa-sweep
Use before claiming Codewhale release work is done: run the full gate sweep and list the manual QA targets.
validate-release-green
Run or inspect the local Release-Green observer for an exact base or combined PR candidate, separating hard failures, advisory drift and incomplete evidence. Use for maintainer preflight; full CI acceptance remains a separate requirement.
ship
Pre-release gate. Run the full gate, responsive + render checks, then produce the release checklist (README badge/current/changelog). Use before tagging a release.
verify-and-ship
Choose proportionate validation, fix failures, update the changelog, commit, push, and create/update the pull request or merge request.
ship-workflow
Resumable shipping lifecycle: reconciles current Git and GitHub facts from any entry (dirty default or feature branch, local commits, published branch, open PR, existing manual or native stack, merged work), commits dirty work as lossless logical commits, publishes or reuses the PR, requires current CI and review…
mathodology-dev-test-release
Use when checking skill metadata, references or repository boundaries, or preparing an explicitly requested skills release.