review-plan-implementation

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Review Plan Implementation

评审计划实现

Goal

目标

Given a

.plan.md

file, validate the implementation by following the plan's

## Reviewer Handoff

instructions and reporting whether code changes align with the plan.

给定一个

.plan.md

文件，按照计划中

## 评审人员交接

部分的指令验证实现情况，并报告代码变更是否与计划一致。

When to use

使用场景

Use this skill when a user asks to review, verify, or audit work completed from a plan file in

.cursor/plans/*.plan.md

当用户要求评审、验证或审计

.cursor/plans/*.plan.md

路径下计划文件对应的已完成工作时，使用此技能。

Minimal workflow

最小工作流程

Load and validate the plan file
- Read the provided
```
.plan.md
```
  path.
- Confirm YAML frontmatter exists and
```
todos
```
  are present.
- Confirm a
```
## Reviewer Handoff
```
  section exists.
- If
```
## Reviewer Handoff
```
  is missing, stop and report that the plan cannot be reviewed with this skill until that section is added.
Extract handoff instructions
- Parse the
```
## Reviewer Handoff
```
  section and identify:
  - Implementation summary claims
  - File-level changelog entries
  - UI manual verification checklist
Review plan alignment (code review mindset)
- Compare completed todos in frontmatter to the claimed implementation in
```
## Reviewer Handoff
```
  .
- Inspect changed files and verify claims are accurate.
- Prioritize findings:
  - Bugs
  - Behavioral regressions
  - Missing or incorrect implementation versus the plan
  - Missing tests or verification gaps
- If no issues are found, explicitly state that.
Execute or delegate UI verification
- Use the UI checklist from
```
## Reviewer Handoff
```
  as the source of truth.
- Assume the tester has no codebase context.
- Ensure each UI step references a route/page and specific on-page area (section/panel/table).
- If a step is ambiguous (for example component names only), rewrite it into actionable user-facing steps and call out that rewrite.
Report format
- Present findings first, ordered by severity, with file references where applicable.
- Then provide:
  - Open questions/assumptions
  - Plan alignment verdict (
```
aligned
```
    ,
```
partially aligned
```
    ,
```
not aligned
```
    )
  - UI verification status and any blockers

加载并验证计划文件
- 读取提供的
```
.plan.md
```
  文件路径。
- 确认YAML前置元数据存在且包含
```
todos
```
  项。
- 确认存在
```
## 评审人员交接
```
  章节。
- 如果缺少
```
## 评审人员交接
```
  章节，停止操作并报告：在添加该章节前，无法使用此技能评审该计划。
提取交接指令
- 解析
```
## 评审人员交接
```
  章节，识别以下内容：
  - 实现总结声明
  - 文件级变更日志条目
  - UI手动验证清单
评审计划对齐情况（代码评审思维）
- 对比前置元数据中已完成的todos与
```
## 评审人员交接
```
  中的实现声明。
- 检查变更文件，验证声明是否准确。
- 按优先级整理发现的问题：
  - 漏洞（Bugs）
  - 行为回归
  - 与计划相比缺失或不正确的实现
  - 缺失测试或验证漏洞
- 如果未发现问题，明确说明这一点。
执行或委托UI验证
- 以
```
## 评审人员交接
```
  中的UI清单为唯一依据。
- 假设测试人员不具备代码库上下文。
- 确保每个UI步骤都引用了路由/页面和页面上的特定区域（板块/面板/表格）。
- 如果步骤模糊（例如仅提及组件名称），将其重写为可执行的面向用户的步骤，并标注该重写操作。
报告格式
- 首先呈现发现的问题，按严重程度排序，并附上对应的文件引用（如有）。
- 然后提供：
  - 未解决的问题/假设前提
  - 计划对齐 verdict（
```
aligned
```
    ：一致，
```
partially aligned
```
    ：部分一致，
```
not aligned
```
    ：不一致）
  - UI验证状态及任何阻塞问题

Output template

输出模板

Use this structure:

markdown

Review target: `<plan filepath>`

Findings:
1. [Severity] <title> — `<file path:line>`
1. [Severity] <title> — `<file path:line>`

Open questions / assumptions:
1. <question or assumption>

Plan alignment verdict: <aligned | partially aligned | not aligned>

UI verification:
1. <what was verified>
1. <what remains or is blocked>

使用以下结构：

markdown

评审目标: `<计划文件路径>`

发现的问题:
1. [严重程度] <标题> — `<文件路径:行号>`
1. [严重程度] <标题> — `<文件路径:行号>`

未解决的问题 / 假设前提:
1. <问题或假设>

计划对齐 verdict: <aligned | partially aligned | not aligned>

UI验证:
1. <已验证内容>
1. <待验证或阻塞内容>

Notes

注意事项

Do not modify the plan status while reviewing unless the user explicitly asks for updates.
Treat
```
## Reviewer Handoff
```
as the authoritative review scope unless the user expands scope.
If the user asks for a strict sign-off decision, provide a clear yes/no with rationale.

除非用户明确要求更新，否则评审时不要修改计划状态。
除非用户扩大范围，否则将
```
## 评审人员交接
```
视为权威的评审范围。
如果用户要求明确的签署决定，需给出清晰的是/否答复并附上理由。