rpi-implement

RPI Implement

Goal

Deliver the approved outcome by following the current task-centered plan. Keep the plan current as new information comes to light, check off work as it completes, and keep a condensed changes log of the behavioral and functional changes made, so the caller can trust what was done and what remains.

Flow

1. Resolve the exact plan, the one supplied or .copilot-tracking/plans/{{YYYY-MM-DD}}/{{task_slug}}-plan.md, where {{task_slug}} is the work's name: the task slug for a task's first work, or the name a later request's documents carry. Resolve the declared invocation scope: the full plan, one Pxx phase, or one Pxx-Txx task. Read each in-scope task's Goals:, Requirements:, Details:, Guidance: when present, References:, and Dependencies: blocks, follow the linked references, and check the plan's decision and risk tables for rows that name the task. The declared scope limits completion claims and active work.
   • Before source changes, read the plan's Planning Readiness and Critique Disposition. Implementation does not require a critique; a skipped or absent critique is not a blocker. When the plan is marked not ready, records open blockers, or has unresolved blocking critique findings, name them and confirm with the user before implementing affected tasks, unless the user or the confirmed automatic parent already directed implementation with them known.
   • An approved plan is an implementation-ready plan for the declared scope, not a human sign-off. A direct /rpi-implement request needs no additional plan-approval prompt. Agent self-checks are not human attestations; human review applies only when an instruction, domain artifact, or explicit user requirement names it for the affected action, and its checkboxes stay human-owned.
2. Create or continue .copilot-tracking/changes/{{YYYY-MM-DD}}/{{task_slug}}-changes.md using templates/changes-log.md, named like the plan it implements: a plan named for a later request's work, such as task-board-polish-plan.md, gets task-board-polish-changes.md. Record each completed item under a descriptive heading tied to its plan marker, describing the behavior or functionality that changed rather than the edits made.
3. Before substantive source edits, bring the plan checklist, changes record, and any related state tracking artifacts current, then send the implementation opening defined in references/implementation.md.
4. Start with the first unchecked dependency-ready plan item in declared scope and work through eligible items in plan order. When a task's Requirements: hold and its changes-record entry exists, check the Pxx-Txx marker immediately. Check a Pxx phase only when it is in scope and every task in it is checked. Do not check markers outside declared scope. Implementation needs no subagent. Use subagents only when a dispatch tool is available and the user's direction allows them, including using none. When you use them, run dependency-ready tasks that change different files in one parallel batch, keep dependent or same-file work in sequence, and verify each result yourself before checking its marker. Run a subagent on Claude Haiku 5.5 (copilot) at max reasoning effort, passed as dispatch parameters when the tool accepts them, unless the user names another model or the subagent's frontmatter declares its own. 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.
5. When new information comes to light, classify it using references/implementation.md: ordinary local judgment, an implementation-only annotation, follow-up-only work outside the active plan, or a plan change that may need a user decision.
   • When completed work creates something a later task needs that the plan does not already name, such as a class, API, contract, utility, fixture, or path, add a Guidance: block immediately after that task's Details: with the concrete pointer. This needs no user decision.
   • Keep the change map current when a plan update adds, merges, splits, renumbers, or removes phases or tasks: update the tags in After, and in Before when the plan has one, and each phase's Changes in the map: line, or, in a plan written with phase diagrams, those diagrams, using existing part IDs. When an update starts to change how parts connect, add a Before anchored to pre-change evidence.
   • When a plan update changes, or completed behavior differs from, a requirement that cites a BRD, PRD, or ADR, add a Business Alignment entry as references/implementation.md defines.
6. Ask for the smallest decision-critical user input only when available evidence cannot support a responsible user-owned decision. Persist the result in the plan and the changes record. When requirements, scope, architecture, capability, safety, dependencies, or evidence must change, update the affected plan sections under references/implementation.md. A significant or divergent choice needs a user decision first, and affected dependent work pauses until it is recorded; an evidence-backed clarification needs no user question. The confirmed user decision remains authoritative. Do not run a critique from implementation; a follow-up critique runs only when the user asks for one.
7. Run the checks the task's Requirements: or Details: name and record each result in the changes record as passed, failed, skipped, or unavailable with its reason. Validation alone does not resume paused dependent work.
8. When declared scope finishes, bring the changes record, blockers, completion markers, remaining work, and validation state current. Report active plan markers outside the scope as remaining work. Report full-plan completion only when the full plan was declared and every marker has completion evidence.
9. Before handing a full-plan or review-ready scope to Review, reconcile plan markers and task-local context, completed-work entries, handoff prose, blockers, remaining work, follow-up items, and validation state. Compare completed behavior with every cited BRD, PRD, or ADR requirement and add any missing Business Alignment entry.
10. Return the current implementation result to the caller using the return contract below.