Execute Plan

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.