task-final-review git:20261026.df81a7aA

Immutable. This exact content never changes and is served at /api/v1/blob/43bcc49d8ef9c8b4.

---
name: task-final-review
description: >-
  在任务收尾、需要交付前检查时，分别判断需求覆盖、结果验证及独立评审的必要性，
  按需组合自查、脚本校验、运行测试、事实核查、试用或子 agent 评审。
  适用于文档、方案、代码、数据、Skill 及操作结果的核验，
  尤其是要求较多、推理复杂或需遵循明确规范的任务。
  简单任务可只作轻量核对，不因启用本 Skill 就要求独立评审或执行全部检查。
---

# 任务收尾检查

目标是发现遗漏和质量盲点，并据此改善最终产物。
检查目标包括用户要求覆盖，以及结果的正确性与可用性。
自查、脚本、运行测试、事实核查、试用和独立评审都是检查手段，
可分别用于不同目标，按本次任务需要组合。

## 1. 逐项判断需要哪些检查

分别判断各项检查与本任务是否相关、现有证据是否仍充分，
以及新增检查能否覆盖重要风险、是否值得相应成本。

| 检查 | 建议默认 |
|---|---|
| 用户要求覆盖 | 通常作简短核对。要求多、反复修改或保存了原始消息时，再深入复核 |
| 结果验证 | 根据实际结果及可能的失败方式选择方法，也可验证操作后的实际状态 |
| 独立评审 | 在独立视角能补充现有证据、发现盲点，且收益支持成本时采用 |

例如，移动文件可核对目标路径和实际状态，无需读者审阅。
修改计算程序可检查需求和计算结果，是否独立评审另行判断。
复杂报告则可能同时需要需求复核、事实核验和读者审阅。
用户只要求核对某一项时，按指定范围检查。

区分“不适用”“已有充分证据，无需重复”和“需要检查但无法执行”。
缺少环境、权限或子 agent 能力属于执行限制，不能据此记为不适用或通过。
用户明确要求或项目规定的必要检查不能仅因成本高而自行省略。
存在限制时完成能做的部分，并说明相关检查缺口。
普通任务不必为每个未选方法输出说明，也不强制制作完整检查清单。

## 2. 逐项复核用户要求

通常先作简短核对，按要求数量、变化程度及遗漏风险决定深入程度。

**没有单独保存的消息文件**：回顾对话，整理要求及后续补充、修正，
逐项对照当前产物和执行结果。

**用户提到已将消息保存到文件**：收尾前重新认真阅读该文件，
不能只凭先前印象、摘要或关键词命中片段完成复核。
同时核对文件未包含的后续对话，以用户最新的有效说明为准。
文件无法访问时尝试定位或询问，并如实标明检查缺口。

文件较长时，按语义分小段增量阅读：

1. 只读当前一小段。若一个物理行很长，也按其中的要求拆分。
2. 提取这一段的各项要求，对照实际产物，明确各项的处理状态及依据。
3. 记录遗漏、处理决定和待确认事项，完成这一段的分析后再读取下一段。
4. 读完整个文件后，汇总未解决项并核对前后约束，再统一补做确认的遗漏，
   避免未读到后文的限制或更正就先行修改。

关键词搜索可用于定位和交叉核对，不能替代以上完整阅读。
必要时可请子 agent 辅助分段核对，但主 agent 仍需确认汇总结果与遗漏项。

“处理过”指有依据地考虑并作出判断，可能是已执行、
根据适用条件决定不执行、被后续要求替代，或因限制而尚未完成。
可用简短清单记录“要求、状态、依据或产物位置”，不强制另建文件。
区分“已明确考虑”和“已满足”：有理由不做不等于已满足用户的硬性要求。
不要用“不适合”掩盖遗漏或擅自取消明确要求。
需要用户决定或仍有阻碍的事项应如实保留，不能记为完成。

## 3. 选择并执行结果验证

从关键要求和可能的失败方式出发，提出要验证的问题，再选方法。
检查对象可以是文档、代码或数据，也可以是文件移动、配置调整后的实际状态。
优先遵循用户、项目和相关领域已有的有效标准，
补充必要检查时保持任务范围，不为凑检查数量增加验收要求。

