Selecting reviewers and binding the adversarial route

Read this at Stage 3 (Select reviewers), together with references/persona-catalog.md. It defines the layers reviewers are selected in, the search for project standards paths, the check that shrinks the reviewer list for a small low-risk diff, and the decision between the cross-model peer and the in-process adversarial reviewer.

Reviewers

Reviewer personas are selected in layers. The persona catalog in references/persona-catalog.md (read it at Stage 3) has the full selection criteria and the condition for spawning each reviewer. Each selected reviewer is a generic subagent seeded with a local prompt file from references/personas/; do not dispatch standalone agents by type/name.

Core (always-on): correctness-reviewer.

Standards conditional: project-standards-reviewer runs only when Stage 3b finds at least one applicable standards file (Stage 3b is the project-standards path search below). When the search succeeds but finds nothing, skip this persona and say so in Coverage, because this persona is not allowed to invent standards beyond those files.

Generic conditional:

• testing-reviewer — test files, test infrastructure, mocks, fixtures, or harness behavior changed; or the diff changes meaningful runtime behavior without corresponding test work. Behavioral triggers include new or changed branches, state mutation, API/control-flow behavior, and error handling. Production-file presence alone and non-behavioral edits do not select it.
• maintainability-reviewer — a large or structural diff: substantial refactor, new abstractions, file moves, coupling/type-boundary changes, or at least 200 executable changed lines.
• agent-native-reviewer — an agent-facing feature or surface changed (skills, agents, prompts, tools, MCP, commands, or a product capability expected to be accessible to agents).
• learnings-researcher — there is institutional knowledge to check the change against: <root>/solutions/ exists and a cheap path/title search finds a plausible match for the changed modules or patterns (the existence of a corpus alone is not enough), or, in local scope, the repo's CE config declares Compound Packs (Stage 1b declared_packs). Declared packs need no pre-search; the persona matches their rules itself.

Cross-cutting conditional (per diff):

• security-reviewer — auth, public endpoints, user input, permissions (including feature-flag or entitlement gates controlling reachability)
• performance-reviewer — DB queries, data transforms, caching, async
• api-contract-reviewer — routes, serializers, type signatures, versioning
• data-migration-reviewer — migration files / schema dumps / backfills (see the data-migration spawn gate in Stage 3)
• reliability-reviewer — error handling, retries, timeouts, background jobs
• adversarial-reviewer lens — >=50 changed code lines, or auth / payments / persistence writes / event publication / retry or concurrency semantics / external APIs, or a silent-pass verification mechanism regardless of size. Satisfy this lens with the independent cross-model adversarial pass when a peer job on the approved route starts successfully. Dispatch the in-process adversarial-reviewer when the peer cannot start, or when the fold-in step later finds the peer never ran, or gives up after a retry on the same route fails on a rate limit and restores the local reviewer; do not run both reviews on the same brief.
• previous-comments-reviewer — PR with existing review comments (PR-only, comment-gated)

Stack-specific conditional (per diff): julik-frontend-races-reviewer (Stimulus/Turbo, DOM events, async UI) and swift-ios-reviewer (Swift/SwiftUI/UIKit, entitlements, Core Data, .pbxproj).

CE conditional (migration-specific): local prompt asset deployment-verification-agent — deployment checklist + rollback when the migration gate applies and the change is risky.

Review Scope

A full review always spawns correctness, adds project-standards when applicable files exist, then adds only the generic, cross-cutting, stack-specific, and CE conditionals justified by the diff. This file runs only on the full spine; it does not invent irrelevant domains. A Rails auth feature might add security, reliability, and adversarial while still skipping agent-native and learnings when those surfaces are absent.

Language-Aware Conditionals

Select stack-specific reviewers only when the diff touches runtime behavior they specialize in (async UI races, iOS/Swift lifecycle), never mechanically from file extensions alone. The trigger is meaningful changed behavior in that stack's runtime domain. Structural quality (complexity deletion, 1k-line regressions, type-boundary leaks) belongs to the conditional maintainability-reviewer; do not spawn extra reviewers for language conventions, philosophy, or "strict bar" passes.

Stage 3: Select reviewers

