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 eai-org/agent-toolkit --skill refine-pr-reviewgit clone --depth 1 https://github.com/eai-org/agent-toolkitWrote 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/eai-org/agent-toolkit/refine-pr-review)<a href="https://agentmods.dev/skills/eai-org/agent-toolkit/refine-pr-review"><img src="https://agentmods.dev/badge/skills/eai-org/agent-toolkit/refine-pr-review.svg" alt="Measured on agentmods" 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.00051 | $0.01265 |
| Opus 5 | $0.00026 | $0.00633 |
| Sonnet 5 | $0.00010 | $0.00253 |
| Haiku 4.5 | $0.00005 | $0.00127 |
Grade A, and why
refine-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 8d 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 — 109 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Refine PR review
The Refine phase for review feedback: turn a .PR-REVIEW.md (from /fetch-pr-review; ask if
the path is ambiguous) into user-settled per-comment verdicts, drafted replies, and a REQUIREMENTS
file covering the accepted code changes. Triage and replies are settled here; the plan and execute
phases see only code changes.
Verdicts
- address: the change enters the requirements in full; the reply stays a canned one-liner ("fixed", "good catch, thanks").
- partial: part of the change is accepted into the requirements, and the reply explains what was done and what was kept and why.
- push back: no code change; the reply carries the reason.
Phase 1 — triage every comment with the user
Read the code behind each comment first: verify its premise against the current codebase, never judging from the quoted hunk alone. Then form a recommendation — verdict, reasoning, and (for partial and push back) a draft reply. Nothing is decided silently:
- Contentious ones one at a time: every comment recommended partial or push back, or uncertain, is its own question carrying recommendation, reasoning, and draft reply.
- Obvious ones as one batch: then list the comments recommended address or no action for a single confirmation; the user can pull any item out for individual discussion.
Per comment type:
- Open/active human threads → full triage.
- Outdated → code check first; when the concern is moot in the current code, recommend "no action, optional courtesy reply".
- Resolved → no questions; table row marked "resolved earlier".
- Review verdict summaries and general comments → each actionable ask inside them is triaged like a thread.
- Bot comments → never drafted replies; present the actionable findings as one batch include-or-ignore question.
Phase 1 is complete only when every comment in the PR-REVIEW file has a user-confirmed verdict.
Phase 2 — requirements via /refine-ticket
Treat the accepted work (address, the accepted part of each partial, and included bot findings) as a settled-scope ticket and follow /refine-ticket (load and follow its SKILL.md): code verification, blocking vs non-blocking, the REQUIREMENTS structure, location and naming — all as written, with these overrides:
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.
- 8d ago First seen · 109 lines · 51 tokens per session scan A 3db2e3d8daa5
refine-pr-review is a skill published in the GitHub repository eai-org/agent-toolkit (46 stars, last pushed today), licensed MIT. It adds 51 tokens to every session and 1,265 once invoked, about $0.0003 per session on Opus 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-08-30.
Other skills, from other repositories
review-checklist
Code review standards and checklist for the code-reviewer agent.
gsd-ns-review
Route to the appropriate quality / review skill based on the user's intent. gsd-code-review-fix was absorbed by gsd-code-review --fix in #2790.
spec-kitty-runtime-review
Review runtime-owned outputs using the Spec Kitty review workflow surface, then direct approval or rejection with structured feedback. Triggers: "review this work package", "check runtime output", "approve this step", "review WP", "is this WP ready to approve", "check this implementation". Does NOT handle: setup-only…
review
Review code changes for security, performance, bugs, and quality. Reviews staged changes, unstaged changes, specific commits, or PR-ready diffs.
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.
one-way-door
Flags irreversible decisions before commit. Use for data models, infra, auth boundaries, API contracts, event schemas, CI/CD.