review-strategy-selector

name	review-strategy-selector
description	Use after any baseline code review, or when reviewing a change, to deliberately select the right review lenses for THIS change instead of running a generic pass. Classifies by risk, reversibility, requirement clarity, and size, then applies matching strategies from the catalog. Less vibe coding, more deliberate craft.

Review Strategy Selector

The deliberate layer of review. A baseline pass (catalog strategy 1) finds the obvious. This skill decides which additional lenses THIS change actually calls for — and applies them — so review is tuned to the change, not a generic checklist run on autopilot.

The reference for every strategy cited below is catalog.md in this directory (five groups of strategies + composition patterns). Read only the sections you select — progressive disclosure, not the whole file.

When to use

• After a baseline review (strategy 1) has mapped the terrain.
• When asked to review a change, PR, diff, spec, or design.
• Whenever you are both author and reviewer and need to break your own bias.

When NOT to pile on

This is calibration, not always-more. For a trivial-and-safe change (typo, comment, log string, isolated pure function with tests, no money/data/security/production exposure) you may deliberately choose MINIMAL ceremony. When you do, say so explicitly: state that you classified it as trivial-and-safe and chose a light pass. Silence is not calibration — a stated decision is.

Scope and re-invocation

Resolve what to review from the world, never from the conversation. Scope is a diff range, a branch, an explicit PR/file list, or the working-tree change — something re-derivable without trusting memory of "what we just discussed." If $ARGUMENTS is empty and the working tree is clean, do not guess: ask one question with an embedded recommendation (Rule 4), e.g. "I'd review the diff of <branch> against origin/main — confirm?". On re-invocation in the same session, this is also the integrity gate (Rule 3): re-execute from the resolved scope in fresh context; a recalled scope ("the PRs I just reviewed") is itself a memory artifact, not a re-derived target.

Step 1 — Classify the change on four axes

Assess each axis. These, not line count, set the depth.

1. Risk — Does it touch money, customer/PII data, security/auth, or production behavior? Could a defect cause loss, leak, or outage?
2. Reversibility — Migrations, backfills, destructive or in-place writes, schema changes? Is there a bounded path back to the prior state?
3. Requirement clarity — Is the intent unambiguous, or are you inferring what "correct" means? Ambiguity is itself a risk.
4. Size / scope — Blast radius: how many call sites, services, or consumers does it reach? (Not the diff size — the reach.)

The ruler is RISK AND UNCERTAINTY, not line count. A one-line change to a fee calculation or a DELETE predicate is high-depth; a 600-line addition of an isolated, well-tested helper is not.

Step 2 — Map to a depth band

• Trivial-and-safe → minimal: baseline (1) only, plus a stated rationale for stopping (see "When NOT to pile on"). A solo in-context pass is fine here, but the reuse-vs-recompute declaration (Rule 3) is mandatory — if this re-runs an earlier pass, say whether you recomputed or reused, and why.
• Standard → a small set of targeted lenses (typically 2–4) for the non-trivial axes; dispatch each substantive lens to a fresh-context subagent as the default unit of work so the lens recomputes rather than recalls, and each returns its evidence artifact (Task: see "Compose the passes"). Close with fresh eyes (3).
• Risky / irreversible / ambiguous / money-or-data → full adversarial depth in fresh-context fan-out: per-PR as the default unit, per-(PR × lens) for the critical lenses (25, 28, 26); adversarial majority-refute (2, 9) on top; close with a fresh-eyes pass (3) run as a literally separate fresh-context agent, not an in-context re-read.

Step 3 — Select lenses from the catalog

Open the catalog groups matching your non-trivial axes and pick lenses. Read only those sections.

