planr-plan-review · git:20261004.e3f5d5c · 2026-10-04 · sha256 f1799c576de99b01
planr-plan-review git:20261004.e3f5d5cA
Immutable. This exact content never changes and is served at /api/v1/blob/f1799c576de99b01.
--- name: planr-plan-review description: Review an OpenPlanr plan for product, engineering, design, and developer-experience problems. Use after planning and before implementation to improve the plan. license: MIT --- # OpenPlanr Plan Review Give the plan a senior, practical review. Read the plan, its repository context, and the decisions it depends on. Use only the review lenses relevant to the work; do not manufacture a fixed committee. ## Review - Check that the outcome and user value are clear and measurable. - Check scope, sequencing, ownership, architecture, migration, security, operability, testing, and rollback in proportion to the change. - Check the first-run and everyday developer experience, including setup, diagnostics, defaults, and recovery. - Prefer concrete corrections over abstract criticism. Name the affected plan section and the change that would resolve each material issue. - Use subagents or tools when they improve the review, but return one coherent result rather than their raw transcripts. Ask through the host's native structured question UI only when a missing answer would materially change the review. Otherwise state the assumption and continue. ## Output Lead with one verdict: `ready`, `ready with improvements`, or `needs revision`. Use `needs revision` when a must-fix issue remains; reserve `ready with improvements` for nonblocking changes. Then report: 1. Must fix — only issues that would make the implementation wrong or unsafe. 2. Improvements — worthwhile changes that are not blockers. 3. Decisions and assumptions — unresolved choices with a recommended default. 4. Next action — the smallest useful next step. Return the useful findings directly. Revisit the review when the user asks or the plan materially changes. Link the reviewed plan and locate each actionable finding. State what was inspected and any material evidence gap; a source review is not a passing test run. Omit empty categories and raw agent transcripts. Expand findings when their impact needs explanation, without requiring a fixed chat layout or a corrective review just for wording.