review-feat-plan

/review-feat-plan - Feature plan review

The verdict vocabulary remains APPROVE|REJECT. This review does not inspect JSON task design; /review-tasks-plan owns that later gate.

<input_contract> Read when present and relevant:

• Constitution, Product Brief, analysis index, and clarified PRD;
• product, requirements, epics, and product features;
• spec-index and spec-backbone.

Do not require task records. If they already exist, ignore implementation detail except for an obvious stale contradiction with the current product plan. </input_contract>

<hard_invariants>

• Use a fresh-context reviewer or separate fresh session.
• Before the verdict, load and apply this installed skill's references/finding-adjudication.md semantic pack.
• Reviewer reports findings only. It does not rewrite product decisions or choose between ambiguous alternatives.
• FT-000 remains reserved for Foundation Dev Path.
• REJECT is blocking; APPROVE may include non-blocking notes.
• High-risk, large, and autonomous flows require APPROVE; small manual flows use this gate when required by the operator/Constitution or as recommended. </hard_invariants>

<operator_decisions> If correctness depends on an unresolved product/decomposition choice, return REJECT with the exact question, affected artifacts, decision owner, and repair route. A reviewer recommendation may accompany the question but must not be applied as the operator's decision. </operator_decisions>

<required_outputs> Create:

• .tasks/TASK-MB-REVIEW-FEAT-PLAN/REQUEST.md;
• .tasks/TASK-MB-REVIEW-FEAT-PLAN/TASK-MB-REVIEW-FEAT-PLAN-<STAGE_ID>-final-report-docs-01.md.

The report must contain VERDICT: APPROVE|REJECT, evidence, blocking findings, non-blocking notes, unresolved operator questions, and the owning repair route.

Use TASK_ID=TASK-MB-REVIEW-FEAT-PLAN and STAGE_ID=S-FEAT. The bounded reviewer request must name the inputs above, the output path ending in TASK-MB-REVIEW-FEAT-PLAN-S-FEAT-final-report-docs-01.md, the APPROVE|REJECT vocabulary, and the prohibition on reviewing task implementation detail. This is the reviewer handoff contract; review order and probes remain discretionary. </required_outputs>

<agent_discretion> Choose review order, search tools, working-note shape, additional probes, and depth proportional to risk and evidence. The review dimensions below are coverage criteria, not a required reasoning script:

• clarified PRD and Constitution consistency;
• stable REQ-* IDs and no unsupported scope;
• PRD -> REQ -> EP -> FT traceability, including Product Brief/analysis when present;
• stable unique FT-<NNN>-AC-<NNN> IDs under each feature's ## Acceptance Criteria, matching the owning feature and linked to existing governing REQ-*;
• acceptance closure for material outcomes: each material edge/failure maps to a feature AC or a sourced authoritative out-of-scope disposition with /write-prd change route; each material NFR has an accepted observable target/qualitative criterion, decisive conditions, and verification method across its governing REQ and feature AC;
• coherent feature value, sizing, boundaries, acceptance, and failure behavior;
• where evidence shows multiple acceptance outcomes, lifecycle/release units, or actor/authority/boundary paths, one bounded falsification probe asks whether a concrete second product slice has its own observable value and acceptance and can be verified or released independently;
• truthful clarification_status: pending|blocked handling;
• no bypass from analysis to tasking around /write-prd, /spec-init, /prd-to-features, /spec-design, or required Foundation Dev Path;
• FT-000 reservation;
• visible Foundation pressure signals for /spec-design without creating foundation tasks here. </agent_discretion>