Execute Plan

Goal

Execute a plan stored in .cursor/plans/*.plan.md, updating todo statuses as work progresses.

Minimal workflow

1. Load the plan file

   • Read the provided .plan.md path.
   • Confirm the plan uses the expected YAML frontmatter with todos.
   • If the path or format is missing, ask the user for clarification.

2. Execute tasks with status transitions

   • When starting a task, set its status to in_progress.
   • Keep at most one in_progress task at a time.
   • When a task is finished, set its status to completed.
   • Update the plan file after each status change.

3. Handle scope changes

   • If the user adds or changes requirements, update the plan file to reflect the new or adjusted todos.

4. Output formatting

   • In responses, reference the plan file path and describe what was completed or is in progress.

5. Completion requirements

   • When all todos are completed, output a Markdown block that begins with:
     • I just implemented <plan filepath>. Review the plan, review all code changes, and determine if the changes align with the plan. Then have a UI testing subagent manually verify any and all front-end changes.
   • Below that opening line, include:
     • A concise summary of all changes made while executing the plan.
     • A file-level change log describing what changed in each file and why.
     • Clear, actionable instructions for a UI tester to manually validate the changes, using a generic tester alias (for example, ui-ux-tester).
       • Assume the tester has zero knowledge of the codebase.
       • For every manual check, specify where to go in product terms (route/page URL and the relevant section, panel, or table).
       • Avoid component-only references (for example, “DatePicker”, “TableRow”, “Modal X”) unless paired with exact on-page location and user-visible labels.
       • Prefer task language the tester can execute directly: “Open <route>, click <button label>, verify <expected result>.”
   • Write the same completion Markdown (opening line + summary + file-level change log + UI tester instructions) back into the .plan.md file under a new section named ## Reviewer Handoff.
     • This section is for reviewers to reference later.
     • Do not include the request for approval to archive the plan in this .plan.md section.
   • The summary must include the plan name and its filepath.
   • After the summary, ask the user for approval to archive the plan.
   • If the user approves, move the plan file from .cursor/plans/ to .cursor/plans/archive/ and confirm the new location.

Reviewer Handoff Template

Use this exact structure in the final user response and mirror it in the plan file under ## Reviewer Handoff (excluding the archive-approval ask in the plan file):

I just implemented <plan filepath>. Review the plan, review all code changes, and determine if the changes align with the plan. Then have a UI testing subagent manually verify any and all front-end changes.

Implemented plan: **<plan name>** at `<plan filepath>`.

Change summary:
- <high-level outcome 1>
- <high-level outcome 2>

File-level changelog:
- `<absolute-or-workspace-relative-path>`: <what changed and why>
- `<absolute-or-workspace-relative-path>`: <what changed and why>

UI manual verification checklist:
1. `<ui tester alias>`: Open `<route>`. In `<section/panel/table>`, click `<control label>`, then verify `<expected result>`.
1. `<ui tester alias>`: Open `<route>`. In `<section/panel/table>`, perform `<user action>`, then verify `<expected result>`.
1. `<ui tester alias>`: Open `<route>`. In `<section/panel/table>`, verify `<visual/behavioral expectation>`.