review 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.
/ca:review$ca-review/ca-reviewAvailability is read from each shipped host catalog. Preview-only commands are marked on the page.
What it does
Section titled “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 checkpoint-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.
On current Codex hosts, codeArbiter loads each reviewer charter into a host-provided agent thread and retains its thread receipt. An older host may run a review role inline rather than skip it — see Claude Code + Codex → Intentional host differences.
/ca:review [path]Defaults to the current uncommitted diff when no path is given.
Example
Section titled “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
Section titled “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. A read-only look before onboarding at all
is /ca:preview.
| Gate | When | Effect |
|---|---|---|
| severity block | any CRITICAL or HIGH finding surfaces | must be resolved before /ca:pr — the aggregated verdict is not advisory at that severity |
Related
Section titled “Related”Source
Section titled “Source”Source — plugins/ca/commands/review.md (v2.11.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
Read-only review of a change. Routes to `dispatching-parallel-agents`: dispatches the reviewer fleet by path matrix, dedupes, then funnels through `finding-triage` → `checkpoint-aggregator` to a single verdict. No code is modified.
**The change under review does not have to be yours.** `/ca:review #123` reviews an inbound pull request through the same fleet, the same matrix, and the same triage. That is the point of issue #80: a tool that only reviews the diff you just wrote is a linter for authors, not a gate for a team, and reviewing code you did NOT write is where a governance gate earns its keep.
It is an ARGUMENT, not a second command. The scope resolver already took one, the fleet is scope-agnostic, and every phase downstream operates on a diff regardless of where it came from — so a `/ca:review-pr` would be a whole public surface (catalog, three host projections, README counts, sidebar) whose only distinguishing feature is where the diff was fetched from.
## 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. 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/` |
3. 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) → `checkpoint-aggregator` (single verdict).4. 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.5. **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` → `checkpoint-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 → `/ca:btw`.