review-pr

review-pr

只读的首轮 PR 审查，分为 3 个连续阶段。收集 PR 上下文和完整 diff（内联）→ 由一个隔离上下文的子代理整体审查完整 diff（关键判断步骤）→ 发布审查评论，应用确定性的 security 和 lane:* 标签，最后应用 reviewed 标签，并写入本地报告（内联）。绝不检出代码、修复问题或推送提交——这些是 double-check 的工作。

目的

单体式 review-pr 在同一会话中完成去重门禁、上下文收集、读取 diff、分析、置信度评分、规范检查、发布评论、添加标签和写入报告。关键判断步骤（分析 diff 并为其评分）共享的上下文窗口已经被原始 gh JSON、完整 diff、CI 输出和现有评论污染。此流程将该判断隔离到一个干净上下文的子代理中，它只会看到经过整理的 PR 上下文和 diff。

这里的 ICM 优势在于隔离审查结论的干净上下文，而非并行处理。 PR 会以整体方式审查：在一个审查阶段中，结合完整 diff 和所有维度（正确性、规范、Closes 与 Refs）进行审查。不会按文件拆分任务，也不会并行运行子代理。

参数

参数	必填	默认值	说明
pr	是	—	PR 编号（第一个位置参数，$1）
repo	是	—	org/repo（第二个位置参数，$2）

从 $ARGUMENTS 解析：PR=$1，REPO=$2。两者都必填。

令牌： 无需令牌。GitHub 身份验证由环境提供——Pod 的 git-credential-pylot 助手和 gh shim 会按操作生成短期 App 安装令牌。

执行内容

3 阶段顺序 ICM 流程：

阶段	模式	说明
00-context	内联	感知 HEAD 的去重门禁（仅当 reviewed 针对当前 HEAD 有效回执时才退出）+ 收集 PR 元数据、规范、现有评论、CI 状态、完整 diff、机械风险等级（#2210）以及新认证面检测（#2918）
01-cohesive-review	子代理	关键判断步骤。 一个子代理以整体方式按风险等级调整审查深度（LOW 限定 / MEDIUM 完整 / HIGH 完整 + 运行时形态检查清单）审查完整 diff：分析、为发现的问题评分（≥80）、对每项发现进行安全分类（#2918）、检查规范合规性以及 Closes 与 Refs。使用干净的隔离上下文。
02-post	内联	发布结构化审查评论，附带完整的 40 位十六进制 Head reviewed 回执行 + 若发现认证面或安全类问题则应用 security 标签（#2918）+ 应用确定性的 lane:fast/lane:staging 标签（#2996）+ 最后应用 reviewed 标签 + 写入本地报告 + 输出结果标记

恰好只有一个子代理阶段（01）。它不会按文件或维度拆分。

交接位置

所有交接文件都位于仓库工作目录中：

.procedure-output/review-pr/{stage}/handoff.md

阶段 00 写入整理后的 PR 上下文和完整 diff。阶段 01 仅接收该交接文件（不会收到编排器历史记录）。阶段 02 读取两个交接文件。

执行

阶段 00（内联）

在编排器上下文中自行运行阶段 00。读取 CONTEXT.md：

skills/review-pr/stages/00-context/CONTEXT.md

首先运行去重门禁。仅当 PR 带有 reviewed 标签，且最新审查评论中的 **Head reviewed:** 行写明当前 headRefOid 时，才提前结束。缺失、无效或过期的回执不代表已完成：记录 review_run: stale-refresh，继续正常审查，并让阶段 02 在发布当前 HEAD 的回执后重新设置 reviewed 标签。

阶段 01（单个子代理——不拆分任务）

恰好启动一个 Task。只传递该阶段的输入交接路径和阶段 CONTEXT.md 路径。不要传递编排器历史记录，也不要传递你已看到的原始 gh 输出。不要将 diff 拆分到多个 Task——审查必须整体查看完整 diff。

Task 提示词模板：

You are running stage 01-cohesive-review of the review-pr procedure.

Read your stage instructions:
  skills/review-pr/stages/01-cohesive-review/CONTEXT.md

Your inputs:
  .procedure-output/review-pr/00-context/handoff.md

Write your output to:
  .procedure-output/review-pr/01-cohesive-review/handoff.md

Execute all steps in CONTEXT.md. Review the ENTIRE diff together in cohesion — do not fragment it
per-file. Write handoff.md before exiting.

等待任务完成后再进入阶段 02。如果任务失败，输出失败结果标记并停止。

阶段 02（内联）

自行运行阶段 02（编排器上下文）。阅读 CONTEXT.md：

skills/review-pr/stages/02-post/CONTEXT.md

发表评论；如有必要，应用 security 标签（步骤 2）；应用 lane:* 标签 （步骤 2.5）；最后应用 reviewed 标签（步骤 3）；写入本地报告文件，并由编排器输出 [pylot] outcome=... 标记（绝不能由子 Agent 输出）。

阶段交接链

