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.

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.

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

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.

Execution

Stages 01 → 03 (sequential subagents)

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.

Stage 04 (inline)

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).

Stage handoff chain

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
```

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).

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)

double-check

NPX Install

Tags

SKILL.md Content

double-check

Purpose

Arguments

What it does

Handoff locations

Execution

Stages 01 → 03 (sequential subagents)

Stage 04 (inline)

Stage handoff chain

Exit paths

Hard Rules

Reference files