double-check

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

double-check

Purpose

用途

Standalone second-pass PR review, stage-partitioned into an ICM procedure. Fetch the PR + the first review + the diff and check it out (setup), then run ONE cohesive critical-judgement review in a clean context (verify the first review's claims, find missed edge cases, and check tests/docs together → a single consolidated verdict), then apply fixes and re-run tests if needed (fix), then post the curated comment, apply the

double-checked

label, and write the report (post). Behaviorally equivalent to the original

double-check

skill, just isolated so the judgement step is not polluted by the orchestrator's history.

独立的PR二次审核，拆分为ICM流程的多个阶段。拉取PR、首次审核内容和代码差异并完成检出（setup阶段），随后在干净环境中执行一次连贯的批判性审核（验证首次审核的结论、找出遗漏的边缘案例、同步检查测试与文档→形成统一结论），之后按需修复问题并重新运行测试（fix阶段），最后发布整理后的评论、添加

double-checked

标签并撰写报告（post阶段）。其行为与原始的

double-check

skill一致，只是做了隔离处理，确保审核判断步骤不会被编排器的历史信息干扰。

Arguments

参数

Param	Required	Default	Notes
`pr`	yes	—	PR number, e.g. `742`
`repo`	yes	—	`org/repo` , e.g. `fellowship-dev/booster-pack`

Parse from

$ARGUMENTS

: first token is

pr

, second is

repo

. GitHub auth is ambient — no token env var. The pod's

git-credential-pylot

helper and the

gh

shim mint short-lived App installation tokens per operation, so git URLs must stay plain (

https://github.com/<org>/<repo>.git

); inline credentials bypass the helper and expire mid-run.

参数	是否必填	默认值	说明
`pr`	是	—	PR编号，例如 `742`
`repo`	是	—	`org/repo` 格式，例如 `fellowship-dev/booster-pack`

从

$ARGUMENTS

解析：第一个参数为

pr

，第二个为

repo

。 GitHub认证为环境级认证——无需设置令牌环境变量。Pod的

git-credential-pylot

助手和

gh

垫片会为每个操作生成短期的应用安装令牌，因此git URL必须保持纯格式（

https://github.com/<org>/<repo>.git

）；内嵌凭证会绕过助手并在运行中途过期。

What it does

功能说明

4-stage SEQUENTIAL ICM procedure (no parallel stages):

Stage	Mode	Description
01-setup	subagent	Fetch PR metadata, CI status, existing review comments, full diff; checkout PR branch + merge base
02-review	subagent	ONE cohesive critical review in clean context: reconcile the PR's claims against the diff, verify first review's claims, find missed edge cases, check tests/docs → consolidated verdict + curated findings
03-fix	subagent	Apply MUST-FIX (and worthwhile NICE-TO-HAVE) fixes, re-run tests, push — only if fixes are needed
04-post	inline	Re-check the claims gate against the live PR, detect re-check context (needs-work in labels), post curated review comment, apply labels to close the pipeline loop (re-check) or signal completion (first-check), verify the side effects landed, write local report file, emit outcome marker

分为4个顺序执行的ICM阶段（无并行阶段）：

阶段	模式	描述
01-setup	子代理	获取PR元数据、CI状态、现有审核评论、完整代码差异；检出PR分支与合并基准
02-review	子代理	在干净环境中执行一次连贯的批判性审核：对比代码差异验证PR的声明、确认首次审核的结论、找出遗漏的边缘案例、检查测试与文档→形成统一结论及整理后的发现
03-fix	子代理	应用必须修复（及值得修复的优化项）的问题，重新运行测试并推送——仅在需要修复时执行
04-post	内联	针对实时PR重新检查声明与差异的匹配情况，检测重检上下文（标签中的needs-work），发布整理后的审核评论，添加标签以关闭流程循环（重检）或标记完成（首次检查），验证操作结果已生效，撰写本地报告文件，输出结果标记

Handoff locations

交接文件位置

All handoffs live in the repo working directory:

.procedure-output/double-check/{stage}/handoff.md

The setup stage records the local checkout dir (

REPO_DIR

) in its handoff so the fix stage operates on the same working tree. Each subagent stage receives only the handoffs it needs — never the full orchestrator context.

所有交接文件均存储在仓库工作目录中：

.procedure-output/double-check/{stage}/handoff.md

setup阶段会在其交接文件中记录本地检出目录（

REPO_DIR

），以便fix阶段在同一工作树中操作。每个子代理阶段仅接收所需的交接文件——绝不会获取完整的编排器上下文。

Execution

执行流程

Stages 01 → 03 (sequential subagents)

01 → 03阶段（顺序执行的子代理）

Run one Task per stage, one after another. Do NOT launch any stages in parallel. Do not start the next stage until the current one completes.

Each Task prompt must be self-contained:

Include only the stage's input handoff paths
Include the path to the stage's CONTEXT.md
Pass
```
pr
```
and
```
repo
```
values
Do NOT pass orchestrator history or prior reasoning

Task prompt template:

You are running stage {NN}-{name} of the double-check procedure.

PR: {pr}    REPO: {repo}

Read your stage instructions:
  skills/double-check/stages/{NN}-{name}/CONTEXT.md

Your inputs:
  {list only the input handoff paths from that stage's CONTEXT.md}

Write your output to:
  .procedure-output/double-check/{NN}-{name}/handoff.md

Execute all steps in CONTEXT.md. Write handoff.md before exiting.

Stage gating:

Stage 02 is the isolated critical-judgement step. Its prompt MUST carry only the setup handoff (PR + first review + diff) — nothing else. This is the clean-context window the whole proc exists for.
After stage 02, read its handoff. If
```
fixes_needed: false
```
, SKIP stage 03 (no fixes to apply) and go straight to stage 04. Otherwise run stage 03.

每个阶段对应一个任务，依次执行。禁止并行启动任何阶段，必须等待当前阶段完成后再启动下一个阶段。

每个任务提示必须独立完整：

仅包含该阶段的输入交接文件路径
包含该阶段的CONTEXT.md路径
传入
```
pr
```
和
```
repo
```
的值
禁止传入编排器历史或之前的推理内容

任务提示模板：

You are running stage {NN}-{name} of the double-check procedure.

PR: {pr}    REPO: {repo}

Read your stage instructions:
  skills/double-check/stages/{NN}-{name}/CONTEXT.md

Your inputs:
  {list only the input handoff paths from that stage's CONTEXT.md}

Write your output to:
  .procedure-output/double-check/{NN}-{name}/handoff.md

Execute all steps in CONTEXT.md. Write handoff.md before exiting.

阶段门控：

02阶段是隔离的批判性判断步骤。其提示必须仅包含setup阶段的交接文件（PR + 首次审核 + 差异）——无其他内容。这是整个流程存在的核心干净环境窗口。
完成02阶段后，读取其交接文件。如果
```
fixes_needed: false
```
，则跳过03阶段（无需修复）直接进入04阶段。否则执行03阶段。

Stage 04 (inline)

04阶段（内联执行）

Run stage 04 yourself in the orchestrator context — do NOT spawn a Task. Read CONTEXT.md:

skills/double-check/stages/04-post/CONTEXT.md

Run the live claims-vs-diff gate (

gh pr view

), post the comment, apply the label, verify the labels/comment actually landed, write the report file, and emit the

[pylot] outcome=...

marker from the orchestrator (never from a subagent).

在编排器上下文中自行执行04阶段——无需生成任务。读取CONTEXT.md：

skills/double-check/stages/04-post/CONTEXT.md

运行实时声明与差异匹配检查（

gh pr view

），发布评论，添加标签，验证标签/评论已实际生效，撰写报告文件，并从编排器输出

[pylot] outcome=...

标记（绝不能从子代理输出）。

Stage handoff chain

阶段交接链

01-setup ─► 02-review ─► 03-fix ─► 04-post (inline, reads 01+02+03)
                  │                    ▲
                  └── fixes_needed:false ┘  (skip 03)

01-setup ─► 02-review ─► 03-fix ─► 04-post (inline, reads 01+02+03)
                  │                    ▲
                  └── fixes_needed:false ┘  (skip 03)

Exit paths

退出路径

Claims mismatch (first-check, PR body claims code the diff does not contain): stage 04 posts a

<!-- pylot:claims-mismatch -->

comment, withholds

double-checked

(which halts cto-review / staging / FlowChad), does not touch

needs-work

, and emits:

[pylot] outcome="double-check BLOCKED {repo}#{pr} — {N} PR-body claims unbacked by the diff, double-checked withheld" status=success

Re-check PASS (PR had

needs-work

, verdict=ready): stage 04 removes

needs-work

, re-toggles

double-checked

(remove + re-add), and emits:

[pylot] outcome="double-checked re-check PASS {repo}#{pr} — loop closed, cto-review re-fired" status=success

Re-check FAIL (PR had
```
needs-work
```
, verdict=needs-work): stage 04 leaves
```
needs-work
```
in place, does NOT re-toggle
```
double-checked
```
, posts a structured verdict comment with a
```

```
marker (idempotent — skipped if marker already present), and emits:
```
[pylot] outcome="double-checked re-check FAIL {repo}#{pr} — needs-work retained" status=success
```

First-check success: stage 04 applies

double-checked

label and emits:

[pylot] outcome="double-checked {repo}#{pr} — verdict {ready|needs-work}, {N} findings curated, {N} fixes pushed" status=success

Failure: failing stage emits

[pylot] outcome="double-check failed at stage NN: {reason}" status=failed

Blocked: setup cannot fetch/checkout the PR (e.g. merge conflict, missing PR) →
```
[pylot] outcome="double-check blocked: {reason}" status=blocked
```

声明不匹配（首次检查，PR正文声明的代码未在差异中体现）：04阶段发布带有
```

```
标记的评论，不添加
```
double-checked
```
标签（这会阻止cto-review/ staging/ FlowChad流程），不修改
```
needs-work
```
标签，并输出：
```
[pylot] outcome="double-check BLOCKED {repo}#{pr} — {N} PR-body claims unbacked by the diff, double-checked withheld" status=success
```

重检通过（PR带有

needs-work

标签，结论为ready）：04阶段移除

needs-work

标签，重新切换

double-checked

标签（先移除再添加），并输出：

[pylot] outcome="double-checked re-check PASS {repo}#{pr} — loop closed, cto-review re-fired" status=success

重检失败（PR带有
```
needs-work
```
标签，结论为needs-work）：04阶段保留
```
needs-work
```
标签，不重新切换
```
double-checked
```
标签，发布带有
```

```
标记的结构化结论评论（幂等操作——如果标记已存在则跳过），并输出：
```
[pylot] outcome="double-checked re-check FAIL {repo}#{pr} — needs-work retained" status=success
```

首次检查成功：04阶段添加

double-checked

标签，并输出：

[pylot] outcome="double-checked {repo}#{pr} — verdict {ready|needs-work}, {N} findings curated, {N} fixes pushed" status=success

执行失败：失败阶段输出

[pylot] outcome="double-check failed at stage NN: {reason}" status=failed

执行阻塞：setup阶段无法拉取/检出PR（例如合并冲突、PR不存在）→
```
[pylot] outcome="double-check blocked: {reason}" status=blocked
```

Hard Rules

硬性规则

SEQUENTIAL ONLY — one Task per stage, run one after another. NO parallel Task launches, ever.
The review is ONE cohesive stage — do NOT split stage 02 into per-file or per-dimension subagents. Correctness, edge cases, tests, docs, deps, and security are judged together in a single verdict.
Stage 02 gets a clean context — only the setup handoff (PR + first review + diff). Never pass orchestrator history into it.
Stage 04 runs inline — the
```
[pylot] outcome=...
```
marker MUST come from the orchestrator.
Never pass full orchestrator context into subagent Task prompts — inputs only.
Each stage writes handoff.md before the next stage reads it.
Do not skip stages except stage 03 when
```
fixes_needed: false
```
(an explicit, allowed skip).
NO Quest. Reporting is the local report file only — no Quest POST, no
```
127.0.0.1:4242
```
, no
```
quest.fellowship.dev
```
, no
```
QUEST_TOKEN
```
.
Apply labels only after the comment posts successfully (stage 04). On re-check PASS, remove
```
needs-work
```
BEFORE re-adding
```
double-checked
```
— this is the structural loop-break. On re-check FAIL, do NOT touch labels or re-toggle
```
double-checked
```
.
The diff is the only evidence; the PR body is a claim. Stage 02 reconciles every concrete claim in the title/body against the changed files, and stage 04 re-checks it against the live PR. A claim with no code behind it and no pointer to where it landed is
```
needs-work
```
— "intentional", "the commit message explains it", and a LOW risk tier are NOT waivers.
```
double-checked
```
is withheld until the body matches the diff. (pylot#2649, PR pylot#2782.)
Stage 04 verifies its own side effects — after labelling,
```
gh pr view
```
the PR and confirm the expected labels/comment are actually there. Reporting success on unverified side effects is the failure this skill exists to catch in others.
Extend the review-state ledger, never fork it (#2210) — setup extracts the LAST
```
review-state v1
```
block; stage 02 curates by ledger ID at tier-scaled depth (escalate-only); stage 04 re-posts the updated block as valid JSON. No block found → pre-#2210 fallback (verbatim first-review curation, full depth).

仅顺序执行——每个阶段对应一个任务，依次运行。禁止并行启动任何任务。
审核为单一连贯阶段——禁止将02阶段拆分为按文件或维度划分的子代理。正确性、边缘案例、测试、文档、依赖项和安全性需在一次审核中统一判断并形成结论。
02阶段使用干净上下文——仅传入setup阶段的交接文件（PR + 首次审核 + 差异）。绝不能传入编排器历史信息。
04阶段内联执行——
```
[pylot] outcome=...
```
标记必须来自编排器。
禁止传入完整编排器上下文到子代理任务提示中——仅传入输入内容。
每个阶段必须先写入handoff.md，再由下一个阶段读取。
禁止跳过阶段，除非
```
fixes_needed: false
```
时跳过03阶段（这是明确允许的跳过操作）。
不使用Quest——仅通过本地报告文件进行报告——不进行Quest POST、不使用
```
127.0.0.1:4242
```
、不访问
```
quest.fellowship.dev
```
、不使用
```
QUEST_TOKEN
```
。
仅在评论发布成功后添加标签（04阶段）。重检通过时，需先移除
```
needs-work
```
标签，再重新添加
```
double-checked
```
标签——这是打破流程循环的关键操作。重检失败时，不修改标签或重新切换
```
double-checked
```
标签。
差异是唯一证据；PR正文是声明。02阶段需对比标题/正文中的每一项具体声明与变更文件，04阶段需针对实时PR重新检查。无代码支撑且未指明实现位置的声明属于
```
needs-work
```
——“有意为之”、“提交信息已说明”和“低风险等级”均不能作为豁免理由。在正文与差异匹配前，不得添加
```
double-checked
```
标签。（参考pylot#2649，PR pylot#2782。）
04阶段需验证自身操作结果——添加标签后，通过
```
gh pr view
```
查看PR并确认预期的标签/评论已实际生效。未验证操作结果就报告成功，正是本skill要发现的其他流程的错误。
扩展审核状态 ledger，绝不分支（#2210）——setup阶段提取最新的
```
review-state v1
```
块；02阶段按ledger ID分层整理（仅升级问题等级）；04阶段重新发布更新后的有效JSON块。未找到块时→回退到#2210之前的逻辑（完整保留首次审核内容，全深度整理）。

Reference files

参考文件

```
CONTEXT.md
```
— architecture overview
```
stages/NN-name/CONTEXT.md
```
— per-stage inputs, task, output contract
```
shared/review-comment-template.md
```
— curated PR comment template (stage 04)
```
shared/report-template.md
```
— local report file template (stage 04)

```
CONTEXT.md
```
— 架构概述
```
stages/NN-name/CONTEXT.md
```
— 各阶段的输入、任务、输出约定
```
shared/review-comment-template.md
```
— 整理后的PR评论模板（04阶段）
```
shared/report-template.md
```
— 本地报告文件模板（04阶段）