rpi-plan

RPI Plan

Goal

Produce one implementation-ready, human-readable Markdown plan. Lead with the executive summary and the Phase Checklist so a reader sees what will change and how it is sequenced first; put user direction, pending decisions, readiness, goals, scope, requirements, risks, sources, and critique records after the checklist. Keep implementation context under the task that consumes it. The primary planner authors the plan and owns orchestration, revisions, critique timing, and the final readiness decision.

Read references/planning.md for section order, task block format, formatting conventions, diagrams, readiness, planning extensions, and artifact guidance.

Flow

1. Establish the task identity and build ## User Decisions and Requirements from user prompts, user-pointed external documents, tasks, issues, and prior research. Preserve confirmed direction as a concise freeform list. Record unresolved material choices separately as related decision groups with status, owner, rationale or requested input, evidence, and impact. Treat supplied evidence as the starting point, not as a reason to repeat investigation.
2. Create or revise .copilot-tracking/plans/{{YYYY-MM-DD}}/{{task_slug}}-plan.md with one stable task ID, current Pxx phase IDs, and current Pxx-Txx task IDs. Revise the current plan for the request it serves; for a new request in a session that already has a plan, start a new plan named for that request's work as references/planning.md describes. Initialize and maintain ## Follow-Up Items for discovered work outside the active approved plan.
3. Before substantive phase drafting, persist canonical planning state in the plan sections that own it. Record task identity, interpreted planning goal, confirmed user direction, planning decision participation and provenance, grouped unresolved decisions, goals, scope and non-goals, initial evidence and readiness assessment, active boundaries, blockers, and the resolved plan path.
4. Send one canonical RPI Plan opening after that state is persisted and before substantive phase drafting. Follow references/planning.md.
5. Assess supplied and completed evidence against goals, requirements, dependencies, material risks, complexity, uncertainty, and decision-critical choices. Find the BRD, PRD, and ADR sources for the plan, supplied or found by the quick search, check each source's status, and cite it with its specific identifiers and committed path in each task that implements it, as Business source citations in references/planning.md defines. Reuse adequate evidence and activate rpi-research only for a demonstrated planning gap.
6. Use templates/implementation-plan.md as the single planning artifact. Give every phase a Goals: block that states the coherent behavior or outcome the phase establishes and why it matters. Give every task a Goals: block that states an observable behavior, capability, or state that advances its phase. Avoid prescribing exact implementation steps when evidence permits local implementation judgment.
   • Under each task, fill the labeled blocks in order: Goals:, Requirements:, Details:, References:, and Dependencies:. references/planning.md defines what belongs in each. Do not add acceptance, validation, completion, or unresolved-item blocks; Requirements: is the checkable record, completion is the [x] marker plus the changes record, and open decisions, risks, and questions go in their tables with the affected Pxx-Txx named.
7. Before drafting, look for skills and subagents whose descriptions say they are used during planning or with rpi-plan, and follow each description's guidance on when and how to use it. Use subagents only when a dispatch tool is available and the user's direction allows them, including using none; when you use them, dispatch independent work in one parallel batch. A planning-extension subagent keeps the model and effort its frontmatter declares; a general-purpose subagent defaults to Claude Haiku 5.5 (copilot) at max reasoning effort, passed as dispatch parameters when the tool accepts them, unless the user names another model. The lens critics that rpi-plan-critique dispatches take the effort the critique assigns instead. If a subagent dispatch fails because its model does not support the subagent's reasoning effort, retry it once with reasoning_effort set to medium. The primary planner still authors the complete plan.
8. Resolve material planning decisions using the caller's decision-participation mode.
   • Use user-owned for standalone and manual RPI contexts, agent-owned by default for a confirmed automatic RPI Agent, and user-retained when an automatic-session user explicitly keeps planning decisions. Honor a parent-provided mode when its contract owns continuation.
   • Apply clear confirmed direction directly without a redundant question. Collect unresolved material rows from Planning Decisions and Feedback and order groups by dependency, blocker status, and readiness impact.
   • For user-owned or user-retained, present the plan and relevant research, source, or code links before using the host's question tool, such as ask_user or vscode_askQuestions. Explain the reason, evidence, viable choices and consequences, recommendation when supported, uncertainty, and readiness effect in plain language. Present one related group at a time by default and batch only choices that must be understood together. Add a compact Mermaid diagram only when it materially clarifies the choice. While an RPI Workflow canvas shows the session, also offer Answered in the canvas; when the user chooses it, collect their answers with the canvas's take_feedback action before continuing.
   • For agent-owned, select evidence-supported options from confirmed direction, requirements, and recorded trade-offs. Persist each rationale and readiness effect without prompting. Record unsupported material choices as blockers with the smallest evidence needed rather than guessing.
   • Persist each answer or agent-owned decision in User Decisions and Requirements, every affected plan section, and parent state before presenting the next group or continuing.