00-context (inline: dedup gate + context + full diff + auth surface detection)
   │
   └─► 01-cohesive-review (single subagent, clean context, whole diff + security classification)
          │
          └─► 02-post (inline: comment → security label → lane label → reviewed label → report → outcome marker)
                         │
                         ├── lane:fast    ──► cto-review-on-reviewed-fast  (review + cto merge)
                         ├── lane:staging ──► review-pr-on-reviewed        (full pipeline)
                         └── no lane      ──► review-pr-on-reviewed        (pre-#2996 default)

退出路径

• 已完成：阶段 00 的去重关卡找到当前 HEAD 的回执 → [pylot:$PYLOT_OUTCOME_NONCE] outcome="already complete — reviewed receipt matches current HEAD {sha}" status=success（编排器，内联）
• 成功：阶段 02 输出 [pylot:$PYLOT_OUTCOME_NONCE] outcome="review-pr complete — reviewed label applied, lane:{fast|staging|n/a}" status=success
• 失败：失败的阶段输出 [pylot:$PYLOT_OUTCOME_NONCE] outcome="review-pr failed at stage NN: {reason}" status=failed

硬性规则

1. 仅按顺序执行 — 各阶段依次运行。不得并行启动 Task。
2. 只能有一个子 Agent 阶段（01） — 对整个 diff 进行整体审查。不得按文件拆分，也不得按维度拆分。审查必须同时查看整个 diff，以确保跨文件的一致性。
3. 阶段 00 在编排器中内联运行 — 去重门控和上下文收集由编排器执行。
4. 阶段 02 在编排器中内联运行 — [pylot] outcome=... 标记必须由编排器生成。
5. 不得将完整的编排器上下文传递给子 Agent — 仅传递输入交接路径。
6. 每个阶段都必须在下一阶段读取前写入 handoff.md。
7. 只读 — 不得执行 git clone、git checkout，不得修改正在审查的仓库中的文件，也不得推送。diff 来自 gh pr diff。
8. 置信度阈值为 80 — 不得呈现低于 80 的发现。不得降低阈值。
9. 不使用 QUEST — 仅通过本地报告文件报告。不得执行 Quest POST，不得使用 QUEST_TOKEN 或 127.0.0.1:4242。由操作人员通过任务报告呈现报告。
10. 不得应用 double-checked — 仅应用 reviewed。结论始终为“进入二次检查”；此技能不会阻止流程。
11. 不得跳过阶段 — 每个阶段都必须执行（除非考虑当前 HEAD 的去重门控证明最新回执与当前 HEAD 一致，此时可跳过阶段 01/02）。单凭 reviewed 标签绝不能作为已完成的证明。
12. 风险等级按规则机械判定，且只能升级（#2210） — 阶段 00 根据规则计算风险等级；阶段 01 可以提高风险等级（并记录原因），但不得降低。LOW 等级的审查范围有明确限制——不得超出等级“力求全面”；节省下来的审查深度将分配给 HIGH 等级的 PR。
13. 必须始终发布包含完整 40 位十六进制 head 的 **Head reviewed:** 回执行 — 该行用于将审查绑定到确切的 head，以供去重门控和后续阶段使用。下游发现保留其 R{n} ID；不得重新编号。
14. 安全标签采用确定性规则（#2918） — 如果存在任何安全类发现，或 auth_surface: new-auth-surface，阶段 02 就应用 security。不得自行判断：满足条件就必须应用该标签。该标签是分类元数据，绝不会阻止合并——它与审查在同一任务中设置；是否确实需要负责人决策，由 cto-review 自己的负责人权限分类器（#3240）独立决定。
15. 泳道标签由脚本决定，不由你决定（#2996） — 阶段 02 运行 scripts/classify-pr-surface.mts --lane，并应用脚本输出的标签。不得自行判断泳道，不得覆盖分类结果，也不得因为 diff“看起来很小”就说服自己使用 fast。分类器是唯一可信来源；若与分类器结果不一致，应针对 LANE_STAGING_GLOBS 提交 PR，而不是在本任务中自行决定。除精确字符串 fast 之外的任何情况——脚本崩溃、输出为空、缺少分类器，或仓库未启用泳道——都将解析为 lane:staging / 不添加标签，即回到 #2996 之前的流水线。fast 始终为主动选择。
16. 标签顺序：security → lane:* → reviewed，且 reviewed 必须最后应用（#2996） — 对 reviewed 作出响应的自动化会读取 webhook 负载中携带的标签集合，因此在 reviewed 之后应用的泳道标签对它们不可见，PR 便会悄然进入完整流水线。这个顺序是必要机制，不是风格偏好。
17. 审查完成状态绑定到 head — 每条已发布的审查都必须命名并记录自动获取的当前 HEAD SHA。刷新过期回执时，只有在新评论和前置标签都已就位后，才移除并重新添加 reviewed，以便下游阶段收到当前触发信号，同时不必重启审查或阻塞审查。

参考文件

• CONTEXT.md — 架构概览
• stages/NN-name/CONTEXT.md — 各阶段的输入、任务、步骤和输出约定