Differentiated PR review, bug fix vs feature. Scope compliance, regression tests, behavior contract, knowledge base lookup. Uses the toolkit’s code-reviewer agent + project-specific checks.
/review-pr [#N|branch] [--type bug|feature] [--workflow|--classic]
/fix PR, it verifies the scope lock, behavior contract, and regression test that /fix produced/review-pr
What you’ll see: the current branch’s PR is auto-detected, classified as bug fix or feature, then reviewed. The result is a report with a per-check summary table (✓/⚠/✗) and a verdict. APPROVE, REQUEST CHANGES, or COMMENT, which you decide whether to post to GitHub.
Scope zones (set by /fix and enforced here): every bug-fix PR has a
Fix Zone (files the fix is allowed to touch), a Watch Zone (files that may be
affected as a side effect, touching them is allowed but must be justified in the PR),
and a Frozen Zone (files that must NOT change, migrations, lockfiles, unrelated
modules). /review-pr checks the diff against these zones and blocks on any Frozen
Zone violation.
/review-pr # review the current branch's PR, auto-detect type
/review-pr #88 # review a specific PR by number
/review-pr feature/auth # review the PR for a specific branch
/review-pr #88 --type bug # force the bug-fix checklist (scope lock, regression test, RCA)
/review-pr #88 --type feature # force the feature checklist (plan completeness, over-engineering)
/review-pr #88 --workflow # run the review fan-out as parallel isolated agents (needs Claude Code >= 2.1.154 and workflows enabled)
/review-pr --classic # force the sequential path (the default; always available)
/review-pr feature/auth --type feature --workflow
| Flag | Values | Default | What it does |
|---|---|---|---|
[#N\|branch] |
: | current branch’s PR | Which PR to review |
[--type] |
bug, feature |
auto-detect | Forces the review mode; otherwise inferred from labels, title prefix, and /fix artifacts |
[--workflow] / [--classic] |
: | classic | Runs the review fan-out as parallel isolated agents (workflow) or the sequential path (classic, default) |
--workflow prerequisites: requires Claude Code >= 2.1.154 and workflows enabled in
settings. If the version is too old, or workflows are disabled and you’re in a non-interactive
run, review silently falls back to classic with a one-line notice, you won’t get an error,
just the sequential path instead. In an interactive session with workflows disabled, you’re
asked whether to enable them.
bug/feat, title prefixes like fix:/feat:, or local /fix artifacts). If nothing matches, it asks you (bug vs feature, with each checklist previewed); only non-interactive runs default to feature, with a printed notice.Standard review (all PRs), spawns the code-reviewer agent with the diff, project conventions, and prior knowledge: code quality, security, test coverage, architecture, and consistency with past decisions.
With the decisions product on (/arth-setup → decisions), step 1 asks the Jev decision layer for the PR type, review depth, blast radius and a few risk flags before the label/title rules run. In enforce mode a confident answer replaces those rules (the bug-vs-feature question is unchanged when the answer is not confident); a confident skim with no merge-blocker or auth flag runs the code-reviewer on Haiku instead of Sonnet (auth always forces Sonnet). The checklists drive the same ✓/⚠/✗ marks, the complexity check is advisory only, a disagreement about a finding’s severity appears as an extra row in the summary table (the reviewer’s labels are never rewritten), and enabled compliance rules add advisory hints to the reviewer prompt. In shadow mode (the default after setup) nothing changes and the decisions are only logged.
/fix scope lock (Frozen Zone violations block), root-cause documentation in the PR body, regression test presence, a mutation check (test must fail without the fix and pass with it, run in an isolated worktree using your project’s test command, never your working tree; skipped with a reason if that isn’t possible), similar-past-bugs lookup, breaking-change and rollback assessment..claude/plans/<feature>.md (skipped with a note if no plan is referenced in the PR’s commits), over-engineering check, test coverage for new code, domain logic validation.gh pr review. On your own PR, Approve and Request-changes are removed (GitHub forbids self-approval) and the verdict is delivered locally. When you’re reviewing the currently checked-out branch, it can also post line-anchored inline comments via the built-in /code-review --comment.| Agent | Model tier | Role |
|---|---|---|
| explore-light | haiku | Maps callers, dependencies, and tests for the changed files |
| code-reviewer | inherit (caller’s tier) | Standard review: quality, security, coverage, architecture |
| qa-domain | sonnet | Feature PRs: validates business-rule consistency |
| completion-verifier | sonnet | Verifies the review itself was complete |
.claude/knowledge/skills/review-pr.md; new conventions or recurring bug patterns written to the knowledge graph| Problem | Fix |
|---|---|
| Wrong type detected (feature reviewed as bug or vice versa) | Re-run with --type bug or --type feature to force the mode |
✗ CRITICAL: No regression test found on a bug fix |
Bug fixes require a regression test: add one; the mutation check also requires it to fail without the fix |
FROZEN ZONE VIOLATION on a bug-fix PR |
The PR touches files in the Frozen Zone (see Concepts above): revert those changes. Files in the Watch Zone are allowed but need a justification note in the PR body |
| Approve option missing when posting | It’s your own PR: GitHub rejects self-approval (HTTP 422); the verdict is shown locally and you can post a comment instead |
⚠ Mutation check skipped |
The mutation check needs an isolated copy of your repo (a git worktree, or the EnterWorktree tool if available) plus a known test command: it never touches your actual working tree. It’s skipped if either is missing: add the test command to CLAUDE.md’s Test Commands table, or run the test yourself on the PR branch to confirm it fails without the fix and passes with it |
| No PR found for the current branch | Create it first with /pr, or pass the PR number explicitly |
Roughly 18-25 Arth units per invocation: one Haiku spawn (explore-light) plus 1-2 Sonnet
spawns (code review + project-specific checks). Cost runs higher when the knowledge graph
is queried or the PR is large. Note: code-reviewer runs at the caller’s model tier, so
under an Opus-tier caller the review portion is Opus-priced instead of Sonnet-priced.
The classic toolkit reviewer can consult Arth Router after Jev selects review
depth. ARTH_ROUTER_REVIEW_MODE=shadow records a suggestion while keeping the
existing reviewer. Explicit enforce can use an eligible model at or above that
baseline’s catalog quality floor. This needs compatible router support and an
explicit mapping of executable model versions and platform. Defaults to off;
Workflow and custom substituted reviewers are excluded. No extra Jev call is made,
and review completion alone is never treated as proof of review quality.
The pilot can record actual reviewer token usage when execution telemetry is available. Unknown counters remain unknown; reports show how many executions have measurements. This evidence does not charge a shadow suggestion or establish remaining subscription capacity.