Read the diff and file list from Stage 1 and the helper JSON from Stage 1b. Correctness is automatic; project-standards is decided by the Stage 3b (Discover project standards paths) result. Read references/persona-catalog.md from this skill's directory now; it defines the spawn condition for every other reviewer. Select generic reviewers before domain reviewers: testing for changed test/harness surfaces, or when meaningful runtime behavior changed without corresponding test work; maintainability only for large or structural work; agent-native only for agent-facing work; and learnings when a cheap search finds plausible matches in an existing <root>/solutions/ corpus or, in local scope, the repo declares Compound Packs (Stage 1b declared_packs). For the behavioral testing trigger, require concrete diff evidence such as new or changed branches, state mutation, API/control-flow behavior, or error handling. Do not select testing from production-file presence alone or for non-behavioral edits. For each remaining conditional, decide whether the diff warrants it. Diff-derived helper signals (signals, test_files_changed, agent_surface, has_learnings_corpus) are prompts to consider a persona, never automatic selection. declared_packs is a config fact the learnings selection condition reads, not a diff signal.

File-type awareness for conditional selection: Instruction-prose files (Markdown skill definitions, JSON schemas, config files) are product code but do not benefit from runtime-focused reviewers. The adversarial reviewer's techniques (race conditions, cascade failures, abuse cases) target executable code behavior. For diffs that only change instruction-prose files, skip adversarial unless the prose describes auth, payment, or data-mutation behavior, or the change is itself a silent-pass verification mechanism (next paragraph — a CI/CD workflow is a config file but still gets the adversarial lens). Count only executable code lines toward line-count thresholds.

Treat changed persistence writes, event publication, retry/partial-failure behavior, and concurrency or ordering semantics as concrete data-mutation/external-boundary triggers for adversarial; do not require a framework-specific database or HTTP keyword.

Silent-pass verification mechanisms — select adversarial for the guard itself. When the change is a verification mechanism — CI/CD gating logic, merge-blocking checks, build/deploy steps, coverage/lint gates, or test infrastructure/mocks that could mask production — its risk isn't blast radius, it's fidelity: it can go green while the real thing is red, so the exact "can this false-pass?" lens must run. Select adversarial (and therefore the Stage-4 cross-model pass) for such a change regardless of changed-line count and independent of the auth/data heuristics. The selection question: "If this mechanism is wrong, does it fail loudly or silently pass? A silent-pass guard gets the adversarial + cross-model lens regardless of size." Scope limit: this applies to the mechanism (gating/CI/build/deploy/harness changes), not to ordinary per-feature test assertions — a unit test asserting business logic is the testing reviewer's job, not adversarial's.

**previous-comments is PR-only AND comment-gated.** Only select this persona when both conditions hold:

1. Stage 1 gathered PR metadata (PR number or URL was provided as an argument, or gh pr view returned metadata for the current branch).
2. hasPriorComments from Stage 1 is true (the PR has at least one review submission or issue comment).

Skip it for standalone branch reviews with no associated PR, and skip it for PRs with no prior feedback yet -- there is nothing for the persona to verify, and a spawned subagent that returns empty findings still costs the full subagent startup overhead (persona spec, diff, schema, plus its own gh calls).

Stack-specific personas are additive when runtime behavior warrants them. A Hotwire UI change may warrant julik-frontend-races; a TypeScript boundary change may warrant api-contract only when the diff changes an externally consumed contract, not merely because it exports a symbol.