9. Keep the stable overall task ID and current Pxx and Pxx-Txx markers for navigation. The primary planner may add, update, delete, reorder, split, merge, or replace phases and tasks and may renumber current IDs so the plan stays coherent. Remove obsolete active content rather than retaining identifier history.
10. Once the phases are stable, and before critique or finalization, add the change map under ## Phase Checklist: an ### After Mermaid diagram of the intended result of all phases, preceded by a ### Before diagram of the evidence-backed pre-change state only when the plan changes how parts connect. Show the parts the plan changes and the parts they connect to, in boxes for where each change lands, with every arrow pointing from the part that acts to the part it acts on; tag each new, changed, or removed part with the phases that make the change, and mark it with a border. A plan that changes one or two parts and no connections names them in one sentence instead. Under each phase, after its Dependencies: block, add a Changes in the map: line naming its parts. Follow Change map for contents, arrows, boxes, labels, marks, captions, and its check list. Keep Before, when present, anchored to pre-change evidence, and update After, the tags, and the phase lines when the plan changes.
11. Unless the user or parent session skips it, run one critique once the plan is implementation-ready. Follow Independent critique.

• Resolve the critique setting first: standard by default, deep only when the user explicitly requests a deep critique, or skip when the user or parent session excludes the critique. Do not infer deep mode from plan size, complexity, uncertainty, or risk, and do not skip without direction. Record the setting and provenance in Critique Disposition and parent state when present.
• Lock applicable test ownership, exact removals or none, maximum additions, canonical and generated targets, semantic-versus-regression coverage, and validation evidence in the plan whether or not the critique runs.
• Before activation, record the critique status as started, and record the critique path in parent state when it exists, so readers follow the record from its first write. On resume, reuse a critique result, a record whose execution has left started. A record still started is not a result: continue it from its finished lenses or rerun it, without asking for recovery consent. Record the interruption kind; a repeat of the same kind for the same critique output reruns only after a changed prerequisite, otherwise stop with the smallest clearing evidence. A follow-up critique with the next numbered output path starts a new allowance. Planning Readiness stays Not ready until the critique result exists and its blocking findings are resolved, or the critique is skipped.
• Activate rpi-plan-critique in this planning context with the depth, any user-set critique-effort, for every lens or for named lenses, as its effort, the user's subagent direction, task context, requirements, evidence, plan and state paths, decisions, dependencies, one output path, and the latest earlier critique when one exists. It runs its own lens assessments, so do not wrap it in another subagent, and brief it as Running the critique describes. The critique reads the plan and supplied evidence and writes only the critique artifact. Do not critique an initial draft merely because it exists.
• In standard, require a complete actionable finding set for the supplied boundary while minimizing elapsed work. Prioritize implementation blockers, contradictions, missing dependencies or acceptance coverage, unsupported scope or architecture, and material risk. Omit plan restatement, cosmetic feedback, exhaustive strengths, and low-impact suggestions. Read all directly relevant supplied evidence needed to assess the material boundary.
• In deep, assess the same supplied boundary with broader evidence tracing, alternative stress testing, and substantive lower-severity concerns. Deep mode does not permit open-ended research.
• Each PC-xxx records its action owner, exact resolving evidence, and whether the planner can apply it directly or needs a significant or divergent user decision.
• Treat confirmed user requests and answers as authoritative when critique advice conflicts with them. Dispose of findings by severity under Finding disposition, resolving every Critical and High finding, and apply planner-owned corrections one finding at a time, or one group of findings that must change together, saving each correction with its disposition before the next so a reader can follow the revision. Reject a conflicting recommendation when current user direction already resolves it. Route a significant or divergent finding not resolved by current direction through the decision-participation protocol in step 8 when it affects requirements, scope, architecture, dependencies, or evidence boundaries.
• Record execution status separately from verdict and preserve every finding with its disposition in ## Critique Disposition, adding every finding as open when the critique result exists. When the critique returns no result, record the limitation and rerun it once the cause is resolved, or record it as skipped when the user directs continuing without it.
• Run at most one critique per plan. Plan changes, including critique-driven corrections, implementation-time updates, and replanning, do not start another, and readiness never waits for one; run a follow-up critique only when the user asks for one, as Finding disposition describes. Rerunning a critique that saved no result completes that critique rather than adding one.

1. Prepare the plan, critique, and downstream changes-record path for the next stage. Treat executive-summary synchronization as a readiness condition. The implementation phase owns creation of .copilot-tracking/changes/{{YYYY-MM-DD}}/{{task_slug}}-changes.md.