review command

Command

Review a diff with the reviewer fleet, funneled to one triaged verdict. Targets the current working diff, a path, or an inbound GitHub PR.

Invoke it

Claude Code/ca:review

Codex$ca-review

Pi/ca-review

Availability is read from each shipped host catalog. Preview-only commands are marked on the page.

What it does

A read-only review of the current change, dispatched by path against a reviewer-to-path matrix: security-reviewer for auth/middleware/secrets/deploy paths, auth-crypto-reviewer for authn/crypto/key handling, dependency-reviewer for manifest/lockfile changes, migration-reviewer for DB migrations, coverage-auditor for any source change, and architecture-drift-reviewer for code that may diverge from an accepted ADR. Each matched reviewer runs as one read-only unit through dispatching-parallel-agents; the results are deduped, then funneled through finding-triage (severity plus an inline [NEEDS-TRIAGE] marker on anything out of scope) and the read-only verdict-aggregator down to a single verdict. No file is modified by a run. A finding that turns on a genuinely-unresolved unknown surfaces as a numbered CONFIRM-NN rather than being resolved by guessing.

Findings are surfaced by severity (CRITICAL/HIGH/MEDIUM/LOW), file:line, remediation, and — for security findings — the specific control in .codearbiter/security-controls.md they map to. Raw per-reviewer output is never consumed directly; only the triaged, aggregated verdict is.

Select context for the actual review scope. Missing optional provenance or a code map permits focused source inspection. Resolve a genuinely missing task-critical requirement or conflicting instruction before the affected review; an unrelated stale aggregate does not block every unit.

Published releases from 0.7.5 include each packaged reviewer resource charter for Codex host-provided agent threads. Exact static-package and route-closure checks gate release. A bounded 0.9.4 receipt proves one exact installed-charter review. The inline fallback applies only where the canonical workflow explicitly permits it and isolation is not mandatory. See Claude Code + Codex → Intentional host differences.

Usage

