arthai-marketplace

/review-pr

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.

Synopsis

/review-pr [#N|branch] [--type bug|feature] [--workflow|--classic]

When to use it

Quickstart

/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.

Concepts

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.

Examples

/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

Arguments & flags

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.

What it does

  1. Loads PR context — fetches the PR details, diff, and commits, then auto-detects the type (labels like 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.
  2. Gathers prior knowledge — queries the project knowledge graph (if installed) for conventions, patterns, and past decisions touching the changed files, then runs a cheap explore-light scan to map callers, dependencies, and test coverage (blast radius).
  3. 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.
  4. Type-specific review
    • Bug fix: scope compliance against the /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.
    • Feature: plan completeness vs .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.
  5. Compiles the report — per-check summary table plus a verdict. It never auto-approves — findings are always presented for you to decide.
  6. Writes back, then posts — findings go to the project knowledge base first (systemic patterns flagged — e.g., a file with repeated bug-fix PRs). Then the user-confirmation checkpoint: Approve / Request changes / Comment / Don’t post — only with your approval does anything reach GitHub via 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.
  7. Completion verification — a verifier agent double-checks the review covered what it claimed; gaps are reported, not blocking.

Agents spawned

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

Output & artifacts

Troubleshooting

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

Cost

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.