Review Gate

---
name: review-gate
description: Run independent engineering review gates for any work unit or batch. Use for writer/reviewer separation, role selection, compatibility regression, behavior parity, architecture, error diagnostics, IO/concurrency, Rust style, data/algorithm, product ergonomics, review batches, per-unit verdicts, and durable reports.
---

# Review Gate

Use this skill when work needs independent evidence before verification,
release, or promotion. It is not tied to py2rs or numbered R0-R6 gates.

## Gate Catalog

Select only roles that match the unit risk:

- `compatibility_regression`: existing behavior still passes; use for new
  feature work and control-plane additions.
- `behavior_parity`: old/new implementation parity at a named public seam; use
  for rewrites or compatibility-sensitive replacement.
- `rust_style`: Rust module shape, ownership, visibility, lints, tests, and
  maintainability.
- `error_diagnostics`: structured errors, context, logs, tracing, redaction, and
  debuggability.
- `io_concurrency`: blocking IO, async boundaries, cancellation, retries,
  concurrency limits, resource contention, runtime nesting.
- `data_algorithm`: schema, data structures, numeric assumptions, complexity,
  benchmark claims.
- `architecture`: boundaries, ownership, control-plane purity, adapters, storage,
  rollback/release risk.
- `product_ergonomics`: CLI/API/GUI workflow, messages, recovery, accessibility,
  operational usability.

Composition skills may require a first gate. Example: `py2rs` requires
`behavior_parity`; `feature-addition` defaults to `compatibility_regression`.

## Preconditions

- The reviewer did not produce the candidate under review.
- The unit or batch has an exact input snapshot: commit, graph/manifest revision,
  artifacts, and verification evidence.
- The chosen role is explicit.
- Review report path and claimed unit ids cannot race another active review.
- Writer verification has already run unless the role is reviewing why it cannot.

## Batch Rules

- A batch is a scheduling/evidence container, not one merged unit.
- Claim every unit in the batch before reviewing; release only after the report
  is persisted.
- One report may cover many units, but it must give each unit a verdict:
  `pass`, `pass-with-followups`, `fail`, or `not_required`.
- `not_required` needs a reason from the unit record.
- One failed unit must not erase valid evidence for unrelated passing units.
- Rerun affected gates after remediation when inputs changed.

## Workflow

1. Confirm scope, role, candidate snapshot, writer/reviewer separation, and
   required evidence.
2. Inspect only files, tests, docs, fixtures, and logs needed for that role.
3. Run non-mutating checks when useful.
4. Lead with findings ordered by severity and file/line references.
5. Write a durable report under the project review directory.
6. Do not advance unit state unless the project explicitly assigns coordinator
   duties to this same session.

## Report Shape

```markdown
# Review: <role> / <unit-or-batch>

- Decision: pass | pass-with-followups | fail
- Input: commit, manifest/graph revision, artifact digests
- Scope: unit ids
- Verdicts: per-unit verdicts
- Findings: severity ordered
- Checks: commands and results
- Residual risk:
- State recommendation:
```

## Non-Negotiables

- Do not patch production code in a review-only gate.
- Do not combine unrelated roles to save a report.
- Do not reuse a verdict after candidate, manifest, graph, or artifact inputs
  changed.
- Do not replace failed behavior parity with compile-only evidence.
- Do not require behavior parity for work whose composition policy only needs
  regression evidence.