Execute Plan

# Execution Report: <Plan Title>

> Date: YYYY-MM-DD HH:mm:ss
>
> Mode: Batch | Interactive

## Summary

- Overall short result (Completed | Completed with follow-ups | Blocked)
- High-level outcome in 2-4 bullets

## Phase Results

- Phase 1: <name> — ✅/⚠️
  - Implemented:
  - Verification:
  - Notes:
- Phase 2: ...

## Verification Matrix

- Lint: pass/fail (command)
- Type check: pass/fail (command)
- Tests: pass/fail (command)
- Build: pass/fail (command)
- Manual QA: pass/fail/pending

## Deviations

- List any approved deviations from the original plan.
- If none: `None.`

## Blockers and Resolutions

- Blocker:
- Impact:
- Resolution:
- Status:

## Follow-ups

- Remaining tasks, if any
- Recommended owner/next action

## Changed Files

- Relative path list (grouped by area if large)


---
name: execute-plan
description: Execute an approved implementation plan exactly and safely. Use for ExecPlan-style plan execution, resumable phase checklists, multi-hour implementation work, migrations, significant refactors, and plans that require verification checkpoints, status tracking, and final reporting.
argument-hint: "[plan path, e.g. docs/.plans/YYMMDD-HHmm-<plan-slug>/SUMMARY.md]"
license: MIT
---

# Execute Plan

## Overview

Execute a pre-approved plan with strict adherence to scope, sequence, and verification. Treat the plan as a living document that records progress, findings, decisions, and outcomes as execution proceeds.

The input is typically: `execute-plan docs/.plans/YYMMDD-HHmm-<plan-slug>/SUMMARY.md`

Do not redesign the plan during execution. If ambiguity or blockers appear, stop and ask.

## Workflow

### Step 1: Initialize

1. **Locate Plan**
   - Confirm the plan path exists and is readable.
   - If a directory is provided, locate `SUMMARY.md` inside it.

2. **Load Execution Context**
   - Load only the project context relevant to the plan:
     - If `docs/SUMMARY.md` exists, read it first.
     - Load only task-relevant detail docs.
     - Prioritize `Code Standard` docs for implementation conventions.
     - If docs conflict with code or user intent, use the available input/question before broad changes.
   - Review the plan’s phase files, context/orientation notes, dependencies, acceptance criteria, idempotence/recovery notes, decision log, and open questions.
   - If an older plan is missing living-plan sections (`Progress`, `Surprises & Discoveries`, `Decision Log`, `Outcomes & Retrospective`), add those sections before execution when the plan is otherwise clear.

3. **Select Execution Mode (Explicit Rule)**
   - Default mode: **Batch**
   - Use **Interactive** when any of the following is true:
     - High-risk changes (auth, payments, migrations, security-critical logic)
     - Irreversible operations (data migrations, destructive scripts)
     - Unclear acceptance criteria
     - User explicitly requests checkpoints
   - If mode is unclear, ask once and proceed with user choice.

4. **Find Next Pending Phase**
   - First `[ ]` phase
   - If none, first `[-]` phase
   - If no pending/in-progress phases remain, go to final verification.

5. **Critical Plan Sanity Check**
   - Ensure each phase has:
     - clear objective
     - file targets
     - verification commands
     - observable acceptance criteria
   - If observable acceptance criteria are missing but can be inferred from explicit phase verification and exit criteria, add them to the phase before execution.
   - If essential details are missing or contradictory, stop and request clarification.

### Step 2: Execute Per-Phase Loop

For each phase in order:

1. **Skip Completed**
   - If status is `[x]`, continue to next phase.

2. **Mark In Progress**
   - Update phase status to `[-]` before making changes.
   - Add a timestamped `Progress` entry in `SUMMARY.md` describing the phase start.

3. **Execute Exactly**
   - Implement only the tasks defined in that phase.
   - Do not expand scope without approval.
   - Write the minimum code that satisf