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 Mindrally/skills --skill pr-reviewgit clone --depth 1 https://github.com/Mindrally/skillsWrote 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/mindrally/skills/pr-review)<a href="https://agentmods.dev/skills/mindrally/skills/pr-review"><img src="https://agentmods.dev/badge/skills/mindrally/skills/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/mindrally/skills/pr-review"><img src="https://agentmods.dev/badge/skills/mindrally/skills/pr-review.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00061 | $0.01606 |
| Opus 5.5 | $0.00024 | $0.00642 |
| Sonnet 5.5 | $0.00012 | $0.00321 |
| Haiku 4.5 | $0.00006 | $0.00161 |
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 7d 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 — 113 lines — stays where its author put it; the contents beside it link to each section on GitHub.
PR Review
This skill covers focused, angle-specific pull request review: picking the right lens (security, performance, tests, or architecture), producing specific and severity-ranked findings, and closing with a clear merge verdict.
Workflow for Reviewing a PR
- Pick the angle — Determine emphasis from the user's request ("security", "perf", "tests", "arch"). If unspecified, ask which angle to use, or default to security as the highest-risk default.
- Get full file context — A diff alone routinely misses bugs that live just outside the changed lines. If only a diff is available, request the surrounding file(s) before making confident claims.
- Review against the angle's checklist — Work through the relevant checklist below in priority order; do not mix angles unless the user asked for a full review.
- Write specific, cited findings — Every finding names a file and line number and states the concrete defect, not a vague impression.
- Rank by severity — Group findings as blocker, important, or nit.
- State uncertainty explicitly — If the diff doesn't give enough context to be sure, say so and ask for more code rather than guessing.
- End with a verdict on its own line —
Safe to merge | needs changes | reject(or the architecture-specific verdict below).
Output Discipline
Applies to every review angle:
- Cite file path and line number for each finding.
- Rank findings by severity: blocker, important, nit.
- Be specific. "This looks risky" is not a finding; "
src/auth.ts:42— JWT secret read from request body, see line 41" is a finding. - If the diff doesn't give enough context to be sure, say so explicitly and ask for the surrounding file.
- End with a verdict on its own line:
Safe to merge | needs changes | reject.
Angle 1: Security
Review the PR for security defects, in order of priority:
- Auth/authz — new endpoints or branches missing auth checks, role assumptions, IDOR (insecure direct object reference).
- Input validation — untrusted input flowing into queries, shell commands, file paths, deserialization, or
eval. - Injection — SQL, NoSQL, command, prompt injection, template injection.
- Secrets — hardcoded keys/tokens, secrets in logs, secrets in client-bundled code,
.envcommitted to the repo. - Output encoding — XSS via unescaped templating, raw HTML in user content, JSONP-style leaks.
- Crypto/randomness —
Math.random()used for tokens, MD5/SHA1 for password or integrity purposes, missing IVs, custom-rolled crypto. - Data exposure — PII in logs, overshared API responses, missing redaction.
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.
- 7d ago Changed · +3 lines ff710b79204e
- 1mo ago First seen · 110 lines · 61 tokens per session scan A 3e057cebf1c9
pr-review is a skill published in the GitHub repository Mindrally/skills (276 stars, last pushed 7d ago), licensed Apache-2.0. It adds 61 tokens to every session and 1,606 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-03.
Other skills, from other repositories
react-senior-code-review
Senior-level review of a React feature, by theSeniorDev — structure & boundaries, state & data flow, performance & rendering, types/forms/testability/a11y, and styling architecture & motion. Recommends design patterns by name when one fits. Produces prioritized findings (Critical → Nit) with file:line, why, and a…
council-review
Perform a rigorous Carmack Council code review. Use when explicitly asked to review code, do a "council review", "carmack review", or invoke /council-review. Carmack's philosophy chairs a council of domain experts — Troy Hunt (security), Martin Fowler (refactoring), Kent C. Dodds (frontend), Matteo Collina (Node.js)…
stack-changes
Splits a large change into small, single-purpose units of review — PRs, diffs, or CLs — each making one argument (one diff, one thesis) and each buildable and testable on its own. Use when a change is too big to review, when a feature builds on existing code, when working in a large monorepo with stacked diffs, or…
review-work
Post-implementation gate review: run manual QA on the real surface yourself, then launch ONE gate reviewer (never a panel) to audit goal, constraints, code quality, security, missed context, and QA evidence. Use before a PR handoff or when the user explicitly asks to review completed work.
tech-debt-audit
Thorough, file-cited technical debt audit across 9 dimensions using AST-grep (tree-sitter), grep, LSP, and language-native tooling. Produces TECHDEBTAUDIT.md with severity, effort estimates, and prioritized fixes. Use when asked for codebase health check, tech debt audit, architecture review, code quality assessment…
code-review-web
Review web application code for bugs, security issues, performance problems, and stack-specific anti-patterns. Use this skill whenever the user wants to review code, debug a production issue, investigate a build failure, audit security, or check a PR before merging. Triggers on code review, review my code, debug…