review-work

审查工作

仅依据计划文档和代码库，独立验证实现结果。不接收执行过程中的任何信息。

核心原则

审查者与执行者之间不共享记忆。判断仅依据计划中陈述的目标和代码库的当前状态。

硬性要求

1. 不得接收执行上下文。 不得接收 run-plan 日志、工作者输出、差异、任务完成摘要或对话历史。唯一输入是计划文件路径。
2. 直接阅读计划文档。 从磁盘读取计划文件，而非摘要或转述内容。
3. 自行运行所有测试。 不得相信之前的执行结果。运行完整测试套件和计划中指定的每条验证命令。
4. 结论只能是 PASS 或 FAIL——各级均为二元判断。 分别判断每项成功标准和每项任务的验收标准是否达成；最终结论取所有判断的逻辑与。不设有条件通过，不说“差不多完成”，也不提供部分认可。
5. 结论只评判目标约定。 结论依据：计划中的文件是否存在、验收标准是否达成、测试是否通过、是否存在回归，以及计划成功标准是否达成。其他一切问题——占位符／调试代码、提交消息不匹配、风格问题——均作为建议性发现报告，绝不影响结论。只有不受外观问题干扰的二元信号才有用。
6. 将审查文档保存到文件。 审查结果必须保存为结构化文档。不得只以口头报告结束。
7. 不得修改代码。 此技能为只读。如果发现问题，应予以报告，不得修复。

使用时机

• run-plan 执行完成后
• 用户提出“审查工作”“验证实现”“检查是否按计划正确执行”等要求时
• 实现已完成，但需要独立验证时

不适用时机

• run-plan 仍在执行时
• 不存在计划文档时（请先使用 plan-crafting）
• 目标是进行一般代码审查时（此技能用于验证“实现是否符合计划”）

输入

此技能的唯一输入是计划文件路径。

docs/engineering-discipline/plans/YYYY-MM-DD-<feature-name>.md

以下内容绝不能作为输入：

• run-plan 的执行日志或任务完成摘要
• 工作者子代理的输出或差异
• 验证者子代理的验证结果
• 执行会话的对话历史

流程

阶段 1：加载并分析计划文档

1. 接收计划文件路径作为输入
2. 直接从磁盘读取计划文档
3. 提取以下内容：
   • 目标： 此计划要实现的内容
   • 工作范围： 范围内／范围外
   • 任务列表： 每项任务的名称、验收标准和目标文件
   • 文件结构映射： 要创建或修改的完整文件列表
   • 提交结构： 计划中指定的提交消息和范围
   • 测试命令： 计划中指定的所有测试执行命令

如果计划包含 ## Plan Amendment Log（当执行过程中发现计划缺陷时，由 run-plan 追加），审查应依据修订后的计划进行——该日志属于计划，而非执行上下文。相对于计划目标，若修订削弱了某项标准，本身即为 FAIL 发现。

使用提取的结果作为审查文档的基础。

阶段 2：代码库检查

根据计划中指定的文件检查代码库。

1. 文件存在性检查： 确认计划中指定的所有文件确实存在
2. 内容一致性检查： 检查每个文件的内容是否符合计划要求（函数签名、类型定义、逻辑等）
3. 残留项检查（仅供参考，不作为判定依据）：
   • 占位代码（TODO、FIXME、“稍后实现”、桩函数）
   • 调试代码（console.log、打印调试信息、注释掉的代码块）
   • 计划范围之外的意外更改 这些内容将记录为参考性发现。例外情况：如果某个占位项出现在验收标准要求提供可用代码的位置，则该标准不通过——导致判定结果改变的是该标准未通过，而不是占位项本身。
4. 逐项验证任务的验收标准。 检查计划中列出的每项标准，并记录通过/未通过——每项均为二元判定，不设部分通过。

阶段 3：测试执行

1. 运行计划中指定的所有单项测试命令
2. 运行完整测试套件，检查是否引入回归问题
3. 记录每项测试的结果（通过/失败）
4. 如果有测试失败，记录错误消息

阶段 4：Git 历史检查（仅供参考）

1. 将计划中指定的提交结构与实际的 git log 进行比较
2. 记录提交消息或范围方面的不一致（例如，在一个提交中混入无关更改）