以下是按需查阅的参考，不是每次都要跑完的清单：

| 要回答的问题 | 可选方法与参考 |
|---|---|
| 格式、结构、数据约束或程序行为是否符合要求？ | [自动化与功能检查](references/automated-checks.md)：现有校验器、脚本、构建、测试、独立重算 |
| 事实、推理、引用和最终呈现是否可靠？ | [内容与呈现检查](references/content-and-presentation.md)：原始来源核对、逻辑检查、导出与渲染检查 |
| 实际使用是否顺畅，是否真的优于原方案？ | [试用与对比评估](references/behavioral-and-comparative.md)：代表性任务、边界试用、基线与盲评 |

可组合或采用其他更合适的方法，只读本次相关参考。
优先复用已有工具与检查结果，按减少重复工作或提高核查可靠性的收益，
判断是否值得新增脚本，具体选择依据见相关参考。
验证应针对实际交付的版本、文件或操作后的状态，
不能只检查中间稿、源文件、计划或命令是否退出成功。

对关键要求，保留“用什么检查、实际结果、证据位置、覆盖范围”的简短对应关系，
不强制另建报告。区分通过、失败、未执行和不适用。
命令成功、脚本无报错或审阅者同意，各自只能支持其实际检查过的结论。
检查失败时先核实是产物缺陷、检查误报还是环境问题，
不能为取得通过结果而放宽用户标准，或把无法执行记作通过。

## 4. 按需引入独立评审

独立评审是可选的检查手段，可以核验需求覆盖，也可以验证结果质量。
根据本次尚未覆盖的风险、现有证据及独立判断的价值，分别选择视角：

- **读者或使用者视角**：需要别人理解、查阅或使用的复杂产物通常值得采用。
  纯机械核验未必需要这个视角。
- **需求与专业准则核验**：有可对照的材料，且独立核验能补充现有检查时采用。
  不能仅因存在用户要求或 Skill 就自动增员。

可以只选其中一种、组合使用，或不安排子 agent。
独立评审不能替代适用的运行测试或其他必要验证，主 agent 自查也不算独立评审。
决定开展时，读取 [独立评审](references/independent-review.md)，
按其中要求设置上下文、分工与并发队列，并在修订后按需重审，最多 4 轮。

## 5. 综合检查结果并修订

综合需求复核、自动检查和评审反馈，先判断问题，再判断方案，
不能将工具输出或审阅意见直接当作修改指令。
优先处理发现的问题，附带方案和额外想法只作为候选，
先独立思考合适的解法，再决定是否参考或采用，避免被建议锚定：

- **问题是否成立**：核实事实、语境和预期用途，排除误读与个人偏好。
- **根因是什么**：表面症状可能来自更深的结构或概念问题。
- **方案是否合适**：评估收益、额外复杂度、维护成本与其他要求的冲突。
  问题成立也不意味着建议方案合理或最优。
- **是否有更好的做法**：可采纳原方案、调整方案，
  或独立设计另一种方案来解决同一问题。

问题不成立，或改动代价与副作用明显超过收益时，可以拒绝修改并保留理由。
审阅意见不会扩大用户授权。现有授权内可修复已确认的问题，
涉及新增功能、扩大范围、改变用户既定取舍，或副作用无法合理评估的方案，
应先向用户说明并取得确认，不能仅因为子 agent 提出就实施。
审阅者意见冲突时，结合证据与任务目标裁决，不按票数决定。
执行有依据的改动后，确认它改善了产物，并未破坏其他已满足的要求。

## 6. 复核与交付

被修改影响的验证需要重做，无关且已通过的检查不必机械重复。
若评审揭示先前验证未覆盖的失败方式，补充相应检查，
并确认修订后的最终交付物仍满足相关要求。
开展了独立评审时，按其参考文档判断是否重审并遵守总轮数上限。

结束前确认本轮修订没有使先前的需求复核结论失效。
向用户简要说明产物、实际完成的检查及证据、重要未解决项及适用的审阅限制。
不必逐条展示内部判断过程，但不能笼统宣称“全部通过”来掩盖未执行的检查。