Review Agents

Three focused, read-only review subagents for any stack — a test runner, a PR reviewer, and a dependency auditor. Each finds the project’s own commands instead of assuming a build tool. Each carries its own model tier and a tightly scoped tool allowlist, so verification steps report findings without being able to rewrite the code they’re checking. Designed to be invoked after writing code, before opening a PR, or ahead of a release.

Install

/plugin install review-agents@alexmskills

Trigger it

Use the pr-reviewer subagent on the current diff.

These are subagents, not slash commands — ask Claude to delegate to them:

  • "Use the test-runner subagent to run the tests for the order module."

  • "Use the pr-reviewer subagent on git diff main…​HEAD."

  • "Use the dependency-auditor subagent to check for CVEs before this release."

When to use it

  • After writing code, to verify the tests pass (test-runner)

  • When reviewing a PR or before creating one (pr-reviewer)

  • For security checks or before releases, to audit dependencies (dependency-auditor)

What it does

test-runner (haiku)

Finds the project’s test command, runs the requested tests at the right scope (all / one file or class / one test) and reports total run/passed/failed/skipped, with assertion messages and key stack-trace lines for failures. It only reports — never fixes code. A build that fails before any test runs is reported as a build failure, not as "0 tests failed".

pr-reviewer (sonnet)

Learns the project’s standards first — its stated conventions and whatever lint, format and analysis config is checked in — then reviews the diff against the base branch. The checklist is stack-neutral: code quality (imports, logging, resource handling, errors with their cause, no injection or hardcoded secrets), style (the project’s own formatter and linters, in their read-only check modes) and testing (new behaviour has tests, a fix has a test that fails without it). Reports findings grouped as Blocker / Warning / Suggestion, and says which checks ran and which could not.

dependency-auditor (haiku)

Audits every ecosystem it finds in the repo — a JVM service with a Node front end gets both. Lists what is actually resolved (from the lockfile where there is one), checks for updates, and looks for known vulnerabilities with the ecosystem’s own scanner when one is already installed, or by hand against OSV and the GitHub Advisory Database when not. Reports current / latest / advisories / action per dependency, says whether each vulnerable package is direct or transitive, and flags critical and high findings.

Any stack

None of the three assumes a build tool. Each looks for what the repo documents first (CLAUDE.md, README, a Makefile target, the CI workflow), and falls back to the manifest:

Found in the repo Tests Checks Dependency audit

pom.xml

./mvnw test

./mvnw validate

dependency:tree, versions:display-dependency-updates

build.gradle(.kts)

./gradlew test

./gradlew check

dependencies, dependencyUpdates

package.json

the test script

lint / typecheck scripts, tsc --noEmit, prettier --check

npm outdated, npm audit

pyproject.toml

pytest

ruff check, ruff format --check, mypy

pip list --outdated, pip-audit

go.mod

go test ./…​

gofmt -l, go vet, golangci-lint

go list -m -u all, govulncheck

Cargo.toml

cargo test

cargo fmt --check, cargo clippy

cargo outdated, cargo audit

*.csproj

dotnet test

dotnet format --verify-no-changes

dotnet list package --outdated / --vulnerable

Gemfile

bundle exec rspec

rubocop

bundle outdated, bundle audit

PHP (Composer) and Elixir (Mix) are covered for tests and audits too. Two rules hold on every stack: a tool is run only if the repo already configures or has it — a linter with no config is a preference, not the project’s standard, and a missing scanner is never installed — and every command is the read-only form, never one that fixes or upgrades.

Notes

  • Model tiers are chosen per job: cheap haiku for the mechanical test-runner and dependency-auditor, sonnet for the judgment-heavy pr-reviewer.

  • All three are read-only on source: Write and Edit are withheld (tools: Read, Glob, Grep, Bash, plus web lookup for the auditor), so a review step can’t silently change what it audits.

  • Until 1.2.0 the agents were written for Java/Maven only. Maven projects behave as before.

Claude Code vs Codex

Tier 2 — needs tool translation.

Claude Code Codex

Reviewers

Three registered subagents whose runtime tool list omits Write and Edit.

A discoverable skill dispatches each full agent definition in the child brief.

No-write guarantee

Enforced for Write/Edit — those tools are absent (Bash remains).

Instructed — the child is told not to write.

The difference that matters: The plugin’s headline safety property, "no-write by construction", is a runtime guarantee only on Claude Code. On Codex it is a prompt, so treat reviews there as trusted-to-comply.

Install, hook trust and verified limits: Codex compatibility.