rpi-plan

RPI Plan

Goal

Produce an implementation-ready, ordinary Markdown plan and separate phase details. Record user intent in a concise freeform ## User Decisions and Requirements list, then maintain independently editable planner-synthesized goals, scope, requirements, and acceptance criteria. The primary planner owns both artifacts, orchestration, revisions, critique timing, and the final readiness decision.

Read references/planning.md for readiness, executive-summary, delegation, 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 that captures the user's task, goals, requirements, or accepted decisions. Preserve the user's meaning without forcing entries into categories. Distinguish evidence, assumptions, and open choices. Treat supplied evidence as the starting point, not as a reason to repeat investigation.
2. Create or revise these artifacts with one stable task ID, current Pxx phase IDs, and current Pxx-Txx task IDs. Initialize and maintain the plan's ## Follow-Up Items section for discovered work outside the active approved plan.
   • .copilot-tracking/plans/{{YYYY-MM-DD}}/{{task_slug}}-plan.md
   • .copilot-tracking/details/{{YYYY-MM-DD}}/{{task_slug}}-phase-details.md
3. Before substantive phase drafting or delegation, persist the canonical planning state in the plan and phase-details sections that own it. Record task identity, interpreted planning goal, user decisions and requirements, goals, scope and non-goals, initial evidence and readiness assessment, active boundaries, unresolved decisions or blockers, and resolved artifact paths when applicable. The plan owns task-wide state; phase details own the initial phase direction and task-level context.
4. Send one canonical RPI Plan opening after that state is persisted and before substantive phase drafting or delegation. Follow the opening shape in references/planning.md.
5. Assess supplied and completed evidence against goals, requirements, acceptance criteria, dependencies, material risks, complexity, uncertainty, and decision-critical choices. Reuse adequate evidence and activate rpi-research only when one of those dimensions reveals a demonstrated planning gap.
6. Use templates/implementation-plan.md for the overall plan and templates/implementation-details.md for evidence-based phase detail. Keep ## User Decisions and Requirements as a concise freeform list, with optional source pointers in entries when useful. Before ## Phase Checklist, maintain separate top-level ## Goals, ## Scope and Non-Goals, ## Functional Requirements, ## Non-Functional Requirements, and ## Acceptance Criteria sections. Synthesize and update those sections from current user input and evidence without duplicating the list. Follow the executive-summary protocol, placing the summary after task metadata and before sources, and keep it synchronized with every material plan change. Put contextual phase and task markers immediately before their headings.
7. Use one or more RPI Planner subagents for bounded planning assignments. A dispatch may refine phase details, examine supplied evidence, propose decisions or options, expose assumptions, or challenge and refute current goals, phases, or tasks with counter-evidence. Give each dispatch the exact artifacts, relevant evidence, assignment, allowed write boundary, and expected return. Run independent assignments in parallel and dependent assignments sequentially. The primary planner evaluates every return and decides whether to add, update, delete, recreate, reorder, split, merge, or replace goals, scope, non-goals, requirements, acceptance criteria, phases, tasks, or details. Subagent output does not automatically become plan content.
8. Apply a clear user decision or requirement change directly, without a redundant question. When a decision-critical change remains unclear, use a small focused vscode_askQuestions set. Before asking, send a conversation message that states the affected user decision or requirement and plan area, the evidence or conflict, viable choices, material consequences, a recommendation when evidence supports one, and Markdown links to relevant planning artifacts, documents, code, or authoritative external sources when available. Apply the user's answer to the freeform list and all affected synthesized sections. Reconcile current sections, IDs and markers, dependencies, executive summary, details, and ## Follow-Up Items after every material revision.
9. Keep the stable overall task ID and current Pxx and Pxx-Txx markers for navigation. During planning, the primary planner may add, update, delete, recreate, reorder, split, merge, or replace phases and tasks, and may renumber current IDs so the plan and details remain aligned. Remove obsolete active content rather than retaining it for identifier history.
10. Run one final-candidate internal critique by default, only when the primary planner judges both the plan and phase details to be implementation-ready candidates.

• Before dispatch, lock applicable test ownership, exact removals or none, maximum additions, canonical and generated targets, semantic-versus-regression coverage, and validation evidence in the candidate.
• Dispatch a fresh critique worker that activates rpi-plan-critique with the exact task context, caller requirements, research and evidence pointers, plan and details paths, current user decisions and requirements, dependencies, acceptance criteria, and one critique output path.
• Give the critique worker read access to the supplied evidence and write access only to the critique artifact. Do not critique an initial draft merely because it exists.
• Require one complete actionable finding set. 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. Apply compatible planner-owned corrections in one coherent batch. Reject a conflicting recommendation when current user direction already resolves it. Ask the smallest decision-critical question only when a significant or divergent finding is not resolved by current user direction and affects requirements, scope, architecture, acceptance criteria, dependencies, or evidence boundaries.
• Record every finding disposition in the plan's standalone top-level ## Critique Disposition section and finalize without running another critique. A Revise verdict means revise the candidate or obtain the required user decision; it never creates a critique loop.

1. Prepare the plan, phase details, 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.