plan-review

Plan Review Skill

Reviews a phase plan for soundness before implementation starts. Validates the design, incorporates deferred improvements from prior phases, and produces a decision log. This is Gate 1 — run it after /next-phase-plan and before /enrich-phase-plan.

Trigger

/plan-review [plan-path]

If no path is given, ask the user.

Command-line Tools

• use fd instead of find
• use rg instead of grep

Process

Step 1: Identify Inputs

1. Phase plan: If [plan-path] was given, read it. Otherwise ask the user:

   "Which plan file should I review? (e.g., plans/phase-4/PHASE_PLAN.md)"

   Read the full plan content.

2. Deferred improvements (from prior phases):

   fd deferred.md notes/pr-reviews/
   

   • If one or more deferred.md files are found, list them to the user and read all of them. Include their contents in the review.
   • If none exist, proceed without deferred context.

3. Project memory (always):

   MEMORY_DIR="$HOME/.claude/projects/$(pwd | sd '/' '-')/memory"
   

   Read $MEMORY_DIR/MEMORY.md and every linked memory file.

Step 2: fortran-architect Review

Pass everything to the fortran-dev-pipeline:fortran-architect agent with this prompt:

You are performing a pre-implementation architectural review of a Fortran scientific project.

<phase_plan>
{{PLAN_CONTENTS}}
</phase_plan>

<deferred_improvements>
{{DEFERRED_CONTENTS — or "None" if no deferred.md files were found}}
</deferred_improvements>

<project_memory>
{{MEMORY_CONTENTS}}
</project_memory>

Answer these three questions:

1. **Design soundness**: Does this plan produce a sound design?
   - Are there architectural gaps the plan doesn't address?
   - Are there numerical stability pitfalls, interface mismatches, or API decisions that are hard to reverse?
   - Are there missing error handling strategies or module boundary violations?
   - Are there INTENT declaration patterns, KIND parameter conventions, or interface requirements implied but not stated?
   - If the plan looks sound, say so explicitly.

2. **Deferred item decisions**: For each item in `<deferred_improvements>`, decide:
   - **Absorb** — incorporate it into this plan (specify which section to update and how)
   - **Defer again** — not yet warranted (specify a concrete updated precondition)
   - **Close** — not worth doing (explain why)

3. **Recommended plan amendments**: List concrete additions or changes to the plan, if any. If no changes are needed, state "No amendments required."