Execute Plan
Goal
Execute a plan stored in .cursor/plans/*.plan.md, updating todo statuses as work progresses.
Minimal workflow
- 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.
- 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.
- Handle scope changes
- If the user adds or changes requirements, update the plan file to reflect the new or adjusted todos.
- Output formatting
- In responses, reference the plan file path and describe what was completed or is in progress.
- 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>`.