/ca:review [path | #<pr> | <pr-url>]

Defaults to the current uncommitted diff when no target is given. A PR number or URL targets an inbound change. The diff is fetched once and the review does not check out its branch. Missing or unauthenticated gh stops the PR path; it does not fall back to the working diff.

For an inbound PR, the local verdict is the deliverable. Posting a comment requires separate confirmation. This route does not submit GitHub Approve or Request changes decisions. See Review and ship a change for target selection, finding review, commit/PR boundaries and post-merge cleanup.

Example

> /ca:review

Dispatched: security-reviewer, auth-crypto-reviewer (src/auth/session.ts)
            coverage-auditor (src/auth/session.ts, src/auth/login.test.ts)

HIGH   src/auth/session.ts:41  Session token generated with Math.random(),
       not a CSPRNG. Control: security-controls.md §Randomness.
LOW    src/auth/login.test.ts  No test for expired-token rejection path.

Verdict: 1 HIGH, 1 LOW — HIGH must be resolved before /ca:pr.

When to reach for it

/ca:pr already dispatches this automatically when opening a PR, so a manual run is for checking before that point; a periodic full-codebase sweep is /ca:checkpoint’s job, and a pre-implementation threat model is /ca:threat-model’s.

Gates

Gate	When	Effect
severity block	a CRITICAL or HIGH finding surfaces on your own change	must be resolved before /ca:pr; an inbound PR receives a local verdict, not a block on unrelated local work

Related

• dispatching-parallel-agents
• pr
• checkpoint

Route context

Find this entry in the workflow atlas. Compare its related teaching maps, host spelling and context inputs. The exact procedure below remains the owner.

Source

Source — plugins/ca/commands/review.md (v3.7.0)

---
description: Review a diff with the reviewer fleet, funneled to one triaged verdict. Targets the current working diff, a path, or an inbound GitHub PR.
argument-hint: "[path | #<pr> | <pr-url>] (defaults to the current diff)"
---

# /ca:review — diff review

For every security policy reference below, follow `${CLAUDE_PLUGIN_ROOT}/includes/knowledge.md`
("Read security policy before a security decision"): select the repository's
context format, read the complete policy from exact `CTX-SECURITY-CONTROLS`
records in HTML mode or the full Markdown controls in Markdown mode, and read
operative scope blocks when applicable. Required policy that is missing or
unreadable blocks a security decision; scope blocks alone are not full policy.

Read-only review of a change. Routes to `dispatching-parallel-agents` (`${CLAUDE_PLUGIN_ROOT}/skills/dispatching-parallel-agents/SKILL.md`): dispatches the reviewer fleet by path matrix, dedupes, then funnels through `finding-triage` → `verdict-aggregator` to a single in-memory verdict. No code is modified.

`/ca:review #123` reviews an inbound pull request through the same fleet and triage as a local diff.

## Flow

1. Resolve scope from `$ARGUMENTS`:
   - **empty** → the current working diff (unchanged default).
   - **a path** → that path (unchanged).
   - **`#<number>`, a bare number, or a GitHub PR URL** → an INBOUND PR. Fetch its diff with
     `gh pr diff <number>` and review that. If `gh` is missing or unauthenticated, STOP and say so —
     do NOT silently fall back to the working diff, which would report a verdict on the wrong change
     under the PR's name.

   For a PR target, resolve the diff ONCE and review that text. Do not re-fetch per reviewer: the
   fleet runs in parallel, and a PR updated mid-review would otherwise have different reviewers
   reading different code and a triage that reconciles findings from two versions.
2. Before any substantive verdict, deliver task context to each actual reviewer.
   Use the changed paths from the resolved diff to select the current bounded
   packet with `_contextselectlib.select_task_context`; preserve the owning
   host's effective root/nested instruction order and the original source
   owner, scope/cwd, authority, and evidence epoch for each record. Identify
   task-critical source refs from the review obligation. Pass the packet and
   those refs to `_contextselectlib.prepare_review_input` for each reviewer,
   then include its `reviewer_input` in that reviewer's actual input. The
   returned `ready` state checks required inputs; it does not attest host delivery.
   For each actual reviewer, call `_contextselectlib.prepare_actor_delivery`
   with that selected packet, reviewer/task, absolute worktree and current
   source/host epochs. Send its bounded `delivery_text` with the review input
   on `deliver` and retain the counted attempt. On `advisory`, record the unknown
   delivery observation and continue the review without further delivery retries.
   Re-select after resume, compaction, scope or worktree change.
   Preserve applicable native instruction precedence. Source-scoped records,
   imported instruction text, map prose, and accepted ADR labels do not gain
   local normative authority by being copied into the packet.

   Bounded read-only source orientation and prerequisite inspection may happen
   before this preflight, including inspecting missing context. If a critical
   ref is missing or an applicable constraint conflicts, stop the substantive
   verdict and report the gap; do not block the bounded read-only inspection
   needed to resolve it. A stale or incomplete optional map, or a legacy
   provenance warning, remains visible and advisory unless it hides a named
   critical source. Review must not write context/native artifacts or any
   tracked or preexisting untracked file. Inventory only exact allowed
   transient host state, if the host creates any.
3. Build the unit list by path matrix; each matched reviewer is one read-only unit:

   | Reviewer | Dispatched when scope touches |
   |---|---|
   | `security-reviewer` | auth, middleware, secrets, deploy/CI, any security-sensitive path |
   | `auth-crypto-reviewer` | authn, crypto, key handling, secrets |
   | `dependency-reviewer` | `package.json`, lockfiles, base images, dependency manifests |
   | `migration-reviewer` | DB migration file add/modify |
   | `coverage-auditor` | any source change (test coverage vs. obligations) |
   | `architecture-drift-reviewer` | code that may diverge from accepted ADRs in `.codearbiter/decisions/` |

4. Route to `dispatching-parallel-agents` with that unit list (read-only batch — no collision check).
   It dedupes overlapping findings, then funnels through `finding-triage` (severity + inline
   `[NEEDS-TRIAGE]` on out-of-scope items) → `verdict-aggregator` (single read-only verdict).
5. Surface the aggregated verdict: findings by severity, file:line, remediation, and the applicable
   control from `${CLAUDE_PROJECT_DIR}/.codearbiter/security-controls.md` for security findings.
6. **For a PR target, posting the verdict is a separate, confirmed step.** Report locally first; post only on explicit instruction, with `gh pr review <number> --comment --body-file <file>`. A review comment on someone else's PR is outward-facing and effectively public the moment it lands — it notifies subscribers and cannot be un-sent. Never `--request-changes` or `--approve` from here: those carry merge authority, and this command produces a finding list, not a maintainer's decision.

## Severity

- **CRITICAL** — exploitable vuln, secret exposure, banned primitive, data-integrity breach.
- **HIGH** — significant compliance gap or unsafe pattern.
- **MEDIUM** — standards deviation or coverage gap.
- **LOW** — informational or style.

## Hard gate

Read-only — MUST NOT modify a file, and MUST NOT check out, merge, or otherwise move the repository to the PR's branch: reviewing an inbound PR means reading its DIFF, not adopting its code, and a checkout would run its content through hooks that trust the working tree. BLOCK on any CRITICAL or HIGH finding on your OWN change: it must be resolved before `/ca:pr`. On an inbound PR there is nothing local to block — the verdict is the deliverable. MUST NOT consume raw reviewer output — only the `finding-triage` → `verdict-aggregator` verdict. MUST NOT resolve a `[CONFIRM-NN]` surfaced during review by guessing.

## When NOT to use

- Opening a PR (reviews dispatch automatically) → `/ca:pr`.
- A periodic full-codebase sweep → `/ca:checkpoint`.
- A pre-implementation threat model → `/ca:threat-model`.
- A question about the code → ask it directly; no command needed.

View in repo