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/fpindej/netrock/review-prnpx skills add fpindej/netrock --skill review-prgit clone --depth 1 https://github.com/fpindej/netrockWrote 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/fpindej/netrock/review-pr)<a href="https://agentmods.dev/skills/fpindej/netrock/review-pr"><img src="https://agentmods.dev/badge/skills/fpindej/netrock/review-pr.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.00029 | $0.00665 |
| Opus 5 | $0.00015 | $0.00332 |
| Sonnet 5 | $0.00006 | $0.00133 |
| Haiku 4.5 | $0.00003 | $0.00067 |
Grade A, and why
review-pr 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 — 51 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Reviews a pull request for production-readiness before merge. Runs in the main session so the reviewer agents can be dispatched in parallel (per CLAUDE.md delegation patterns).
Argument: PR number or URL. If omitted, reviews the current branch's open PR.
Current branch: !git branch --show-current
Open PR for this branch: !gh pr view --json number,title,url --jq '"#\(.number) \(.title) - \(.url)"' 2>/dev/null || echo "(no open PR)"
Steps
- Resolve the PR:
gh pr view {number} --json number,title,headRefName,body - Get the diff and changed files:
gh pr diff {number},gh pr view {number} --json files - Dispatch reviewer agents in parallel (one message, multiple Agent calls), scoped by what changed:
backend-reviewer- ifsrc/backend/changedfrontend-reviewer- ifsrc/frontend/changedsecurity-reviewer- alwaysux-designer- if UI components or pages changed Give each the PR number and the changed-file list for its scope. They preload the convention skills - do not restate conventions in the prompt.
- While reviewers run, perform the cross-cutting checks below yourself.
Orchestrator Checks (cross-cutting)
- Intent: does the code do what the PR description says?
- Cross-stack consistency: backend DTO changes -> types regenerated (
v1.d.ts), frontend consumers updated - i18n: new keys present in ALL locale directories
- Dockerfile: new
.csprojreferenced by WebApi has a COPY line in the restore layer - Completeness: new flags/props consumed; no dead code introduced
- No em dashes (U+2014), no emojis anywhere in the diff
- Tests: behavior changes come with test changes
Verdict Synthesis
Merge the reviewer reports and your own checks into one report:
- PASS - what looks good (brief, no padding)
- FAIL - issues that MUST be fixed before merge (with file path and line, attributed to the reviewer that found them)
- WARN - suggestions, not blockers
Final verdict: REQUEST CHANGES if any reviewer reported FAIL/CRITICAL/HIGH items or your checks found blockers; APPROVE WITH SUGGESTIONS if only WARN items; otherwise APPROVE.
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 First seen · 51 lines · 29 tokens per session scan A 5eb908ff0117
review-pr is a skill published in the GitHub repository fpindej/netrock (231 stars, last pushed 6d ago), licensed MIT. It adds 29 tokens to every session and 665 once invoked, about $0.0001 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
fleet-review
Code review checklist and PR review workflow for Fleet QA agents.
clean-code
Clean Code principles applied to this TypeScript / Next.js / React project, with a strong emphasis on eliminating duplication (DRY). Use before writing new code, during refactors, after Sonar flags duplicatedlines, or when reviewing a PR that adds similar-looking code to existing modules.
api-design
Guidelines for RESTful API design, endpoint naming conventions, and standardizing JSON responses.
python
Enforces FastAPI, Dependency Injection, and general Python coding standards based on the repository structure.
python-testing
Guidelines for Python testing using pytest and pytest-asyncio. Use when writing or debugging backend tests.
react
Guidelines for the React frontend, TanStack ecosystem, and React 19 standards. Use when modifying the UI.