review-pr

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

review-pr

review-pr

Read-only first-pass PR review, partitioned into 3 sequential stages. Gather PR context and the full diff (inline) → review the whole diff in cohesion as a single isolated-context subagent (the critical-judgement step) → post the review comment, apply the
reviewed
label, write the local report (inline). Never checks out code, never fixes issues, never pushes commits — that's double-check's job.
首次只读PR评审,分为3个连续阶段。收集PR上下文和完整差异(内联)→ 作为单个隔离环境子代理(关键判断步骤)连贯地评审整个差异→ 发布评审评论、应用
reviewed
标签、编写本地报告(内联)。绝不检出代码、绝不修复问题、绝不推送提交——这些是double-check的工作。

Purpose

目的

The monolithic
review-pr
ran the dedup gate, context gathering, diff read, analysis, confidence-scoring, convention check, comment post, label, and report write in one session. The critical-judgement step (analyze + confidence-score the diff) shared a context window already polluted by raw gh JSON, the full diff, CI output, and existing comments. This proc isolates that judgement into one clean-context subagent that sees only the curated PR context and diff.
The ICM win here is clean-context isolation of the review verdict — not parallelism. A PR is reviewed in COHESION: the entire diff, all dimensions (correctness, conventions, Closes-vs-Refs) together in ONE review stage. There is NO per-file fan-out and NO parallel subagents.
原有的单体
review-pr
在一个会话中执行去重校验、上下文收集、差异读取、分析、置信度评分、规范检查、评论发布、标签添加和报告编写。关键判断步骤(分析差异并进行置信度评分)的上下文窗口已被原始gh JSON、完整差异、CI输出和现有评论污染。此流程将该判断步骤隔离到一个仅能看到经过整理的PR上下文和差异的干净环境子代理中。
**此处的ICM优势在于评审结论的干净环境隔离——而非并行处理。**PR评审是连贯进行的:整个差异、所有维度(正确性、规范、Closes与Refs的区分)在同一个评审阶段中完成。不存在按文件拆分或并行子代理的情况。

Arguments

参数

