// Run a single named review agent against target files. Use this when the user names a specific agent (e.g. "run security-review", "check for test issues", "run js-fp-review on this file") rather than wanting the full suite. Prefer this over /code-review when only one concern is relevant or speed matters.
Scaffold a new review agent from a description or URL. Use this whenever the user wants to add a new review agent, detect a new category of code issue, or says things like "add an agent for X", "create a reviewer for Y", "I want to check for Z in code reviews". Also use when given a URL to a coding standard or best-practices guide that should become a review agent.
Install a Claude Code plugin and register it in plugins.json so the full team can replicate the install. Use this whenever adding a new plugin to the project — it keeps plugins.json in sync with what is actually installed.
Apply correction prompts generated by /code-review. Use this whenever the user wants to apply, fix, or action the results of a code review — phrases like "apply the fixes", "fix the issues", "apply corrections", or after /code-review has run and produced a corrections/ directory.
Run all enabled review agents against target files. Use this whenever the user asks for a code review, wants feedback on their code, says "review my code", "check this before I PR", "what's wrong with this", "run the agents", or has just finished implementing a feature. Use proactively before commits and pull requests.
Audit code-review agents, skills, and hooks for structural compliance. Use this when adding or modifying any agent, skill, or hook file, or for a periodic health check of the toolkit. Trigger phrases: "audit the agents", "check compliance", "validate the skills", "are the agents correct", or any time agent/skill files change.
Run eval fixtures against review agents and grade results. Use this after adding or modifying a review agent, to validate detection accuracy, or when the user says "run the evals", "test the agents", "check for regressions", or "how accurate is the agent".
| name | review-agent |
| description | Run a single named review agent against target files. Use this when the user names a specific agent (e.g. "run security-review", "check for test issues", "run js-fp-review on this file") rather than wanting the full suite. Prefer this over /code-review when only one concern is relevant or speed matters. |
| argument-hint | <agent-name> [--changed | --since <ref>] [--path <dir>] |
| user-invocable | true |
| allowed-tools | Read, Grep, Glob, Bash(git diff *) |
Role: worker. This skill performs the actual review using the agent definition as its specification.
You have been invoked with the /review-agent skill. Run a single named review agent.
--changed or --since is used,
honor the agent's Context needs field (diff-only, full-file, or
project-structure).Arguments: $ARGUMENTS
Required: agent name ($0, e.g., test-review, js-fp-review, security-review)
Optional:
--changed: Review only uncommitted changes--since <ref>: Review files changed since a git ref--path <dir>: Target directory (default: current working directory)Read agents/<name>.md. If the file doesn't exist, list available
agents from agents/ and ask the user to pick one.
Same logic as /code-review:
--changed: git diff --name-only + git diff --cached --name-only--since <ref>: git diff --name-only <ref>...HEADFollow the agent definition to review each target file. Produce a JSON result:
{
"agentName": "<name>",
"status": "pass|warn|fail",
"issues": [
{
"severity": "error|warning|suggestion",
"file": "<path>",
"line": 0,
"message": "<description>",
"suggestedFix": "<fix>"
}
],
"summary": "<summary>"
}
Display the result as a formatted summary with issues grouped by file. Include suggested fixes inline.