这里的发现仅供参考——计划很少会准确预测提交消息，执行者也可能进行了合理调整。请在审查文档中记录不一致；它们绝不会影响判定结果。

阶段 5：判定和审查文档

判定结果仅根据目标契约计算——即阶段 2（标准）和阶段 3（测试）。

通过条件（必须全部满足——判定结果取决于所有条件同时成立）：

• 计划中指定的所有文件都存在
• 每项任务的验收标准都已满足（逐项二元判定）
• 计划中指定的所有测试均通过
• 完整测试套件未发现回归问题
• 计划的成功标准均已满足

以上任一条件未满足即判定为失败。 不设有条件通过。

绝不能作为判定依据的事项（仅作为参考性发现）：

• 占位代码或调试代码（除非导致某项标准未通过）
• 提交消息或提交结构不一致
• 风格、命名或代码质量方面的观察

得出判定结果后，编写并保存审查文档。

审查文档

保存位置

docs/engineering-discipline/reviews/YYYY-MM-DD-<feature-name>-review.md

（用户对审查文档保存位置的偏好优先于此默认位置。）

文档结构

# [Feature Name] Review

**Date:** YYYY-MM-DD HH:MM
**Plan Document:** `docs/engineering-discipline/plans/YYYY-MM-DD-<feature-name>.md`
**Verdict:** PASS / FAIL

---

## 1. File Inspection Against Plan

| Planned File | Status | Notes |
|---|---|---|
| `path/to/file` | OK / Missing / Mismatch | Details |

## 2. Test Results

| Test Command | Result | Notes |
|---|---|---|
| `pytest tests/...` | PASS / FAIL | Error details if failed |

**Full Test Suite:** PASS / FAIL (N passed, M failed)

## 3. Acceptance Criteria

| Task | Criterion | Met |
|---|---|---|
| Task 1 | [criterion verbatim from plan] | PASS / FAIL |

## 4. Advisory Findings (not verdict inputs)

- [ ] No placeholders
- [ ] No debug code
- [ ] No commented-out code blocks
- [ ] No changes outside plan scope

**Findings:**
- (Describe with file path and line number)

**Git history (informational):**

| Planned Commit | Actual Commit | Match |
|---|---|---|
| `feat: add X` | `abc1234 feat: add X` | OK / Mismatch |

## 5. Overall Assessment

(Summary of the overall judgment. If FAIL, describe specifically which items failed and why.)

## 6. Follow-up Actions

- (If FAIL: list of items that need to be fixed)
- (If PASS: record improvement suggestions if any)

何时停止

遇到以下情况时，立即停止并通知用户：

• 计划文件不存在或无法读取
• 测试执行环境尚未准备就绪（例如，尚未安装依赖项）
• 无法解析计划文档的格式

如有疑问，不要猜测——请询问用户。

反模式

反模式	失败原因
阅读运行计划的执行日志来进行验证	违反信息隔离原则，会受执行者的表述框架影响
不运行测试，而是相信之前的测试结果	执行后环境可能已经发生变化，因此无法独立验证
发现问题后直接修复	违反审查者与实施者角色分离的原则
给出“差不多就行，通过”的判定	不设有条件通过。标准未满足即为失败
因表面问题（提交消息、TODO、风格）而判定失败	会污染二元信号，因琐事触发重试循环。表面问题仅作为参考性发现
口头告知审查结果，却不保存文档	不会留下验证记录，无法追溯
根据计划中未列出的标准进行评判	审查者只能依据计划中的标准进行评判，禁止添加任意标准
接收计划摘要并据此验证	摘要过程中会丢失信息。必须直接阅读原文

最简检查清单

审核完成后自检：

• 直接从磁盘读取计划文档
• 未将运行计划的执行结果作为输入
• 亲自运行了所有测试
• 检查了计划中的所有任务
• 结论为 PASS 或 FAIL
• 已将审核文档保存到文件

后续步骤

审核完成后：

• PASS → 向用户报告结果并建议后续步骤（创建 PR、部署等）
• FAIL → 向用户报告失败项。如果需要修复，建议切换到 run-plan 或 systematic-debugging 技能
• 如果计划本身存在问题 → 建议返回 plan-crafting 技能修改计划

此技能本身不会调用下一个技能。它会保存审核文档、报告结果，并由用户决定下一步。