rpi-plan-critique

RPI Plan Critique

Goal

Return one substantive, evidence-grounded credibility assessment of an RPI implementation plan. Assess the plan against the supplied evidence with fresh eyes rather than the drafting reasoning, through lens assessments merged into one finding set, as quickly as the supplied evidence permits. The critique is read-only with respect to the plan and writes only the caller-specified critique artifact.

Flow

1. Confirm the task identity, plan, evidence, requirements, decisions, dependencies, task Requirements, critique output path, critique depth, and any lens reasoning effort supplied by the caller. Use standard when depth is omitted. Use deep only when the caller records explicit user direction; otherwise downgrade an unsupported deep request to standard and record the limitation. Standalone use needs only these inputs; no planning parent is required.
2. Read the plan's headings and its phase, task, and requirement IDs, plus the earlier critique when one is supplied. Do not read unsupplied artifacts, perform open-ended research, browse for additional concerns, or infer missing evidence as fact.
3. Before any lens runs, write the critique record at the output path from templates/plan-critique.md with Critique execution: started, the inputs and boundary, and one Lens Assessments row per lens with status queued. The record grows as the critique runs, so a reader can follow it while it runs.
4. Decide who assesses the lenses, following references/lens-assessment.md.
   • When the plan has more than one phase, a dispatch tool is available, and the user's subagent direction allows lens subagents, dispatch the lenses to RPI Plan Critic. Without assessing the plan yourself, choose the lenses and their scope from those IDs, select each lens's reasoning effort, using the user's or caller's level when one is set and otherwise the level the lens's work needs, and send every lens in one parallel batch. The reference covers the fallback when RPI Plan Critic is unavailable.
   • Otherwise, assess each lens yourself, one at a time, with the same lens questions. Set a lens's row to in progress when you start it.
5. Merge each lens's result as it finishes, as Merge the returns describes: set its row's status, add its verified findings under Findings, merge a duplicate into the finding already recorded, and save the record before the next lens or return. The merged set covers the full boundary across requirements, research, phase and task Goals, task Requirements, Details, References, dependencies, decisions, risks, and missed concerns. For a follow-up critique, mark each earlier finding resolved, still open, or superseded against the current plan rather than repeating it, and add new findings for gaps the revision introduced.
   • Assess coverage across the supplied plan and evidence as a whole. Do not require a task to repeat requirements already established elsewhere solely for restatement. A stated requirement alone does not prove implementation coverage; ground required changes in demonstrated omissions, contradictions, or material evidence gaps.
   • Treat missing detail in an abbreviated task or excerpt as a limitation of the supplied evidence, not proof that the full plan omits it. Identify the evidence needed to resolve a decision-critical uncertainty; do not turn the same uncertainty into a separate requirement-restatement finding.
   • In standard, assess the complete supplied boundary while prioritizing implementation blockers, contradictions, missing dependencies or acceptance coverage, unsupported scope or architecture, and material risks. Follow direct evidence and omit plan restatement, exhaustive strengths, and low-impact suggestions so the complete evidence-supported actionable set is recorded with minimal elapsed work.
   • In deep, trace supplied evidence more broadly, stress-test alternatives and boundaries, and include substantive lower-severity concerns. Deep remains one assessment and does not widen research authority.
   • In either depth, return one complete finding set rather than serializing findings across critique passes. Findings land one lens at a time, but the critique is still one assessment with one verdict.
6. Complete the record using templates/plan-critique.md, including each lens's scope, reasoning effort and its source, status, and adopted and rejected candidates under Lens Assessments, then the coverage assessment, verdict, strengths, questions, limitations, and next action. Use PC-xxx findings keyed to relevant requirement, research, phase, or task IDs, graded on the severity scale in references/lens-assessment.md, and fill every field the template gives an actionable finding. A follow-up critique continues the earlier PC-xxx numbering.
7. Record critique execution as Complete, Partial, Blocked, or Not produced, separately from its Pass, Revise, or Blocked verdict; execution leaves started only when the record is complete. When no assessment was produced, record execution Not produced and verdict unavailable, preserve any fragments, and return the limitation; never manufacture a verdict. A passing critique may identify residual risks the parent explicitly accepted.