adversarial-plan-review

Adversarial Plan Review

Use this skill to test whether a plan is executable, evidence-backed, safe, and complete. This is not a polite checklist review and not an implementation workflow.

Use it with the orchestrator skill. The parent orchestrator runs as gpt-5.6-sol; review subagents run as gpt-5.6-terra with high reasoning.

Scope boundary

First identify the plan being reviewed and the exact review artifacts the user authorizes. Unless the user explicitly expands scope, reviewers may inspect repository evidence but may edit only:

• the plan under review; and
• the dedicated adversarial-review artifact.

Never implement the plan, change production code, add tests, alter dependencies/configuration, or make release/Git-history changes during a plan review.

Sol's protocol

1. Read the plan completely and turn its material assertions into a claim ledger. Include evidence claims, root causes, impacts, priorities, proposed fixes, dependencies, phase ordering, file references, tests, release gates, and definitions of done.
2. Freeze the plan during the first attack round.
3. Dispatch multiple independent Terra attackers. Use all available parallel capacity; if capacity is limited, run additional attack roles in a second wave rather than dropping them.
4. Require evidence-backed attack packets, cross-examination, and an explicit Sol adjudication for every material finding.
5. Permit one designated Terra remediator to revise the plan only after adjudication.
6. Run a second attack round against all revised material.
7. Independently verify every P0/P1 closure before final handoff.

Sol is a referee, not the plan's advocate. A claim survives only when evidence and an executable remediation path support it.

Terra attack roles

Assign non-overlapping roles as capacity permits:

• Finding falsifier: attempts to disprove the plan's cited facts, impact, severity, and root-cause claims from source and test evidence.
• Remediation breaker: finds bypasses, regression paths, and weak tests that let a proposed fix appear complete while the underlying defect remains.
• Execution saboteur: simulates a literal coding agent executing each phase; identifies missing prerequisites, hidden work, unsafe ordering, ambiguous tasks, and unverifiable exit criteria.
• Security and trust attacker: attacks secret handling, credentials, plugins, logging, persistence, network permissions, provenance, and trust boundaries.
• Contract attacker: attacks public APIs, CLI/MCP parity, schemas, transports, result contracts, configuration, and compatibility claims.
• Release-gate attacker: attempts to make the plan's release gates pass while the claimed defect still exists; attacks test isolation, package installation, dependencies, and definitions of done.