Review (dynamic) opus

Deep-review coordinator written into your repository by /brewcode:superreview-setup and wired to that project’s agents, rules, build commands and task tracker. One /superreview run covers correctness, architecture, reuse, version pins, business requirements and scope discipline, and writes a single report.

Not shipped with the plugin. The generator writes it to .claude/skills/superreview/ in your repo; you invoke it there as /superreview.

Quick reference

Field	Value
Command	`/superreview "<prompt-or-file-path>" [scope]`
Lives at	`.claude/skills/superreview/` in your repo
Invocable by	user and model (auto-triggers on “deep review”, “check scope”, “blast radius”)
Model	opus
Tools	Read, Glob, Grep, Agent, Bash, Write, AskUserQuestion
Output	`.claude/reports/{TIMESTAMP}_superreview/REPORT.md`; read-only, never edits code

What it does

The skill resolves one review mode from your argument and runs your project’s real build and test commands as ground truth. It routes each group of changed files to the agent that owns that surface, then checks the change against the task or issue that sanctioned it.

Nothing reaches the report unvalidated. An agent that does not own the file reverse-checks every candidate finding; failures are dropped, and anything unvalidatable is reported as UNVALIDATED with the run marked INCOMPLETE. A degraded run never looks clean. The report recommends /simplify and a fix session in Manager mode; the skill never edits code.

When to use

Situation	Command
Working tree right now	`/superreview "check the payment module"`
A branch against main	`/superreview "auth rework" feat/42-token-rotation`
One commit	`/superreview "why did this regress" a1b2c3d`
One folder	`/superreview "boundary check" src/billing/`
Whole repo	`/superreview "review the entire project"`
Focus read from a file	`/superreview ./docs/review-focus.md`

Example

/superreview "focus on reuse and boundary violations" feat/42-payment-retry

The skill announces what it resolved before reviewing:

superreview MODE = EXPLICIT (explicit token)
Branch: feat/42-payment-retry
Scope: origin/main...feat/42-payment-retry
Files: 17 (src/billing/retry.ts, src/billing/policy.ts, ...)
Gates: build OK / lint OK / test FAIL (exit 1)
Experts (derived from live roster): billing -> billing-owner, tests -> test-owner
Preflight: OK

Delegation

The fan-out spawns one subagent per file group, all in one message, each with the six-field brief (references/agent-prompt.md); the contract is part of the emitted template. Full table: Delegation.

Technical details: modes, verdicts, gates, files

Verdict output

The run closes with:

VERDICT: REWORK
Validation: all 12 findings validated
P0: 1  P1: 4  P2: 5  P3: 2
Report: .claude/reports/20260802-141205_superreview/REPORT.md

Flow

Phase 0: mode, gates, baseline
The mode is computed, never asked. Build, lint, type and test commands run once and their output (CONFIRMED-BY-EXECUTION) goes to every agent. The sanctioned scope baseline is read from the task, issue and recorded decisions.
Phase 1: route files to owners
Changed files are grouped by path. Owners come from the live .claude/agents/ roster; a group with no owner falls back to Explore and is marked DEGRADED.
Phase 2: one parallel fan-out
One message spawns the domain experts plus two scope passes: diff side (creep) and baseline side (delivery and closeout). Up to two general agents join.
Phase 3: adversarial validation
A non-owning validator checks every candidate (40 per spawn, 4 spawns max), then merges and prioritizes P0 to P3 once.
Phase 3b: scope gate
Scope-creep findings with no cited decision trigger one AskUserQuestion: was this sanctioned? The answer only reprioritizes existing rows.
Phases 4-5: report and summary
One merged report sorted P0 to P3 with a Scope Discipline section, plus a chat summary with verdict and next steps.

Mode resolution, checked in this order:

#	Condition	Mode	Scope reviewed
1	Prompt asks for the whole project, in any language	`FULL_PROJECT`	whole corpus
2	Explicit token: folder, file, commit SHA or branch	`EXPLICIT`	that folder / commit / branch-vs-main
3a	Default, `git status --porcelain` non-empty	`UNCOMMITTED`	working-tree diff vs `HEAD`
3b	Default, tree clean	`LAST_COMMITS`	`HEAD~2..HEAD`, else `HEAD~1..HEAD`, else root commit

Any other prompt is a focus directive; the mode still resolves via rule 3. Corpus: git-ignored is OUT, tracked and untracked-but-not-ignored are IN.

Verdicts

Verdict	Meaning
`APPROVED`	Gates green, no surviving findings, at least one agent returned
`CONDITIONAL`	Findings exist, none are blockers
`REWORK`	P0 or P1 findings survived validation
`- INCOMPLETE` suffix	Something went unvalidated or agents failed to return

Gates. Gate output is the only non-adversarial verdict, cited with the command and output line. A gate is OK only on an explicit GATE <name> OK. Missing toolchain records Gates: not run (<reason>). Failures outside the review scope appear under “Pre-existing gate failures”.

Files written into your repo

<project>/.claude/skills/superreview/
  SKILL.md                    # the emitted skill, self-contained
  references/
    agent-prompt.md           # expert selection + domain-owner prompt contract
    scope.md                  # baseline, ownership map, creep taxonomy, gate
    report-template.md        # merged P0-P3 report layout
    {stack}.md                # java-kotlin | typescript-react | python | go

Commit the directory so the team shares one review standard; re-run /brewcode:superreview-setup when the roster, rules, stack or tracker change.

Review (dynamic) opus

Quick reference

What it does

When to use

Example

Delegation

/brewcode:superreview-setup

agents skill

GitHub source

brewcode overview