ParamRequiredDefaultNotes
pr
yesPR number (first positional arg,
$1
)
repo
yes
org/repo
(second positional arg,
$2
)
Parse from
$ARGUMENTS
:
PR=$1
,
REPO=$2
. Both required.
Token: none needed. GitHub auth is ambient — the pod's
git-credential-pylot
helper and the
gh
shim mint short-lived App installation tokens per operation.
参数必填默认值说明
pr
PR编号(第一个位置参数,
$1
repo
org/repo
(第二个位置参数,
$2
$ARGUMENTS
解析:
PR=$1
REPO=$2
。两者均为必填项。
**令牌:**无需额外令牌。GitHub认证是环境级别的——pod的
git-credential-pylot
助手和
gh
垫片会为每个操作生成短期应用安装令牌。

What it does

功能说明

3-stage SEQUENTIAL ICM procedure:
StageModeDescription
00-contextinlineDedup gate (exit if already
reviewed
) + gather PR metadata, conventions, existing comments, CI status, the full diff, and the mechanical risk tier (#2210)
01-cohesive-reviewsubagentCritical-judgement step. ONE subagent reviews the whole diff in cohesion at tier-scaled depth (LOW bounded / MEDIUM full / HIGH full + runtime-shape checklist): analyze, confidence-score findings (≥80), convention compliance, Closes-vs-Refs. Clean isolated context.
02-postinlinePost structured review comment with the embedded
review-state v1
block
(findings ledger + verification manifest consumed by double-check/cto-review, #2210) + apply
reviewed
label + write local report + emit outcome marker
There is exactly one subagent stage (01). It is NOT split per-file or per-dimension.
3阶段顺序ICM流程:
阶段模式描述
00-context内联去重校验(若已添加
reviewed
标签则退出)+ 收集PR元数据、规范、现有评论、CI状态、完整差异以及机械风险等级(#2210)
01-cohesive-review子代理**关键判断步骤。**单个子代理根据等级调整的深度(LOW级受限 / MEDIUM级完整 / HIGH级完整+运行时形态检查清单)连贯地评审整个差异:分析、对发现的问题进行置信度评分(≥80)、检查规范合规性、区分Closes与Refs。环境干净隔离。
02-post内联发布结构化评审评论并嵌入
review-state v1
(供double-check/cto-review使用的发现记录清单+验证清单,#2210)+ 应用
reviewed
标签 + 编写本地报告 + 输出结果标记
仅有一个子代理阶段(01)。不会按文件或维度拆分。

Handoff locations

交接位置

All handoffs live in the repo working directory:
.procedure-output/review-pr/{stage}/handoff.md
Stage 00 writes the curated PR context + full diff. Stage 01 receives ONLY that handoff (never the orchestrator history). Stage 02 reads both handoffs.
所有交接文件均存储在仓库工作目录中:
.procedure-output/review-pr/{stage}/handoff.md
阶段00写入整理后的PR上下文+完整差异。阶段01仅接收该交接文件(绝不会接收编排器历史)。阶段02读取两个交接文件。

Execution

执行步骤

Stage 00 (inline)

阶段00(内联)

Run stage 00 yourself (orchestrator context). Read CONTEXT.md:
skills/review-pr/stages/00-context/CONTEXT.md
Run the dedup gate first. If the PR already has the
reviewed
label, emit the already-complete outcome marker and STOP — do not spawn stage 01. Otherwise gather all context + the full diff and write the handoff to
.procedure-output/review-pr/00-context/handoff.md
.
自行运行阶段00(编排器上下文)。阅读CONTEXT.md:
skills/review-pr/stages/00-context/CONTEXT.md
首先执行去重校验。若PR已添加
reviewed
标签,输出已完成的结果标记并停止——不要启动阶段01。否则收集所有上下文+完整差异,并将交接文件写入
.procedure-output/review-pr/00-context/handoff.md

Stage 01 (single subagent — NO fan-out)

阶段01(单个子代理——无拆分)

Spawn exactly ONE Task. Pass only the stage's input handoff path and the stage CONTEXT.md path. Do NOT pass orchestrator history or the raw gh output you already saw. Do NOT split the diff across multiple Tasks — the review must see the whole diff in cohesion.
Task prompt template:
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.
Await the task before proceeding to stage 02. If it fails, emit the failure outcome marker and stop.
启动恰好一个任务。仅传递阶段的输入交接文件路径和阶段CONTEXT.md路径。不要传递编排器历史或你已见过的原始gh输出。不要将差异拆分到多个任务中——评审必须连贯地查看整个差异。
任务提示模板:
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。若任务失败,输出失败结果标记并停止。

Stage 02 (inline)

阶段02(内联)

Run stage 02 yourself (orchestrator context). Read CONTEXT.md:
skills/review-pr/stages/02-post/CONTEXT.md
Post the comment, apply the
reviewed
label, write the local report file, and emit the
[pylot] outcome=...
marker from the orchestrator (never from a subagent).
自行运行阶段02(编排器上下文)。阅读CONTEXT.md:
skills/review-pr/stages/02-post/CONTEXT.md
发布评论、应用
reviewed
标签、编写本地报告文件,并从编排器输出
[pylot] outcome=...
标记(绝不要从子代理输出)。

Stage handoff chain

阶段交接链

00-context (inline: dedup gate + context + full diff)
   └─► 01-cohesive-review (single subagent, clean context, whole diff)
          └─► 02-post (inline: comment + reviewed label + report + outcome marker)
00-context (内联:去重校验 + 上下文 + 完整差异)
   └─► 01-cohesive-review (单个子代理,干净环境,完整差异)
          └─► 02-post (内联:评论 + reviewed标签 + 报告 + 结果标记)

Exit paths

退出路径

  • Already complete: stage 00 dedup gate hits →
    [pylot] outcome="already complete — reviewed label already applied" status=success
    (orchestrator, inline)
  • Success: stage 02 emits
    [pylot] outcome="review-pr complete — reviewed label applied" status=success
  • Failure: failing stage emits
    [pylot] outcome="review-pr failed at stage NN: {reason}" status=failed
  • 已完成:阶段00触发去重校验 →
    [pylot] outcome="already complete — reviewed label already applied" status=success
    (编排器,内联)
  • 成功:阶段02输出
    [pylot] outcome="review-pr complete — reviewed label applied" status=success
  • 失败:失败阶段输出
    [pylot] outcome="review-pr failed at stage NN: {reason}" status=failed

Hard Rules

硬性规则

  1. SEQUENTIAL ONLY — stages run one after another. NO parallel Task launches.
  2. Exactly one subagent stage (01) — the whole-diff cohesive review. NO per-file fan-out, NO per-dimension split. The review must see the entire diff together for cross-file cohesion.
  3. Stage 00 runs inline — dedup gate + context gathering happen in the orchestrator.
  4. Stage 02 runs inline — the
    [pylot] outcome=...
    marker MUST come from the orchestrator.
  5. Never pass full orchestrator context into the subagent — input handoff path only.
  6. Each stage writes handoff.md before the next stage reads it.
  7. Read-only — no
    git clone
    , no
    git checkout
    , no file modifications to the repo under review, no pushes. The diff comes from
    gh pr diff
    .
  8. Confidence threshold is 80 — never surface findings below 80. Don't lower it.
  9. NO QUEST — reporting is the local report file only. No Quest POST, no
    QUEST_TOKEN
    , no
    127.0.0.1:4242
    . Operators surface the report via the mission report.
  10. Never apply
    double-checked
    — only
    reviewed
    . The verdict is always "proceed to double-check"; this skill never blocks.
  11. Do not skip stages — every stage executes (except stage 01/02 when the dedup gate exits at 00).
  12. Risk tier is mechanical and escalate-only (#2210) — stage 00 computes it from the rubric; stage 01 may raise it (recording why) but never lower it. LOW-tier review is bounded by design — do not "be thorough" past the tier; the saved depth is reallocated to HIGH-tier PRs.
  13. The
    review-state v1
    block is always posted and must be valid JSON
    — it is the ledger double-check and cto-review extend. Findings keep their
    R{n}
    IDs downstream; never renumber.
  1. 仅允许顺序执行——阶段依次运行。禁止并行启动任务。
  2. 恰好一个子代理阶段(01)——完整差异的连贯评审。禁止按文件拆分、禁止按维度拆分。评审必须查看整个差异以保证跨文件连贯性。
  3. 阶段00以内联方式运行——去重校验和上下文收集在编排器中进行。
  4. 阶段02以内联方式运行——
    [pylot] outcome=...
    标记必须来自编排器。
  5. 绝不传递完整编排器上下文给子代理——仅传递输入交接文件路径。
  6. 每个阶段在写入handoff.md后,下一阶段才能读取它。
  7. 只读操作——不执行
    git clone
    、不执行
    git checkout
    、不修改待评审仓库的文件、不推送提交。差异来自
    gh pr diff
  8. 置信度阈值为80——绝不展示置信度低于80的发现结果。不要降低该阈值。
  9. 禁止使用QUEST——仅通过本地报告文件进行报告。不进行Quest POST、不使用
    QUEST_TOKEN
    、不连接
    127.0.0.1:4242
    。操作人员通过任务报告展示该报告。
  10. 绝不应用
    double-checked
    标签
    ——仅应用
    reviewed
    标签。结论始终为“进入double-check环节”;此技能绝不会阻塞流程。
  11. 禁止跳过阶段——每个阶段都要执行(除非阶段00触发去重校验后退出,此时不执行阶段01/02)。
  12. 风险等级为机械判定且仅可升级(#2210)——阶段00根据规则计算风险等级;阶段01可提升等级(记录原因)但绝不降低。LOW级评审在设计上是受限的——不要超出等级要求“彻底评审”;节省的评审深度将分配给HIGH级PR。
  13. review-state v1
    块必须始终发布且为有效JSON
    ——它是double-check和cto-review扩展的记录清单。发现结果在下游保留其
    R{n}
    ID;绝不重新编号。

Reference files

参考文件

  • CONTEXT.md
    — architecture overview
  • stages/NN-name/CONTEXT.md
    — per-stage inputs, task, steps, output contract
  • CONTEXT.md
    ——架构概述
  • stages/NN-name/CONTEXT.md
    ——每个阶段的输入、任务、步骤、输出约定