/review-plan

name: review-plan
description: Review/debate plans before implementation with an external reviewer model (Codex CLI by default; Claude Code or Antigravity on request). Can run in plan mode — debates the plan and edits the plan file to fix accepted issues.

Plan Review

Purpose

Adversarially review a plan before implementation to **maximize its chance of achieving the stated target**: achievability, technology or capability claims that do not hold, logic and design flaws, missing steps, and places where the plan patches around a problem that an established standard solves better. Additions are proposed only when the target needs them.

When to Use

After creating a plan, before implementing code. Requires a Markdown plan file with headings.

Inputs

• **Plan path**: the user's (it may be outside the repository, such as a client's plan-mode file), else a single `*-plan.md` in the repo (`ls *plan*.md`, `find ./docs -maxdepth 3 -name "*plan*.md"`). Ask if several or none.
• Round 1 placeholders: `PLAN_PATH` (absolute), `USER_REQUEST` (original request plus the user's latest decisions), `SESSION_CONTEXT` (only what the reviewer cannot read in the plan or the repository: decisions and constraints from the conversation; where real samples live when the work parses, limits or guards input).
• Reply placeholders: `PLAN_PATH`, `SESSION_CONTEXT`, `FIXED_ITEMS`, `DISPUTED_ITEMS`.
• Skill `review-plan`, no mode.

{{PROTOCOL_CORE}}

{{PROTOCOL_VARIANT}}

For this skill, ACCEPT means editing the plan file so it reaches the user's existing target. A change of target, scope, acceptance criteria or architecture direction is a USER DECISION. A standards-based restructuring the plan proposes is not over-engineering when it has evidence (source, spike, breaking scope, migration cost); judge the evidence, and treat "too big a redesign" alone as no reason to reject it.

Completion

APPROVE: if the plan has a `Plan Review` section (loop-plan), set it to `APPROVE (review-plan <session id>, <date>)`; do not add one to other plans. Stalemate: present the deadlocked issues and ask the user. Report rounds, verdict, issues found/fixed/disputed, user decisions, plan edits, and remaining risks.

Rules

• In plan mode, stay in plan mode; the debate takes priority.
• Do not implement code. Never claim approval without `VERDICT: APPROVE` from the reviewer or an explicit user approval.
• Never hide a review-originated expansion inside a fix, test step, assumption, or rebuttal.