// 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.
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.
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".
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.
| name | add-plugin |
| description | 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. |
| argument-hint | <name@marketplace> [--repo <owner/repo>] |
| user-invocable | true |
| allowed-tools | Read, Edit, Bash |
Role: implementation. This skill installs a Claude Code plugin and
adds it to plugins.json so ./install.sh stays the source of truth
for the project's plugin set.
You have been invoked with the /add-plugin skill.
name@marketplace
format encodes both; never ask the user to repeat information
already in the argument.Arguments: $ARGUMENTS
Required: plugin identifier ($0) in name@marketplace format —
e.g. cab-killer@cab-killer or skill-creator@claude-plugins-official.
Optional:
--repo <owner/repo>: GitHub repository to register as the
marketplace source before installing (e.g. bdfinst/cab-killer).
Required for plugins not on an official marketplace.Extract:
NAME — the part before @ in $0MARKETPLACE — the part after @ in $0REPO — value of --repo, or empty string if not providedRead plugins.json. If .plugins[] already contains an entry with
"name": "<NAME>", report:
<NAME> is already registered in plugins.json. Nothing to do.
and stop.
If REPO is non-empty, run:
claude plugin marketplace add <REPO>
If this fails, report the error and stop — do not proceed to install.
Run:
claude plugin install <NAME>@<MARKETPLACE>
If this fails, report the error and stop — do not update plugins.json for a plugin that did not install successfully.
Append a new entry to the plugins array in plugins.json:
REPO is non-empty:
{
"repo": "<REPO>",
"marketplace": "<MARKETPLACE>",
"name": "<NAME>",
"required": true
}
REPO is empty (official marketplace):
{
"marketplace": "<MARKETPLACE>",
"name": "<NAME>",
"required": true
}
Installed: <NAME>@<MARKETPLACE>
Repo: <REPO or "official marketplace">
plugins.json: updated