rpi-review

RPI Review

Goal

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

Use one selected review worker to compare the complete supplied acceptance boundary as quickly as the evidence permits. The primary review parent owns the final outcome, every route disposition, continuation, and user conversation.

Read references/review.md for the review document contract, method, outcome vocabulary, routing, and conversation protocol. Use templates/review-log.md as the canonical record skeleton.

Flow

1. Resolve one task artifact set: current task-centered plan, latest plan critique, changes record, and relevant research. Use supplied paths or the stable task slug and date. 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 or rpi-quick, and user-retained only when an automatic-session user explicitly keeps Review decisions. If the review record already exists, use only its latest Parent Decision Record participation event and ignore pre-record preference state. Record provenance.
4. Confirm plan markers and task-local Goals, Requirements, Details, References, changes evidence, handoff prose, blockers, remaining work, and follow-up items are reconciled enough to form a credible review boundary. Inspect the review path and parent state when present. An existing builder execution of started, Complete, Partial, or Blocked consumes the one builder invocation; reconcile that record and do not dispatch a replacement. If an existing builder execution has no canonical participation event, stop final Review execution Blocked and outcome Not accepted rather than restoring a stale preference.
5. Before creating a worker reservation, inspect available skills and subagents. A candidate's stable name contains review or reviewer, or its description explicitly says it is used during review; select it only when its description fits evidence comparison and review-document construction for this task. Exclude this skill and other RPI lifecycle phase entrypoints from helper selection. Activate useful matching skills as scoped review criteria. Prefer one matching subagent. When none fits, select an unnamed general-purpose subagent by omitting the agent selection. Retain the selected worker identity or general-purpose and dispatch availability without writing started or dispatching.
6. When no builder execution exists, create the canonical record skeleton at .copilot-tracking/reviews/logs/{{YYYY-MM-DD}}/{{task_slug}}-review.md using templates/review-log.md. Persist Scope and Evidence and Opening Review State, append one stable participation event to Parent Decision Record, then, when parent state exists, require one successful state write that removes pre-record preference and stores only the record pointer/revision. Do not continue if any write fails.
   • When subagent dispatch is unavailable, set builder execution metadata to Blocked (not dispatched: unavailable), append final Review execution Blocked and outcome Not accepted with the exact later-new-review condition, and persist only the record pointer and derived projections in parent state. Do not write started or compare evidence inline. These terminal records consume the current Review even if availability changes later.
   • When availability passes, persist builder candidate identity, depth and provenance, and builder execution started before dispatch. Do not dispatch if this write fails.
7. Dispatch exactly one selected review worker with the stable task identity, review purpose, review depth and provenance, exact scope, acceptance basis, complete artifact set, exact read boundary, canonical template, review-record path, compact return, and write authority limited to the review record except ## Parent Decision Record. For an unnamed general-purpose worker, explicitly prohibit source, plan, critique, research, changes-record, parent-state, and Parent Decision Record edits; user questions; final outcome or route decisions; destination invocation; and nested delegation.
   • In standard depth, require complete coverage of every material contract in the supplied boundary while minimizing elapsed work: one marker-driven comparison, all directly relevant supplied evidence, concise findings, and no restatement, cosmetic feedback, exhaustive strengths, low-impact suggestions, continual narration, or additional workers.
   • In deep depth, require broader cross-evidence tracing, stress-test alternatives and boundaries, and include substantive lower-severity concerns within the same supplied boundary. Deep does not permit open-ended research, nested workers, or a second review pass.
   • The builder writes the evidence body, one complete RV-xxx finding set, proposed execution status and outcome, validation coverage, limitations, and proposed routes. The builder does not ask the user, mutate parent state, select continuation, or invoke a destination.
8. Read the completed review record and compact builder return once. Do not redo the evidence comparison or dispatch another worker. A Partial or Blocked builder result is terminal and must name the unassessed boundary or blocker. On recovery, stranded started is also terminal: record final Review execution Blocked and outcome Not accepted, preserve the evidence, and name the exact condition for a later new Review.
9. 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, and route decision; never rewrite 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, present one finding at a time. Before asking, link the review record and cited evidence, then explain in plain language what was found, why it matters, the proposed route, consequences, uncertainty, and a suggested answer.
   • Use vscode_askQuestions when available. Offer Use suggested action: [plain-language action] as the recommended option, Gather more information, Skip this item, and Finish review decisions; allow freeform input so the user also has an empty response box. When unavailable, present the same choices in chat and wait.
   • Append each answer and its finding, route, owner, rationale, evidence need, and outcome effect before asking about the next item. Gather more information defers or changes the route to the appropriate evidence owner. Skip this item rejects the proposed route without erasing the finding. Finish review decisions stops questions and appends deferred events for every undecided item. Material skipped or deferred findings prevent a conformant final outcome.
   • 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.
10. Decide final execution and outcome from builder evidence and resolved or deferred findings. Append those events only to ## Parent Decision Record; preserve builder-authored evidence and findings. When parent state exists, store only the record path and revision plus derived next_action and follow-up projections.
11. 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. A later implementation does not require another Review.
12. Return the record, builder execution, final review execution and outcome, validation evidence, findings, decision participation and walkthrough status, route dispositions, and next action.