review-gauntlet

name	review-gauntlet
description	Lean code-review profile over review-deep's engine. Takes a developer prompt and code diff (positional args), runs review-deep's code lenses (correctness, bugs, security, test quality, style) with deterministic aggregation, and emits a terse PASS / NEEDS-WORK verdict — no JSON sidecar. Use after a developer agent produces a diff for a fast multi-lens gate; use review-deep directly when you need the full audit trail, plan-conformance, or runtime lenses.
user-invocable	true

Review Gauntlet

Judging doctrine: the producer-grader split, evidence-on-every-verdict, deterministic-aggregation, and primary-owner dedup rules this profile runs on live in _shared/judge-core.md. review-gauntlet does not re-implement them — it inherits them through review-deep's engine (review-deep is one of judge-core's reference implementations, §10).

review-gauntlet is a thin profile over review-deep — not a separate review engine. It runs review-deep's code lenses (the --reviewers code set) with review-deep's deterministic aggregation, but in a LEAN configuration: positional args instead of named flags, and a terse PASS / NEEDS-WORK report instead of review-deep's JSON audit-trail sidecar.

It exists so the common case — "review this diff, fast, give me a verdict" — has a one-line invocation with no sidecar bookkeeping, while the heavy case (high-stakes substrate / schema / key-shape diffs that want the full audit trail, plan-conformance, runtime lenses, or --prior-sidecar persistent- disagreement tracking) reaches for review-deep directly.

review-gauntlet does NOT define its own reviewer prompts. The lens definitions, severity rubric, anti-pattern catalog, evidence discipline, and aggregation rules are review-deep's — review-gauntlet points at them so the two never drift as a duplicate pair. If you need to change how a lens reasons, edit review-deep; the change flows through here automatically.

---

Invocation contract

/review-gauntlet <prompt> <diff>

Positional args (this is review-gauntlet's contract — NOT review-deep's named --prompt / --diff):

1. <prompt> — the developer's intent (what the diff is supposed to accomplish).
2. <diff> — the code diff to review. Same three accepted forms as review-deep:
   • A git diff output (staged, unstaged, or between commits)
   • A PR number (the skill fetches the diff via gh pr diff <NUMBER>)
   • An explicit paste of the changed code

If the invoker doesn't supply both a prompt and a diff, ask for them before proceeding.

No sidecar. Unlike review-deep (which writes a JSON audit-trail sidecar to .review-deep/<timestamp>.json by default), review-gauntlet writes NO sidecar and NO output file. Its only output is the terse markdown verdict below, printed to stdout. This is the lean contract — a fast gate, not an archived audit trail. If you want the audit trail, run review-deep instead.

---

What runs: review-deep's code lenses, lean

review-gauntlet maps to exactly this review-deep configuration:

review-deep arg	review-gauntlet value	Why
--prompt	positional <prompt>	lean positional contract
--diff	positional <diff>	lean positional contract
--reviewers	code (the code-lens lane)	gauntlet is a static code gate
--plan-step	(never passed)	plan-conformance is review-deep's job; gauntlet's lens set is the 5 always-on code lenses
--output-dir / sidecar	(suppressed)	LEAN: no JSON sidecar written

So an operator running /review-gauntlet <prompt> <diff> gets review-deep's five always-on code lenses with deterministic aggregation:

1. Correctness — diff vs stated intent
2. Bugs — defects in the diff itself
3. Security — adversarial-input / secrets / unsafe-config defects (a free upgrade over the historical four-pass gauntlet, which had no Security lens)
4. Test quality — focus, trim, missing critical coverage
5. Style and conventions — surrounding-code conformance

The sixth review-deep lens, plan-conformance, only runs when --plan-step is supplied; review-gauntlet never passes it, so plan-conformance reports SKIPPED and does not affect the verdict (use review-deep --plan-step ... when you want it). Runtime lenses (--reviewers runtime|full) are likewise out of scope for the lean gate — reach for review-deep when a diff needs them.

Lens definitions are review-deep's, verbatim. Read review-deep's SKILL.md for the authoritative per-lens Scope / Coverage / Non-coverage / evidence-shape / severity-rubric / verdict-threshold sub-sections:

