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 skills add wunki/dotfiles --skill pr-reviewgit clone --depth 1 https://github.com/wunki/dotfilesWrote 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/wunki/dotfiles/pr-review)<a href="https://agentmods.dev/skills/wunki/dotfiles/pr-review"><img src="https://agentmods.dev/badge/skills/wunki/dotfiles/pr-review/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/wunki/dotfiles/pr-review"><img src="https://agentmods.dev/badge/skills/wunki/dotfiles/pr-review.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.00120 | $0.01669 |
| Opus 5.5 | $0.00048 | $0.00668 |
| Sonnet 5.5 | $0.00024 | $0.00334 |
| Haiku 4.5 | $0.00012 | $0.00167 |
Grade A, and why
pr-review 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 yesterday.
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 — 108 lines — stays where its author put it; the contents beside it link to each section on GitHub.
PR Review
The question behind every review: will the next engineer, six months from now, understand this code, trust it, and change it safely? Correctness comes first. A correct change that only its author can follow is still a cost the team pays forever, so readability, abstractions and data design are real findings, not style notes.
Read LENSES.md before reviewing anything non-trivial. It holds the checklists and the smell-to-fix examples for each lens.
Review modes
- Review someone else's change: inspect and report. Don't edit unless asked.
- Pre-handoff self-review: inspect the final diff against the task's acceptance criteria. Look for missing requirements as well as defects.
For self-review, prefer a fresh session when available and authorized. Give it the task, relevant constraints, repo rules, and diff, not the implementer's conclusions about correctness. Switching models within the same conversation does not create an independent review.
A review request alone does not authorize fixes. When implementation is already authorized, verify findings before fixing them and stay within the agreed scope.
1. Orient
- Read the PR description, linked tickets and any design notes. Know what "done" was supposed to mean.
- Read the repo's rules: root and scoped
AGENTS.md/CLAUDE.md, architecture and glossary docs, and contributing docs. Repo rules beat this skill when they conflict. - Find how CI tests the code (
.github/workflows, package scripts, Makefile). CI is the source of truth for "does it pass". - Get the change:
gh pr view <n>,gh pr diff <n>, orgit diff <base>...<head>. Check the head out in a separate worktree, so you read whole files and can run things without touching anyone's checkout.
Never review hunks alone. For every changed file, read the whole file. For every changed function, read its callers and the code it calls. Most real bugs live in the lines the diff didn't show.
2. Map the change
Before judging anything, write down in three to six lines:
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.
- yesterday First seen · 108 lines · 120 tokens per session scan A 6ad73a2828d6
pr-review is a skill published in the GitHub repository wunki/dotfiles (47 stars, last pushed 2d ago), licensed MIT. It adds 120 tokens to every session and 1,669 once invoked, about $0.0005 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-10-21.
Other skills, from other repositories
assess-quality
Foundational quality framework: the five questions (readable, easy to start, expands without bloat, consistent, intentional) every other dev skill is judged against, plus the dual-audience and workshop principles. Use when onboarding to a project, defining a quality bar, setting an assessment checklist, or arbitrating…
merge-ready
Drive an existing pull request to a mergeable state: get CI green, resolve merge conflicts with the base branch, address and resolve review comments, trigger required bot reviews/approvals (e.g. commenting '@claude review'), link associated issues, and clean up the PR title and description. Ends with a readiness…
test-code
Testing philosophy, test types (unit, integration, golden, fuzz, property, benchmark, smoke, E2E), per-language conventions (Rust, Go, Python, TypeScript), file organization, fixtures/mocks, CI strategy, and what NOT to test. Use when writing tests, reviewing test coverage, setting up test infrastructure, or deciding…
check-project
Validate project structure against scaffold conventions -- check for required files, CI consistency, documentation completeness, sub-package/workspace members, and optional directory usage, reporting PASS/WARN/FAIL with fix suggestions. Use to audit an existing project or verify a scaffold was applied correctly. Do…
review-diff
Standardized review of the CURRENT working-tree changes -- staged, unstaged, and untracked -- against an explicit five-dimension rubric (correctness, security, tests, scope-creep, conventions). Emits a prioritized findings list, each with file:line, severity, and a suggested fix. Read-only: it reviews and reports, it…
sync-ecosystem
Audit one repository against ecosystem conventions (naming, capabilities, terminology, doc coverage, version discipline, canonical skill coverage) and emit a read-only drift report. Use when onboarding a repo, auditing convention drift, or checking ecosystem consistency after a refactor. This skill only reports; it…