execute-plan

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Execute Plan

执行计划

Goal

目标

Execute a plan stored in

.cursor/plans/*.plan.md

, updating todo statuses as work progresses.

执行存储在

.cursor/plans/*.plan.md

中的计划，随着工作推进更新待办事项状态。

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.

加载计划文件
- 读取提供的
```
.plan.md
```
  路径。
- 确认计划使用包含
```
todos
```
  的预期YAML frontmatter。
- 如果路径或格式缺失，向用户请求澄清。
执行任务并切换状态
- 开始任务时，将其
```
status
```
  设置为
```
in_progress
```
  。
- 同一时间最多保持一个
```
in_progress
```
  任务。
- 任务完成时，将其
```
status
```
  设置为
```
completed
```
  。
- 每次状态变更后更新计划文件。
处理范围变更
- 如果用户添加或修改需求，更新计划文件以反映新增或调整后的待办事项。
输出格式
- 在回复中，引用计划文件路径并描述已完成或正在进行的工作。
完成要求
- 当所有待办事项完成时，输出一个Markdown块，开头为：
  - ```
  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.
```
- 在该开头行下方，包含：
  - 执行计划期间所有变更的简要总结。
  - 文件级变更日志，描述每个文件的变更内容及原因。
  - 供UI测试人员手动验证变更的清晰、可操作的说明，使用通用测试人员别名（例如
```
ui-ux-tester
```
    ）。
    - 假设测试人员对代码库完全不了解。
    - 对于每个手动检查项，明确指定产品层面的位置（路由/页面URL以及相关区域、面板或表格）。
    - 避免仅引用组件（例如“DatePicker”、“TableRow”、“Modal X”），除非同时搭配精确的页面位置和用户可见标签。
    - 优先使用测试人员可直接执行的任务语言：“打开
      <route>
      ，点击
      <button label>
      ，验证
      <expected result>
      。”
- 将相同的完成Markdown内容（开头行 + 总结 + 文件级变更日志 + UI测试人员说明）写回
```
.plan.md
```
  文件中名为
```
## Reviewer Handoff
```
  的新章节下。
  - 该章节供评审人员后续参考。
  - 请勿在
```
.plan.md
```
    的此章节中包含请求批准归档计划的内容。
- 总结必须包含计划名称及其文件路径。
- 在总结之后，请求用户批准归档计划。
- 如果用户批准，将计划文件从
```
.cursor/plans/
```
  移动到
```
.cursor/plans/archive/
```
  并确认新位置。

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):

markdown

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>`.

在最终用户回复中使用以下确切结构，并在计划文件的

## Reviewer Handoff

章节中镜像此结构（计划文件中需排除请求归档批准的内容）：

markdown

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>`.