**data-migration spawn gate.** Select data-migration-reviewer only when the diff includes at least one migration or schema artifact: db/migrate/*, db/schema.rb, db/structure.sql, Alembic/Flyway/Liquibase migration paths, or explicit backfill/data-transform scripts (rake tasks, one-off data migration classes). Do not spawn for model-only changes, query-only refactors, serializers/controllers that reference columns without a migration or schema dump in the diff, or migration tests alone.

For deployment-verification-agent, use the same migration-artifact condition when the change is risky (destructive DDL, backfills, NOT NULL without default, column renames/drops).

Stage 3b: Decide the project-standards dispatch

Stage 1c already paired each criteria file governing this change with the changed files it governs. Decide from that mapping whether the project-standards persona runs. When the instruction-file fallback supplied the criteria for any changed file, name it as the fallback in Coverage. When uncertain, run the persona rather than skip it — an error is never an empty result:

• One or more applicable paths: select project-standards and pass the mapping inside a <standards-paths> block in its Stage 4 context. The persona applies the precedence Stage 1c resolved rather than re-deriving it, and reads the files itself, targeting only relevant sections.
• Empty successful search: do not dispatch project-standards; record project standards: not run (no applicable standards files) in Coverage.
• Search failure or uncertain scope: dispatch project-standards with the uncertainty stated.

Stage 3c: Depth already decided

The Review depth gate in references/modes-and-output.md already chose lite, focused, or full, before this file was read. This stage does not size the run and does not shrink the roster. You are on the full spine. Continue to Stage 3d.

Stage 3d: Bind the adversarial route and final roster

Complete this stage **before reading persona prompt assets, references/dispatch-reviewers.md, or entering Stage 4** (Dispatch reviewers). That reference's persona-file instructions are valid only once you have settled which single route covers the adversarial lens: the peer, or the in-process fallback. This stage makes that exclusive choice between a cross-model adversarial peer and the in-process adversarial-reviewer. Later stages use that choice and must not decide it again, except when the fold-in step finds the peer never ran, or restores the in-process reviewer after a retry on the same route fails on a rate limit.

Both routes share the run directory Stage 1b created; do not create another.

When adversarial was selected and the working tree is the reviewed head (standalone, base:, or local-aligned scope), read references/cross-model-review.md from this skill's directory in full, verify the host as that reference requires, resolve one fixed route and approve it, and make the announcement that reference requires before anything is sent to the peer (its egress announcement, which tells the user what leaves the machine). Before start, write both inputs the reference defines; you, the orchestrator, write them, not the peer. They are the dedicated host-vetted constraints file, and the separate untrusted semantic brief containing intent plus material risk divisions inferred from the current file inventory and diff. Do not embed the diff, mechanically copy every path, or combine the two files. Then start the detached peer job using the reference's exact invocation and persist its job ID, target, requested model/reasoning, and start epoch in working state, recording --start peer in the stage log (references/scope.md) in that same shell call.

• If the runner returns a job ID, the peer covers the adversarial lens for this run. Remove adversarial-reviewer from the local roster immediately. Do not read its local persona asset or dispatch it later — except when the owning fold-in rules in references/cross-model-recovery.md require the did-not-run fallback or the in-process restore after a failed same-route rate-limit retry.
• If no job starts because of a dispatch-infrastructure failure (a non-zero exit before any job id, an unresolved $SKILL_DIR/script path), read references/cross-model-recovery.md at that point and first attempt its bounded same-route hand recovery before accepting the fallback. Re-run the identical resolved route, holding target/model and read scope fixed. Keep retrying only while each failure is a new, plausibly recoverable one and the shared peer deadline holds. If recovery returns a job id, treat it as the branch above (the peer covers the lens; remove adversarial-reviewer). Keep adversarial-reviewer in the local roster as the fallback, and record the peer skip reason for Coverage, only in two cases: recovery is exhausted (a failure repeats or the deadline is spent), or the peer was never eligible to start (selection condition not met, disabled by checkout config, host un-attestable, no different provider, or CLI missing).
• In pr-remote / branch-remote, do not start the peer; keep the selected in-process adversarial reviewer because it can inspect the reviewed refs.

When a job ID is returned and task tracking is active, add a distinct task that names the independent cross-model adversarial review. Keep it in progress while the detached job runs, then record its terminal outcome when the artifact is collected. Never create this task before a peer starts or leave it behind when the local adversarial fallback runs.

Do not proceed until the final local roster is settled. This is a hard rule, not a preference: a started peer and the in-process adversarial reviewer must never both receive the same review brief.

Announce that final team before spawning, as a user-facing summary: name the always-on reviewers plainly, and for each conditional reviewer give the one-line reason it was added (the real concern, not the keyword that matched). Do not put local reviewer model-tier labels ([session model]/[mid-tier]) or the internal names of the scope modes in this announcement — those are internal. Still decide each local reviewer's tier here and keep it in working state for Stage 4. The cross-model line is separate; it uses the model/reasoning and route wording from its reference, which depends on what the peer's receipt attests. This is progress reporting, not a blocking confirmation.