• Always, first (Requirement) → 25 functional correctness / requirement conformance — does it do what was actually asked? The most important lens.
• Money / data / production (Risk) → 26 security, 27 performance, 28 data integrity, 30 observability; add 2 adversarial, 20 pre-mortem.
• Migrations / backfills / destructive (Reversibility) → 23 concurrency, 24 reversibility/rollback, 28 data integrity, 31 operability/rollout, 16 coverage analysis.
• Ambiguous intent (Requirement clarity) → 15 assumption/invariant audit, 32 cross-document consistency, 13 validation against real data, 50 spec self-review.
• Implementation reviewed against a spec/intent → 52 spec-conformance audit (alignment-not-correctness, drift taxonomy, discovery-only), with 25.
• Wide blast radius (Size/scope) → 55 blast-radius/change-impact (map every caller/consumer the change reaches), 29 contract/API, 32 cross-service consistency, 18 test-quality, 34 readability.
• External-dependency / error paths → 21 silent-failure hunting, 22 error-handling adequacy.
• Frontend / mobile / infra / data / experiments → the matching Part-D / Part-E group; open only the relevant subsection.

Worked example — change writes production data via a backfill: Non-trivial on Risk + Reversibility + Size. Selected lenses: 25 (functional correctness — does it backfill what the requirement meant?), 23 (concurrency — backfill contends with live writes), 24 (reversibility — is there a bounded way back?), 28 (data integrity — invariants/transactions hold?), 2 (adversarial — try to break it), closed with 3 (fresh eyes). Skipped frontend/i18n groups — logged as not applicable.

Operator overrides. Before applying the selected lenses, consult deliberate-engineering-overrides: if any selected lens has an operator override (disable / modify / add), honor it and declare the deviation in the Output.

Each substantive lens emits an evidence artifact — and the artifact IS its completion criterion. A lens has not run until it has produced, from THIS pass, the concrete trace of what it examined:

• 25 functional correctness → the requirement clause quoted from its source + the file:line implementing each clause + a per-clause verdict.
• 28 data integrity → the invariant/transaction checked + the file:line it lives at + the concrete case that would violate it.
• 26 security → the attack surface examined + the file:line + the check applied and its result.
• Other selected lenses follow the same shape: name what was examined, cite where (file:line, command + output), and state the verdict.

This is what makes a recalled review visibly incomplete: reused conclusions carry no fresh artifact, so a pass that only reformats prior findings produces empty artifacts and fails its own completion criterion. It is also what exposes overclaimed exhaustion — an artifact that lists three opened files cannot be presented as a whole-file audit of thirty.

Step 4 — Compose the passes

Apply the composition patterns from the catalog's Appendix:

• Rotate the lens each pass — one strategy per pass, never the same angle twice.
• Find → verify — find candidates broadly, then verify each adversarially (9 majority-refute) before acting on it. For unknown-size audits, loop until dry (6).
• Self-review your own fixes (4) — after editing, review what the fix may have broken.
• CLOSE with a fresh-eyes pass (3) in a separate context — the final pass must be independent of the edit history AND of the prior conclusions. In-context re-reading inherits what you already concluded, so it confirms rather than re-sees; dispatch it as a fresh-context agent (or defer to a new session). Always.
• Never silently truncate — if you limited coverage (sampled, capped, skipped a group), log what you deliberately skipped and why. Truncating silently reads as "covered everything," which is a lie of omission.

Step 5 — Coexistence and precedence

When other reviewers or engines are present (e.g. a PR-review toolkit, a feature-development flow), THIS skill decides which to invoke for the change at hand. It may invoke their agents as tactics — e.g. dispatch a silent-failure hunter, a type-design analyzer, or a test analyzer to execute a selected lens.

This skill never requires removing or disabling any other reviewer. It orchestrates; it does not displace. If a present engine already covers a selected lens well, delegate to it and note the delegation rather than duplicating the pass.

Output

Report, briefly: the classification (4 axes), the depth band, the lenses selected (by number) and why, anything deliberately skipped and why, and the findings — each tagged blocking vs. optional (53), and each tied to the concrete evidence produced in this pass (the file:line actually opened, the command run and its output, the requirement clause quoted from source). A finding with no fresh-pass evidence is incomplete, not done — recompute it, don't relay it. End with the fresh-eyes close.