Review is the sweet spot for skills: you do it every day, and its output can be checked. The hard part was never getting a model to find faults. It is getting it to stop dumping twenty irrelevant ones in your lap.
You already let an agent write code. The next question is not whether it writes well — it is who looks at what it wrote. Everything in this category kills the same chore: it turns "read your own diff before you push", the step everybody skips, into one command. This issue names ten real, installable or readable items, each with the install and a "when not to install it"; the judgment criteria come in the second half, because tools rotate and the question of whether a finding counts does not.
# 1) Local: nothing to install, Claude Code ships it (/review is an alias)
/code-review # commits ahead of upstream + working tree changes
/code-review high # broader coverage, at the price of less certain findings
/code-review --fix # apply the findings to your working tree afterwards
/code-review main...my-feature # also takes a PR number / branch / path
# 2) CI: the security lane (official Action, per repo README, 2026-09)
- uses: anthropics/claude-code-security-review@main
with:
comment-pr: true
claude-api-key: ${{ secrets.CLAUDE_API_KEY }}
# 3) Third-party review skills: either route works
/plugin marketplace add aidankinzett/claude-git-pr-skill
/plugin marketplace add levnikolaevich/claude-code-skills
# or the crudest route: copy the skill folder into ~/.claude/skills/
The first usage you can run right now: type /code-review on the uncommitted branch in front of you. It runs as a background subagent with its own context window, so it never crowds your conversation; when the findings land, you decide which ones to act on. Try it today — there is nothing to install.
Writing a review checklist costs an hour, but it runs on every PR. Flip that around: a skill you use twice a year never earns back the time you spent writing it. That is why this category grows usable artifacts and "annual retrospective" skills do not.
The oracle is whatever settles right and wrong: a test, a type check, one real execution. A finding backed by an oracle is a fact; one without is a preference. The official webapp-testing skill (anthropics/skills) exists to supply that oracle for frontend changes: drive Playwright, start the server via scripts/with_server.py, wait for networkidle, find selectors, screenshot, read console logs back. Its own rule is blunt — run the script with --help first, do not start by reading its source. You can also just copy the folder into ~/.claude/skills/.
Three teams landed on the same answer. Claude Code's /code-review runs as a background subagent with its own context window by default. Superpowers' requesting-code-review takes BASE_SHA / HEAD_SHA, dispatches a separate subagent and fills in the repo's code-reviewer.md template; its SKILL.md states the reason outright — the reviewer never inherits your session history. The hosted Code Review runs multiple agents in parallel, each hunting a different class of issue, then adds a verification step that checks candidates against actual code behavior to filter false positives before deduplicating, ranking by severity and posting on the exact lines (per official docs, 2026-09).
/code-review low and medium report only the findings it is most confident in; high through max broaden coverage and may include less certain ones (per official docs, 2026-09). By default it reuses the level you typed last — so if it suddenly feels noisy, check whether you casually typed max last time.
The hosted reviewer reads REVIEW.md at the repo root (it reads CLAUDE.md too, but treats violations as nits). The four highest-value moves: redefine what counts as an Important finding (the default calibration targets production code; a docs repo or a prototype should narrow it), cap the nits ("report at most five, give the rest as a count in the summary"), write skip rules (generated code, lockfiles, anything CI already enforces such as lint and spellcheck), and raise the evidence bar ("behavior claims need a file:line citation, not an inference from naming"). One more, aimed at round trips: re-review convergence — "after the first review, Important findings only" — so a one-line fix does not reach round seven on style.
/code-review follows CLAUDE.md but does not read REVIEW.md. Assuming the file applies everywhere is a common trap.The most underrated skill here is superpowers' receiving-code-review, which governs not the reviewer but the agent receiving the findings. The rule is "verify before implementing, ask before assuming": before touching anything, check two things — is this technically correct for this codebase, and would it break existing functionality? If yes, fix it; if not, push back with technical reasoning and point at a passing test. It explicitly forbids performative agreement like "You're absolutely right!" and asks you to state the fix instead. This matters more than any reviewer: a downstream that accepts everything converts every false positive into real code degradation.
One line: anything with a definite answer belongs to CI; anything requiring judgment belongs to the review agent. Formatting, lint, types, dependency advisories — gate those fail-closed, and forbid the review agent from repeating them (that is a skip rule in REVIEW.md). Meanwhile the hosted Code Review check run always completes with a neutral conclusion and never blocks a merge. If you do want a gate, the documented route is to parse the machine-readable severity counts from the check run output — shaped like {"normal":2,"nit":1,"pre_existing":0} — and decide in your own CI.
REVIEW.md, at max effort, is the combination most likely to make a team give up./code-review: already on your machine, zero install, zero bill. Kills "found it after pushing"; not enough when: only you run it, so it never touches your colleagues' PRs./review, /describe, /improve, /ask — via GitHub Action or pip install pr-agent locally, with a swappable model. Not enough when: it reads the PR, not your whole codebase.claude /install-github-app sets it up, then you hand it a prompt in a workflow. Not enough when: you now own the prompt and the trigger logic — which is exactly what the hosted product does for you./security-review locally plus claude-code-security-review in CI (per the GitHub repo page, 2026-09, about 6.2k stars). It deliberately excludes the most false-positive-prone classes by default: denial of service, rate limiting, memory/CPU exhaustion, generic input validation with no proven impact, and open redirects. Not enough when: it only covers security — do not ask it about style.Install these three first: (1) /code-review — already on your machine, run it once today; (2) anthropics/claude-code-security-review — five lines of YAML in CI, the best return on effort in this batch; (3) superpowers/skills/receiving-code-review/ — copy that folder into ~/.claude/skills/; it treats the habit you and your agent share of accepting everything.
Then add exactly one more: if you review on GitHub, take github-pr-review from aidankinzett/claude-git-pr-skill (MIT; per the repo page, 2026-09, about 50 stars), which forces you to read the whole review before it goes out. If you want CI fully automatic, take The-PR-Agent/pr-agent. If the budget is there and you are on Team or Enterprise, turn on Anthropic's hosted Code Review.
When not to install any of it: a one-person toy repo · you already have strict human review plus strict CI · your changes are mostly copy and config.
Two-week review: of the findings it reported, how many did you actually act on? Under thirty percent means it is time to write a REVIEW.md — not time to switch tools.
/code-review runs this way by default: the review never crowds your main conversation, and only the conclusions come back.CLAUDE.md, which shapes every session). Severity calibration, nit caps and skip rules live here.github-pr-review uses it as the gate that makes a human read the review before it is posted.REVIEW.md option, the $15-25 per review pricing, and the machine-readable check run output/code-review (with /review as an alias) and /security-reviewgithub-pr-review: pending reviews plus a human approval gate, MITcode-reviewer lives; that page read 1,236 installs as of 2026-08 (the site was unreachable from our network while writing this issue, so the number is not re-verified)