| name | review-plan |
| description | Stress-test a plan before acting on it. Finds blind spots, missing steps, and wishful thinking, then gives a clear verdict — APPROVE, or REVISE with a fixed-up plan. Substantive plans get a council of critics by default; `quick` or `single-pass` runs one fast review instead. Use right after plan mode, or on any plan file. |
| argument-hint | [file:path] [quick|single-pass] [role:"expert role"] [--peer codex|gemini] |
/review-plan — Stress-Test a Plan
Read the plan, critique it hard, deliver a verdict. For plans of any substance the default is a small council of independent critics with a separate synthesis — three reviewers with different lenses catch more than one. quick or single-pass opts down to a single fresh-context review.
Step 1 — Find and read the plan
In priority order:
- Explicit file — the
file:path argument. If the path doesn't exist: "File not found: [path]. Check the path and try again."
- Plan-mode file — the most recent file in
~/.claude/plans/ (Glob ~/.claude/plans/*.md), when the user just finished plan mode.
- The conversation — a plan developed or pasted in this session.
If no plan is found anywhere, reply: "No plan found. Run /review-plan right after plan mode, or /review-plan file:path/to/plan.md." and stop.
If the plan is under ~50 words, warn — "This plan is very brief; the review may be limited." — then proceed.
Step 2 — Pick the review path and the reviewer
- Council (default). Any plan where a missed flaw would cost real time, money, or credibility: implementation plans, migrations, research designs, proposals, workflow changes.
- Single-pass. Only when the user says
quick or single-pass, or the plan is short and low-stakes (a simple to-do sequence).
Assign an expert role for the critique — infer from the plan's content; the user's role:"..." always wins:
| The plan is about | Reviewer role |
|---|
| Software, automation, AI tools | AI engineering specialist |
| Grants, proposals, funders | Research funding strategist |
| Papers, studies, data analysis | Research methodology specialist |
| Project management, workflows, operations | Operations specialist |
| Anything else | Strategic planning specialist |
Announce: "Reviewing as: meticulous [role]. (Say role:\"...\" to override.)"
Step 3 — Research best practices (skip when quick)
Privacy check before any search: web search sends search terms outside Claude. If the plan includes confidential records, personal contact details, research-participant or human-subjects material, unpublished sensitive work, private financial/legal/medical/school details, or anything the user would not paste into a public website, skip web search and say: "I am skipping web search because the plan appears sensitive; reviewing from the local plan and general domain knowledge." If the plan is safe, run two web searches: "[the plan's main approach] best practices" and "[the plan's domain] common pitfalls". Distill 3–5 principles that bear on THIS plan — they feed the critique. If web search is unavailable, continue and note: "Web research unavailable; reviewing from domain knowledge."
Step 4 — Run the critique
Council path (default)
Follow the bundled council skill — ${CLAUDE_PLUGIN_ROOT}/skills/council/SKILL.md — with:
- Panel: the plan panel (skeptic, pre-mortem, completeness-checker). Type: plan.
- Critic input: the full plan text plus the best-practice principles from Step 3.
--peer codex|gemini: pass it through if the user set it. The council skill checks whether that engine is actually available, asks for explicit send confirmation, and falls back to all-Claude with a friendly note if not. Privacy check first: a peer review sends the full plan to another AI service — if the plan contains confidential, personal, or research-participant material, don't pass --peer; tell the user why and run all-Claude.
The council skill owns the persona-file check, the parallel dispatch, and the mandatory separate synthesis. Don't re-implement those here.
Single-pass path (quick / single-pass / trivial plan only)
Dispatch ONE Task call, subagent_type: general-purpose — a fresh context avoids grading your own homework — with this prompt:
You are a meticulous [role]. Find what's missing, what will break, and what's
wishful thinking. Do not rationalize or hedge.
PLAN TO REVIEW: [full plan text]
BEST PRACTICES CONTEXT: [principles from Step 3, or "none — quick mode"]
Review against 6 dimensions:
1. PRE-MORTEM — it's 3 months later and this failed. Top 3 causes?
2. COMPLETENESS — what's missing that a domain expert would expect?
3. FEASIBILITY — which steps depend on unconfirmed resources, approvals, or data?
4. BEST-PRACTICE FIT — where does the plan deviate, and is the deviation justified?
5. SEQUENCING — hidden blockers? Would reordering reduce risk?
6. SPECIFICITY — could someone unfamiliar execute each step? Flag hand-waves
("figure out", "as needed") and missing success criteria.
Classify each finding: Red (will likely cause failure or major rework), Yellow
(risky but survivable), Green (minor). End with
VERDICT: APPROVE | REVISE — [one-line reason]
Step 5 — Present the review
════════════════════════════════════════
PLAN REVIEW — [plan title]
════════════════════════════════════════
Reviewing as: meticulous [role] · Source: [file / plan mode / conversation]
STRENGTHS
1. [what the plan gets right — be specific]
WEAKNESSES & GAPS
🔴 [issue] → Fix: [specific change]
🟡 [issue] → Fix: [specific change]
🟢 [issue] → Fix: [specific change]
VERDICT
✅ APPROVE — [reason] or 🔄 REVISE — [reason] + revised plan below
When the council ran: take the verdict, blockers, and patches from the synthesis output; include the per-critic one-line verdicts; put the raw critiques in a <details> block at the bottom. If the verdict is REVISE, draft the revised plan yourself from the blockers and patches, marking changed sections [CHANGED] and additions [NEW].
Step 6 — Iterate
Ask: "Apply these revisions, or give me feedback to refine further?"
- Accept → apply the revisions to the plan file (if file-based) or present the final version.
- Feedback → loop back to Step 4 once, with the user's notes added to the critic input.
- After 2 review cycles: "This plan has been reviewed [N] times — further rounds hit diminishing returns. Consider running it and iterating in practice."
Examples
/review-plan ← right after plan mode
/review-plan file:docs/migration-plan.md
/review-plan quick
/review-plan single-pass role:"clinical trial design specialist"
/review-plan --peer codex
