rpi-review

RPI Review

Goal

Produce one complete, human-readable, evidence-based review record after implementation finishes, as quickly as the evidence permits. Lead with the scoped assessment and material findings, keep evidence and resolution conditions with each finding, and make the final decisions easy to distinguish from the assessment.

Read references/review.md for the review document contract, comparison pass, optional helpers, outcome vocabulary, routing, conversation protocol, and per-finding walkthrough. Use templates/review-log.md as the canonical record skeleton.

Flow

1. Resolve one task artifact set: current task-centered plan, latest plan critique when one ran, changes record, and relevant research. Use supplied paths, or the work's name and date: the task slug for a task's first work, or the name a later request's documents carry. Stop if multiple unrelated sets remain ambiguous.
2. Resolve review depth. Use standard by default. Use deep only when the user explicitly requests a deep review; do not infer it from task size, complexity, uncertainty, or risk. Record depth and provenance.
3. Resolve candidate decision participation: user-owned for standalone and manual RPI, agent-owned by default for confirmed automatic RPI Agent, and user-retained only when an automatic-session user explicitly keeps Review decisions. If the review record already exists, use its latest Parent Decision Record participation event. Record provenance.
4. Confirm plan markers and task-local Goals, Requirements, Details, References, changes evidence, handoff prose, blockers, remaining work, follow-up items, and validation state are current and reconciled enough to form a credible review boundary. When you will use helper lanes, confirm this from the plan's markers and IDs and the changes record's status and reconciliation sections, and leave the task bodies for the comparison. Inspect the review path. When a review record exists, continue a started review from its saved record, and reuse a finished review unless the user asks for a new one.
5. To start a review, create the record skeleton from templates/review-log.md at .copilot-tracking/reviews/logs/{{YYYY-MM-DD}}/{{task_slug}}-review.md, named like the plan it reviews, or, for a user-requested new review of the same work, at the next numbered path, such as {{task_slug}}-review-2.md. Persist Scope and Evidence and Opening Review State with review execution started and append one stable participation event to Parent Decision Record. When parent state exists, record the review path. Send the opening message defined in the reference.
6. Compare the evidence yourself in one marker-driven pass using the review method in the reference. Activate skills whose descriptions say they are used during review and fit the task as scoped review criteria; exclude this skill and other RPI lifecycle phase entrypoints. When task Requirements: cite a BRD, PRD, or ADR source, or the changes record has Business Alignment entries, also apply references/business-alignment.md. Subagents are optional and follow the user's direction, including using none. When a dispatch tool is available and isolating context-heavy portions would help, split them into narrow independent lanes, dispatch the lanes in one parallel batch before reading the evidence they cover, at the reasoning effort each lane needs, and treat their candidates as suggestions to verify at the cited evidence, or investigate further yourself, before recording a finding. Optional helpers in references/review.md defines lanes, each lane's reasoning effort, the assignment, and the return.
   • In standard depth, cover every material contract in the supplied boundary once while minimizing elapsed work: all directly relevant supplied evidence, concise findings, and no restatement, cosmetic feedback, exhaustive strengths, low-impact suggestions, or continual narration.
   • In deep depth, trace cross-evidence more broadly, stress-test alternatives and boundaries, and include substantive lower-severity concerns within the same supplied boundary. Deep does not permit open-ended research or a second review pass.
7. Write the evidence body as the review proceeds, saving the record each time so a reader can follow it while execution stays started: acceptance and change coverage as each area is assessed, and each RV-xxx finding with its proposed route as soon as it is verified. The finding set is complete, as one set, when execution leaves started. Then write the assessed execution status and outcome, validation coverage, limitations, and the reviewer self-check, and update review execution from started to Complete, Partial, or Blocked. A Partial review names the unassessed boundary and routes the missing work; a Blocked review names its blocker.
8. Resolve every actionable RV-xxx according to decision participation. Treat Decision History within ## Parent Decision Record as the append-only canonical decision log. Append a stable event for each participation, walkthrough, execution, outcome, route, and continuation decision; never rewrite or remove an earlier event. Refresh the section's Current Disposition from those events as a reader-facing projection, not an independent decision authority.
   • For user-owned or user-retained, walk through each actionable finding one at a time as the Review Item Walkthrough in references/review.md defines, and persist each answer before the next item. A user-retained automatic session stays automatic and resumes once the decisions are recorded.
   • For agent-owned, skip all per-item questions, record the walkthrough as skipped-auto, and decide every proposal from evidence. Do not treat the later automatic follow-up selection as this walkthrough.
9. Decide final execution and outcome from the evidence body and resolved or deferred findings. Append those events only to ## Parent Decision Record; preserve the evidence body and findings as written. When parent state exists, store only the record path plus derived next_action and accepted follow-up projections.
10. Route each accepted gap once: implementation defects to later rpi-implement, decision gaps to rpi-plan, evidence gaps to rpi-research, and residual work to a distinct follow-up.
11. Close with the Final response.