Review (dynamic) opus

Caution

This skill is not shipped with the plugin. It is written into your repository by /brewcode:superreview-setup as .claude/skills/superreview/, and you invoke it there as /superreview. Every project gets its own copy, wired to that project’s agents, rules, build commands and task tracker.

Tip

One skill, both passes. There is no separate static skill for rule or style compliance. The emitted skill merges the old review engine with the standards-review pass, so one /superreview run covers correctness, architecture, reuse, version pins, business requirements and scope discipline — and produces one report.

Quick reference

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

What it does

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

Nothing reaches the report unvalidated. Every candidate finding is reverse-checked by an agent that does not own the file it came from; findings that fail the check are dropped, and anything that could not be validated is reported as UNVALIDATED with the whole run marked INCOMPLETE. A degraded run can never look clean.

It is read-only by design. The report recommends /simplify and a fix session in Manager mode, and names the domain agents to delegate to — it never edits code itself.

When to use

Situation	Command
Review what is in the working tree right now	`/superreview "check the payment module"`
Review a specific branch against main	`/superreview "auth rework" feat/42-token-rotation`
Review one commit	`/superreview "why did this regress" a1b2c3d`
Review one folder	`/superreview "boundary check" src/billing/`
Sweep the whole repo	`/superreview "review the entire project"`
Read the focus from a file	`/superreview ./docs/review-focus.md`

Example

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

Before any review work, the skill announces exactly what it resolved:

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, ...)
Focus: 1 reuse  2 correctness  3 architecture  4 version-pins  5 business-reqs
Gates: build OK / lint OK / test FAIL (exit 1)
Scope baseline: task T-118 / issue 42 (Retry failed payments) / 3 of 17 files outside the sanctioned surface
Experts (derived from live roster): billing -> billing-owner, tests -> test-owner
Preflight: OK

and closes with a verdict plus the report path:

VERDICT: REWORK
Validation: all 12 findings validated
Scope: task T-118 / issue 42; 3/17 files outside the sanctioned surface; delivery 1 partial; gate answered
P0: 1  P1: 4  P2: 5  P3: 2
Report: .claude/reports/20260802-141205_superreview/REPORT.md

Flow

Phase 0 — Mode, gates, baseline, announce
The mode is computed, never guessed interactively. Then the project’s real build, lint, type and test commands run — their output is fact, carrying the verdict CONFIRMED-BY-EXECUTION, and it is handed to every agent so nobody re-runs them. The sanctioned scope baseline is resolved read-only from the task, the issue and the recorded decisions. Everything resolved is printed before any review starts.
Phase 1 — Route files to their owners
Changed files are grouped by path, and only groups that actually changed are enabled. Owners come from the live .claude/agents/ roster read on each run, so an agent added yesterday is used today. Read-only recon agents are never given source review; a group with no owner falls back to the built-in Explore and is marked DEGRADED in the report.
Phase 2 — One parallel fan-out
A single message spawns the domain experts plus two scope passes: pass A works the diff side (creep shapes 1-6), pass B works the baseline side (delivery D1-D4 with proof of absence, closeout C1-C4). Up to two general cross-cutting agents join by judgement. All agents share one JSON finding contract and must search before flagging anything as duplicated code.
Phase 3 — Adversarial validation
A non-owning validator reverse-checks every candidate — batched at most 40 per spawn, at most 4 spawns — then merges, de-duplicates and prioritizes P0 to P3 exactly once across all batches. False positives, already-fixed items and duplicates are dropped. Anything unvalidatable becomes UNVALIDATED and forces an INCOMPLETE run.
Phase 3b — Scope gate
If validated scope-creep findings carry no cited decision, or a delivery gap has no proof, one AskUserQuestion asks you: was this sanctioned? The answer rewrites priorities on existing rows only — it can never add a finding, and it never lifts the permanent P2 cap that an unknown baseline imposes. Every question and answer is recorded verbatim in the report.
Phases 4-5 — Merged report and chat summary
One report at .claude/reports/{TIMESTAMP}_superreview/REPORT.md, sorted P0 to P3, every row carrying its verdict, with a Scope Discipline / Blast Radius section. The chat summary repeats the verdict, the validation counts, the scope numbers and the next steps.

Technical details

Mode resolution

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

A prompt that is neither a whole-project request nor a scope token is treated as a focus directive; the mode still resolves via rule 3. Corpus rule: git-ignored is OUT, everything else is IN — tracked and untracked-but-not-ignored files count.

Delegation

Why groups, not one big agent

A big task handed to one agent = an agent gone for an hour: you cannot observe it, cannot correct it, and it usually drifts off-target.

One subagent = ONE bounded unit — here, ONE file group’s review: roughly 5 files, roughly 10 steps. An oversized group is split into two groups rather than handing one agent half the repo, and every task in a fan-out goes out in ONE message.

Every spawn prompt carries six fields. A bare one-line task is never enough:

Field	Content
GOAL	the overall task and why it exists — the point beyond the file edit
ROLE	what this agent owns; what it must NOT touch
SCOPE	exact paths/commands in bounds + explicit out-of-bounds
CONTEXT	what is already done, by whom, what runs in parallel — trimmed to what THIS agent needs
CONSUMER	who or what uses the result next, and the shape it must fit
DONE	acceptance criteria + the exact report shape you want back

Phase 2 fills these from references/agent-prompt.md; Phase 3 fills them for the validator. The contract is part of the template /brewcode:superreview-setup emits, so it is already there the first time you run the generated skill.

Verdicts, gates, and the files in your repo

Verdicts

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

Mechanical gates

Gate output is the only non-adversarial verdict in the skill: CONFIRMED-BY-EXECUTION, cited with the command and the output line. A gate is reported OK only on an explicit GATE <name> OK — quiet output is never read as success. If the toolchain or dependencies are missing, the run records Gates: not run (<reason>) and never invents a result. Gate failures on files outside the review scope are still reported, 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           # runtime expert selection + domain-owner prompt contract
    scope.md                  # baseline, ownership map, creep taxonomy, delivery, closeout, gate
    report-template.md        # merged P0-P3 report layout
    {stack}.md                # java-kotlin | typescript-react | python | go

Commit the directory: your whole team then shares one adapted review standard, and re-running /brewcode:superreview-setup refreshes it when the roster, rules, stack or tracker change.

⭐

Updating plugins

Use /brewtools:plugin-update to check and update the brewcode plugin suite in one command. See the FAQ for details.