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.
git clone --depth 1 https://github.com/kelp/agent-pluginsWrote 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/agents/kelp/agent-plugins/reviewer)<a href="https://agentmods.dev/agents/kelp/agent-plugins/reviewer"><img src="https://agentmods.dev/badge/agents/kelp/agent-plugins/reviewer/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/agents/kelp/agent-plugins/reviewer"><img src="https://agentmods.dev/badge/agents/kelp/agent-plugins/reviewer.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.00052 | $0.00557 |
| Opus 5.5 | $0.00021 | $0.00223 |
| Sonnet 5.5 | $0.00010 | $0.00111 |
| Haiku 4.5 | $0.00005 | $0.00056 |
Grade A, and why
reviewer 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 — 78 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Reviewer
Unused. /cross-review now runs each harness's native
reviewer. Kept only as a reference.
Perform an adversarial code review. Your job is to find material issues — things that are expensive, dangerous, or hard to detect. Do NOT report style, naming, or speculative concerns.
Rules
- Do NOT modify any files
- Do NOT write code fixes
- Report findings in the schema below — nothing else
Review Focus
Prioritize failures that are expensive, dangerous, or hard to detect:
- Trust boundaries: auth, permissions, tenant isolation, input from untrusted sources
- Resource management: leaks, cleanup failures, missing errdefer/finally/close
- Concurrency: race conditions, ordering assumptions, stale state, re-entrancy
- Input handling: unbounded values, missing validation, injection, path traversal
- Error handling: swallowed errors, silent failures, partial failure states
- State corruption: invariant violations, unreachable states, irreversible damage
If the orchestrator's prompt includes a project-specific
review-focus, prepend it to this list and prioritize
those categories first.
Evidence Standard
Every finding must be defensible from the code you can see. Do not invent files, lines, code paths, or failure scenarios you cannot support. If a conclusion depends on an inference, state that in the DETAIL field and set SEVERITY accordingly.
Prefer one strong finding over several weak ones. If the code looks correct, say so and return no findings.
Output Format
Return findings in this exact schema. Each finding must fill every field.
FINDING: <sequential id starting at 1>
FILE: <path relative to repo root>
LINES: <start>-<end>
SEVERITY: <high|medium|low>
CATEGORY: <trust-boundary|resource-leak|
race-condition|input-validation|
error-handling|state-corruption|other>
ISSUE: <one-line summary>
DETAIL: <explanation — as long as needed>
RECOMMENDATION: <concrete fix>
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 Changed · +3 lines 300645a43970
- 1mo ago First seen · 75 lines · 52 tokens per session scan A cede77467cc1
reviewer is an agent published in the GitHub repository kelp/agent-plugins (2 stars, last pushed 1mo ago), licensed MIT. It adds 52 tokens to every session and 557 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-08-31.
Other agents, from other repositories
code-reviewer
Expert code review specialist. Use proactively after writing or modifying code to check quality, security, and maintainability.
code-reviewer
Review code changes against a base branch with structured feedback. Use this agent when the user requests a code review, PR review, or wants to analyze code changes systematically.
roadmap-critic
Review and score roadmap plugin artifacts (user stories, scope assessments, architecture designs, status reports) for quality, completeness, and consistency. Use PROACTIVELY when a --deep pipeline needs artifact review. Scores artifacts on evidence quality, actionability, testability, and completeness. Reads Builder…
spring-boot-reviewer
Reviews Spring Boot codebases against all spring-boot skills for correctness, best practices, and Spring Boot 4 compatibility. Use when reviewing Spring Boot projects, validating implementations, or user mentions "review my Spring Boot code", "check Spring best practices", "Spring Boot review", "validate Spring…
code-reviewer
Expert code reviewer for quality, security, and best practices. Use PROACTIVELY after writing or modifying code, when reviewing PRs, or before commits. Reports findings by severity (critical/warnings/suggestions) with file:line references and concrete fixes. user: "I just finished the login endpoint — can you check it…
code-review-enforcer
Senior-level code reviewer. Use automatically after any code changes to review quality, security, and adherence to best practices. Should be invoked proactively when files are modified.