Skill: Review Plan

Your goal is to CRITICALLY review the given implementation plan. Provide thorough, constructive feedback that enhances the plan's quality and likelihood of successful execution and solving the stated goal.

Fan out parallel read-only subagents, each assigned a different plan-review area, then synthesize the highest-signal findings. Each subagent goes deep on one area, catching gaps a single pass misses.

Review Areas

Pick 2–4 areas based on the plan's complexity and risk profile.

Workflow

1 — Scope

• Look for a plan in session memory at /memories/session/plan.md first.
• If no session plan exists, check for a plan file the user points to, or a plan visible in the conversation context.
• If there is nothing to review, ask the user to run the Plan agent first or point at a plan file.

2 — Fan Out

Launch 2–5 parallel subagents using the area prompts below. Each subagent works in isolation — do not share one area's findings with another before synthesis.

Each gets a self-contained prompt with its area, the plan location, and the return format. Subagents read the full plan from session memory themselves. Subagents may surface findings their area doesn't explicitly list — don't constrain them to only the listed focus items.

3 — Synthesize

When all subagents return:

1. Deduplicate findings that overlap across areas (e.g., a feasibility gap that also shows up as a sequencing problem).
2. Order by severity: missing requirements > incorrect assumptions > sequencing errors > scope issues > weak verification > minor risks.
3. Apply the signal filter — drop anything that wouldn't actually cause problems during implementation.
4. If no blocking issues survive, say so and note any areas where the plan could be strengthened.

4 — Save Findings

Always save the synthesized findings to session memory at /memories/session/plan-review.md. This makes them available for follow-up turns, plan revision, and cross-referencing during implementation.

5 — Revise or Report

• Review-only: if the user said "only review", "just review", or "read-only", stop after reporting.
• Default (review-and-revise):
  1. For each actionable finding, propose a specific revision to the plan — what to add, remove, reorder, or clarify.
  2. Apply revisions to the plan in session memory (/memories/session/plan.md), preserving the plan's existing structure.
  3. After revising, re-read the updated plan to confirm the revisions are coherent.
  4. Report what was revised and any remaining items that need the user's input or a decision.

Signal Filter

Before reporting a finding, ask: Does this change what a developer would actually do — or how likely the plan is to succeed? Ground every finding in something observable: a file that doesn't exist, an API that behaves differently, a requirement the steps don't cover, a sequence that creates rework.

…