• Correctness lens
• Bugs lens
• Security lens
• Test quality lens
• Style and conventions lens

The anti-pattern catalog (silent-wiring, producer-consumer-drift, codifying-test-diff, silent-fallthrough-in-loop, silent-fallthrough-in-hot-path, duplicate-shape-constants, create-table-without-migration), the universal evidence discipline (every finding cites file:line + excerpt + reasoning), the Block | Nit | FYI severity rubric, and the cross-section dedup / lens-owns-dimension rules all live in review-deep's Anti-pattern catalog and Aggregation sections. review-gauntlet runs them unchanged — it does not restate or fork them.

Lineage note. review-deep's anti-pattern catalog cites this skill as the origin of its first three anti-patterns (silent-fallthrough-in-loop, duplicate-shape-constants, create-table-without-migration came from the historical review-gauntlet Bug Reviewer). Those definitions now live in review-deep as the single source of truth; review-gauntlet defers to them.

Style-lens offload (switchboard, INERT BY DEFAULT)

review-gauntlet inherits review-deep's Style-lens local-judge offload: the Style lens is the only code lens cheap enough to route to a local model, it is off unless switchboard offload is enabled, and on a defer (the default) it falls back to the Claude Style lens with no behavior change. The historical review-gauntlet-style task_class remains a valid switchboard config slice (tier-offload; Switchboard Decision 9) — it is the lean profile's name for the same offload review-deep documents as review-deep-style. Either slice routes ONLY the advisory Style judgment; the four deep-reasoning lenses (Correctness, Bugs, Security, Test-quality) ALWAYS stay on Claude, and the aggregation step's Claude final judge — never the local model — sets the gate (Decision 3).

---

Aggregation and output (lean)

review-gauntlet uses review-deep's deterministic aggregation over the five code lenses' verdicts — the same severity-dominance, lens-owns-dimension, NO-EVIDENCE-handling, and absence/lint dedup rules. The aggregation step is the Claude final judge (Switchboard Decision 9): the lenses advise, this step makes the single PASS / NEEDS-WORK call, and it always runs on Claude.

The difference from review-deep is output only — review-gauntlet emits a terse report and no JSON sidecar:

## Review Gauntlet Results

### Correctness
<findings or "Correctness verdict: PASS">

### Bugs
<findings or "Bugs verdict: PASS">

### Security
<findings or "Security verdict: PASS">

### Test Quality
<per-test verdicts or "Test quality verdict: PASS">

### Style & Conventions
<findings or "Style verdict: PASS">

---

**Verdict: PASS / NEEDS-WORK**

Each finding renders in review-deep's evidence shape (file:line + excerpt + reasoning). The five code-lens verdict lines (Correctness verdict: …, etc.) are review-deep's, verbatim.

Verdict logic (review-deep's aggregated-verdict ladder, narrowed to the lean code-lens gate — no DEFERRED-TO-UAT, since runtime/auth-gate deferral is a review-deep-only path):

• PASS — zero Block findings and zero Nit findings across all five lenses (FYI-only is PASS), and no lens reported NO-EVIDENCE.
• NEEDS-WORK — any Block finding, any Nit finding, any lens at NO-EVIDENCE, or aggregated Nit count ≥ 3 (review-deep's soft-fail threshold).

If NEEDS-WORK, end with: "Want me to fix these issues, or discuss any findings first?"

---

What NOT to do

• Do not re-define the reviewer prompts here — defer to review-deep's lens definitions (re-defining them is exactly the duplication this profile removes).
• Do not write a JSON sidecar or any output file — the lean contract is a terse stdout verdict. Use review-deep when you want the audit trail.
• Do not pass --plan-step or runtime flags — those are review-deep's lane.
• Do not let the local Style offload set the verdict — it is advisory; the Claude aggregation step is the gate.

---

Cross-references

• review-deep/SKILL.md — the engine this profile runs on (lens definitions, anti-pattern catalog, aggregation rules, severity rubric)
• _shared/judge-core.md — the judging doctrine both skills inherit
• review-proof/SKILL.md — primary-source verification discipline
• dev/.claude/rules/code-quality.md — anti-pattern catalog source