review dynamic

This skill is different. /brewcode:review is not shipped with the brewcode plugin. It is generated into every target project by /brewcode:setup — tailored to the project’s tech stack, detected agents, coding conventions, and etalon classes. Every project ends up with its own /brewcode:review, adapted to what that codebase actually looks like.

What it does

A single invocation runs a full multi-phase pipeline:

1. Codebase study — parallel Explore agents scan the repo topology, tests, and DB layer.
2. Group formation — enables main-code, tests, db-layer (and any project-specific groups like security) based on detected files.
3. Parallel review — N agents per group run simultaneously; each one runs the project’s adapted checks and rules.
4. Quorum collection — findings are clustered by file, line range (±5), and category; only clusters with ≥M unique agents are confirmed.
5. DoubleCheck — one Opus reviewer re-verifies every confirmed finding (exists? accurate? actionable? right severity?).
6. Critic (optional) — devil’s-advocate Opus agent challenges the whole review, looking for issues every reviewer missed.
7. Report — prioritized findings (P0 Critic → P1 DoubleCheck-confirmed → P2 quorum only → P3 exceptions).

Invocation

/brewcode:review "<prompt-or-file-path>" [-q|--quorum [G-]N-M] [-c|--critic]

Parameters

Argument	Meaning	Example
prompt	Plain-text review focus	/brewcode:review "auth module PR 123"
file path	Read file as review instructions	/brewcode:review ./review-focus.md
-q N-M	N agents per group, M quorum threshold	-q 5-3 → 5 agents, needs 3 confirming
-q G-N-M	G groups, N agents/group, M quorum	-q 3-4-2 → 3 groups × 4 agents, quorum 2
-c / --critic	Enable Critic phase 5.5 after DoubleCheck	-c
Default	-q 3-2 (3 agents per group, quorum 2), no critic	—

The skill also auto-enables Critic when the prompt contains the words critic, критик, or с критиком.

How generation works

Quorum semantics

Findings are de-duplicated before being counted toward a quorum. Two findings from different agents are treated as the same finding when all of:

Criterion	Tolerance
File path	Exact
Line range	±5 lines
Category	Same or equivalent
Description similarity	≥0.6 semantic

Only unique-agent counts matter: five findings from one reviewer still count as one vote, not five. If unique_agents ≥ M the cluster is confirmed; if not but severity ∈ {blocker, critical} it becomes a P3 exception (surfaced but below quorum); otherwise discarded.

Merge rules within a confirmed cluster: longest description, highest severity, first non-null suggestion, averaged confidence, min/max line range, full list of contributing agents.

The Critic phase

When -c / --critic is set (or the prompt mentions critic / критик), an extra pair of phases runs after DoubleCheck:

• Phase 5.5 — Critic. A single Opus reviewer is given every confirmed, rejected, and discarded finding plus the raw source, and tasked with finding what everyone missed. Its output category is missedFindings.
• Phase 5.75 — DoubleCheck Critic. A second Opus agent verifies the Critic’s own findings using the same CONFIRM/REJECT verdict JSON.

Anything that survives both stages gets top priority (P0) in the final report.

Tech-specific checks

The template ships with example check blocks for the major stacks:

When /brewcode:setup detects your stack, only the relevant block is written into SKILL.md. Multi-stack projects get multiple blocks.

Related

Files in a target project

<project>/
└── .claude/
    └── skills/
        └── brewcode-review/
            ├── SKILL.md                      # instantiated skill (~460 lines)
            └── references/
                ├── agent-prompt.md           # standard/DB/Critic agent prompts
                └── report-template.md        # report layout + severity ladder

The skill is committable — you can check it into version control so your whole team shares the same project-adapted review standard.