Adversarial Review

Decide whether the proposed work can responsibly proceed. Find material gaps; do not manufacture findings or redesign the product.

Independence And Context

Use a fresh configured plan_review.workers.<harness> session when available. Pass only the brief, plan, episode state, relevant evidence pointers, repository instructions, and the review question. Do not pass the orchestrator's suspected findings or the full conversation.

Use the repository's existing agent-workspace convention and single kickoff.yaml. A selector under plan_review.workers.<harness> contains exactly one of: an exact harness-native agent, or a direct model with optional reasoning_effort when named workers are unsupported. Honor an explicit current choice, validate a saved selector before use, and never substitute a worker silently. If missing, discover available native workers before asking the user to select or configure one, then update only the active harness entry while preserving every other key.

The review is read-only. The worker must not edit files, implement fixes, or spawn more workers. Under Kickoff, an unavailable independent worker sets the review phase to needs-input or blocked until the user chooses a valid worker or explicitly accepts a non-independent fallback. In standalone use, current-session review is allowed only after the same explicit acceptance and must be labeled non-independent.

When Required

• Always for full work.
• For fast work.
• For tiny work only when route assessment finds material ambiguity, blast radius, consequence, irreversibility, novelty, or coordination—or repository policy requires it.

Assess risk in the work's own domain. Include user journeys, interaction and content states, visual-system consistency, accessibility, trust, compatibility, performance, data and security, delivery, and operations when relevant; do not default to backend concerns.