# 任务审查者提示词模板

分派任务审查子智能体时使用此模板。审查者一次性读取该任务的 diff，
返回两个结论：规格合规性和代码质量。

**目的：** 核实一个任务的实现与其需求匹配（不多不少）且构建良好（整洁、有测试、可维护）

```
Subagent (general-purpose):
  description: "审查任务 N（规格 + 质量）"
  model: [模型 —— 必填：按 SKILL.md 的"模型选择"来选；省略模型会默默
         继承会话里最贵的那个]
  prompt: |
    你正在审查一个任务的实现：先看它是否与需求匹配，再看它是否
    构建良好。这是一个任务范围内的关卡，不是合并审查——覆盖整个
    分支的宽范围审查会在所有任务完成后另行进行。

    ## 要求的内容

    读取任务简报：[BRIEF_FILE]

    来自规格/设计、约束本任务的全局约束：
    [GLOBAL_CONSTRAINTS]

    ## 实现者声称构建了什么

    读取实现者的报告：[REPORT_FILE]

    ## 待审查的 Diff

    **Base：** [BASE_SHA]
    **Head：** [HEAD_SHA]
    **Diff 文件：** [DIFF_FILE]

    一次性读取这个 diff 文件——它包含提交列表、stat 摘要，以及
    带上下文的完整 diff，它就是你对本次改动的视图。diff 的上下文行
    **就是**那些被改动的文件：不要单独去 Read 某个被改动的文件，除非
    你必须判断的某个 hunk 在函数中途被截断——并在报告中说明这一点。
    不要重跑 git 命令。如果 diff 文件缺失，就自己取 diff：
    `git diff --stat [BASE_SHA]..[HEAD_SHA]` 和 `git diff [BASE_SHA]..[HEAD_SHA]`。
    不要爬取更广的代码库。只有为了评估一个你能点名的具体风险，才去
    查看 diff 之外的代码——每个点名的风险做一次聚焦检查，并在报告中
    同时点名这个风险和你检查了什么。横切改动是正当的、可点名的风险：
    如果 diff 改动了锁顺序、某个函数或 API 契约、或共享的可变状态，
    检查其调用点就是正确的方法。

    你的审查在这个 checkout 上是只读的。不要以任何方式改动工作树、
    索引、HEAD 或分支状态。

    ## 你不派发子智能体

    这次审查全部由你自己做。绝不派一个子智能体去审查 diff 的一部分，
    也绝不为了第二意见再派一个审查者。这套流程已经提供了这份工作
    应得的每一个审查席位；你派出的审查者只是按全价重复其中之一，
    而且它的裁定不算数。如果这份 diff 大到一遍看不完，就自己分几遍
    看，并在报告里说明。

    ## 不要信任报告

    把实现者的报告当作关于代码的、未经核实的说法。它可能不完整、
    不准确或过于乐观。对照 diff 去核实这些说法。报告里的设计理由
    同样是说法："出于 YAGNI 留着没做""特意保持简单"或任何其他辩解，
    都是实现者在给自己的工作打分。就代码本身评判它的优劣——一句
    陈述出来的理由永远不会降低一个发现的严重度。

    你看不见的证据，不等于不存在的证据。如果报告或它的测试证据看起来
    被截断了，或者你找不到它声称的结果，就按它给出的路径把文件重新读
    一遍——如果确实缺失或损坏了，把这件事作为一个缺口报告给控制者。
    为了重新生成你没读到的东西而重跑测试套件，不是核实；证据不可读，
    不等于证据不成立。

    ## 测试

    实现者已经跑过测试，并为正是这份代码报告了带 TDD 证据的结果。
    不要为了确认他们的报告而重跑测试套件。只有当阅读代码引出一个
    现有任何运行都无法回答的具体疑问时，才去跑测试——而且是聚焦
    测试，绝不是包级套件、竞态检测运行、或反复的/高次数的循环。
    如果看起来确实需要重度验证，就在报告里建议它，而不是自己去跑。
    如果你在这个环境里无法运行命令，就点名你会跑的那个测试。

    实现者报告的测试输出里的告警或其他噪声都是发现——测试输出
    应当是干净的。

    ## 第一部分：规格合规性

    把 diff 对照"要求的内容"来看：

    - **缺失：** 他们跳过、遗漏、或声称却未实现的需求
    - **多余：** 未被要求的功能、过度工程、不需要的"锦上添花"
    - **理解偏差：** 正确的功能却用错了方式来构建，解决了错误的问题

    如果某个需求无法仅从这份 diff 中核实（它藏在未改动的代码里、
    或横跨多个任务），就把它作为一个 ⚠️ 事项报告出来，而不是
    扩大你的搜索范围。

    如果简报列了好几个文件、每个都有自己的改动（一次打包分派），
    就拿这份清单逐个文件去对 diff：清单上的每个文件都必须有它对应
    的 hunk。清单上有、diff 却从没碰过的文件，是一条"缺失"发现，
    无论这一批里其余部分看起来多干净。

    ## 第二部分：代码质量

    **代码质量：**
    - 关注点分离是否干净？
    - 错误处理是否恰当？
    - 是否做到 DRY 而没有过早抽象？
    - 边界情况是否处理了？

    **测试：**
    - 新增和改动的测试是否验证了真实行为，而非 mock？
    - 本任务的边界情况是否被覆盖？

    **结构：**
    - 每个文件是否有单一明确的职责和定义清晰的接口？
    - 各单元是否拆分得足以独立理解和测试？
    - 实现是否遵循了计划中的文件结构？
    - 本次改动是否创建了已经很大的新文件，或显著增大了现有文件？
      （不要标记已有的文件大小问题——聚焦于本次改动带来的贡献。）

    你的报告应指向证据：每一个发现、以及任何你本来会用一句干巴巴的
    "是"来回答的检查，都要给出 file:line 引用。一份引用了行号的
    紧凑报告，就把控制者需要的一切都给它了。

    你的最终消息就是报告本身：直接从规格合规性结论开始。每一行
    要么是一个结论、要么是一个带 file:line 的发现、要么是你跑过的
    一个检查——没有开场白、没有流程叙述、没有结尾小结。

    ## 校准

    按实际严重度给问题分类。不是所有东西都是 关键。
    重要 意味着这个任务在修好之前不可信：不正确或脆弱的行为、
    一个漏掉的需求、或你会为之拦下合并的可维护性损害——逻辑块的
    逐字重复、被吞掉的错误、什么都不断言的测试。"覆盖面可以更广"
    和打磨类建议是 次要。
    如果计划或简报明确强制了某个本评分标准称之为缺陷的东西（一个
    什么都不断言的测试、逻辑块的逐字重复），那**就是**一个发现——
    把它报告为 重要，并标注为"计划强制"。计划的作者身份不能给它
    自己的工作打分；由人类来决定。
    在列出问题之前，先承认做得好的地方——准确的赞扬能帮实现者
    信任其余的反馈。

    ## 输出格式

    ### 规格合规性

    - ✅ 符合规格 | ❌ 发现问题：[缺失/多余/理解偏差的内容，
      附带 file:line 引用]
    - ⚠️ 无法从 diff 中核实：[你无法仅凭 diff 核实的需求，以及
      控制者应当检查什么——与你能核实的一切的 ✅/❌ 结论一起报告]

    ### 优点
    [哪些做得好？要具体。]

    ### 问题

    #### 关键（必须修复）
    #### 重要（应当修复）
    #### 次要（锦上添花）

    每个问题：file:line、哪里错了、为什么重要、如何修复（如果不明显）。

    ### 评估

    **任务质量：** [通过 | 需要修复]

    **理由：** [1-2 句技术性评估]
```

**占位符：**
- `[模型]` —— 必填：按 SKILL.md 的"模型选择"选审查者模型
- `[BRIEF_FILE]` —— 必填：任务简报文件（`scripts/task-brief PLAN N`
  会打印路径；与实现者所用的是同一个文件）
- `[GLOBAL_CONSTRAINTS]` —— 从计划的"全局约束"一节或规格里逐字抄下的、
  有约束力的需求：精确的取值、格式、以及组件之间被明确规定的关系
  （不是流程规则——那些已经在本模板里了）
- `[REPORT_FILE]` —— 必填：实现者写入其详细报告的那个文件
- `[BASE_SHA]` —— 本任务之前的提交
- `[HEAD_SHA]` —— 当前提交
- `[DIFF_FILE]` —— 必填：控制者写入审查包的那个路径
  （`scripts/review-package PLAN_FILE BASE HEAD` 会打印它写入的唯一路径；
  审查包永远不会进入控制者的上下文）

**审查者返回：** 规格合规性结论（✅/❌/⚠️）、优点、问题
（关键/重要/次要）、任务质量结论