review-pr

review-pr

3 つの連続したステージに分けて実施する、読み取り専用の初回 PR レビューです。PR のコンテキストと差分全体を（インラインで）収集する → 隔離されたコンテキストを持つ単一のサブエージェントとして、差分全体を一貫性を保ってレビューする（重要な判断ステップ） → レビューコメントを投稿し、決定的な security ラベルと lane:* ラベルを適用し、最後に reviewed ラベルを適用して、ローカルレポートを書き込みます（インライン）。コードのチェックアウト、問題の修正、コミットのプッシュは行いません。これらは double-check の役割です。

目的

従来の一枚岩の review-pr は、重複排除ゲート、コンテキスト収集、差分の読み取り、分析、確信度スコアリング、規約チェック、コメント投稿、ラベル付け、レポート書き込みをすべて 1 つのセッションで実行していました。重要な判断ステップ（差分の分析と確信度スコアリング）では、生の gh JSON、差分全体、CI 出力、既存のコメントによってすでに汚染されたコンテキストウィンドウが使われていました。この手順では、その判断を、精選された PR コンテキストと差分だけを確認するクリーンなコンテキストのサブエージェントに切り分けます。

ここで ICM が効果を発揮するのは、レビュー判定をクリーンなコンテキストに隔離する点であり、並列化ではありません。 PR は一貫性を保ってレビューします。差分全体と、正確性、規約、Closes と Refs の使い分けを含むすべての観点を、1 つのレビュー段階でまとめて確認します。ファイルごとの分割処理も、サブエージェントの並列実行も行いません。

引数

Param	必須	デフォルト	備考
pr	はい	—	PR 番号（最初の位置引数、$1）
repo	はい	—	org/repo（2 番目の位置引数、$2）

$ARGUMENTS から解析します：PR=$1、REPO=$2。どちらも必須です。

トークン： 不要です。GitHub 認証は環境から利用できます。pod の git-credential-pylot ヘルパーと gh shim が、操作ごとに有効期間の短い App インストールトークンを発行します。

実行内容

3 段階の逐次 ICM 手順です。

Stage	Mode	Description
00-context	インライン	HEAD を考慮した重複排除ゲート（現在の HEAD に対する有効なレシートが reviewed にある場合にのみ終了）と、PR メタデータ、規約、既存のコメント、CI ステータス、差分全体、機械的なリスク階層（#2210）、新たな認証サーフェスの検出（#2918）の収集
01-cohesive-review	サブエージェント	重要な判断ステップ。 単一のサブエージェントが、階層に応じた深さ（LOW は範囲を限定／MEDIUM は全体／HIGH は全体＋ランタイム形状チェックリスト）で差分全体を一貫性を保ってレビューします。分析、指摘の確信度スコアリング（≥80）、各指摘のセキュリティ分類（#2918）、規約への準拠、Closes と Refs の使い分けを確認します。クリーンで隔離されたコンテキストを使用します。
02-post	インライン	40 桁の 16 進数からなる Head reviewed レシート行を含む構造化レビューコメントの投稿＋認証サーフェスまたはセキュリティ分類された指摘がある場合は security ラベルを適用（#2918）＋決定的な lane:fast／lane:staging ラベルを適用（#2996）＋最後に reviewed ラベルを適用＋ローカルレポートを書き込み＋結果マーカーを出力

サブエージェントのステージは 1 つ（01）のみです。ファイルごと、または観点ごとには分割しません。

引き継ぎ先

すべての引き継ぎファイルは、リポジトリの作業ディレクトリに置かれます。

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

ステージ 00 では、精選された PR コンテキストと差分全体を書き込みます。ステージ 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 をちょうど 1 つ起動します。ステージの入力引き継ぎファイルのパスと、ステージの CONTEXT.md のパスのみを渡します。オーケストレーターの履歴や、すでに確認した生の gh 出力は渡さないでください。差分を複数の Task に分割しないでください。レビューでは差分全体を一貫性を保って確認する必要があります。

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 に進む前に Task の完了を待ちます。失敗した場合は、失敗結果マーカーを出力して停止します。

ステージ 02（インライン）

自分でステージ 02 を実行します（オーケストレーターのコンテキスト）。CONTEXT.md を読みます。

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

コメントを投稿し、必要に応じて security ラベルを適用し（ステップ 2）、lane:* ラベルを適用し （ステップ 2.5）、最後に reviewed ラベルを適用して（ステップ 3）、ローカルのレポートファイルを書き込み、 オーケストレーターから [pylot] outcome=... マーカーを出力します（サブエージェントからは出力しません）。

ステージ引き継ぎチェーン

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. サブエージェントのステージは 1 つだけ（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 のみを適用します。判定は常に「ダブルチェックへ進む」です。このスキルがブロックすることはありません。
11. ステージを省略してはいけません — ヘッドを考慮する重複排除ゲートによって、最新のレシートが現在の HEAD と一致すると証明された場合を除き、すべてのステージを実行します。reviewed ラベルだけでは、完了の証明になりません。
12. リスクティアの決定は機械的に行い、引き上げのみ可能です（#2210） — ステージ 00 が評価基準に基づいて算出します。ステージ 01 は理由を記録したうえで引き上げられますが、引き下げることはできません。LOW ティアのレビューは意図的に範囲が限定されています。ティアを超えて「念入りに」レビューしてはいけません。そこで節約した深度は HIGH ティアの PR に振り向けます。
13. **Head reviewed:** のレシート行には、必ず完全な 40 桁の 16 進数のヘッドを記載します — これはレビューを重複排除ゲートおよび後続ステージの対象となる正確なヘッドに結び付けます。指摘には後続処理でも R{n} ID をそのまま使用し、番号を振り直してはいけません。
14. security ラベルは決定的に適用します（#2918） — いずれかの指摘がセキュリティ分類に該当する場合、または auth_surface: new-auth-surface の場合は、ステージ 02 で security を適用します。判断の余地はありません。条件を満たした場合は必ずラベルを適用します。このラベルは分類メタデータであり、マージ保留を意味するものではありません。レビューと同じミッション内で設定します。実際にオーナーの判断が必要かどうかは、cto-review 独自のオーナー権限分類器（#3240）が別途判定します。
15. レーンラベルを決めるのはあなたではなくスクリプトです（#2996） — ステージ 02 で scripts/classify-pr-surface.mts --lane を実行し、出力された値をそのまま適用します。レーンについて独自に判断したり、上書きしたり、差分が「小さく見える」からといって fast にしたりしてはいけません。分類器が唯一の信頼できる情報源です。これに異議がある場合、このミッションで判断するのではなく、LANE_STAGING_GLOBS に対する PR を作成してください。fast という完全一致の文字列以外はすべて、クラッシュ、空の出力、分類器の欠落、レーンが有効でないリポジトリも含め、lane:staging／ラベルなしとして処理します。これは #2996 より前のパイプラインと同じです。fast は常にオプトインです。
16. ラベルの順序は security → lane:* → reviewed とし、reviewed は最後にします（#2996） — reviewed に反応する自動処理は、その Webhook ペイロードに含まれるラベルセットを読み取ります。そのため、reviewed の後にレーンラベルを適用すると、自動処理から認識されず、PR は気付かないうちにフルパイプラインの対象になります。この順序は仕組み上の要件であり、スタイル上の好みではありません。
17. レビュー完了はヘッドに紐付きます — 投稿するレビューには、現在の HEAD SHA を自動取得して記載・記録します。古いレシートを更新する場合、新しいコメントと前提条件となるラベルを適用した後にのみ reviewed を削除して再適用します。これにより、レビュー自体を再開したりブロックしたりせずに、後続ステージへ最新のトリガーを送信できます。

参照ファイル

• CONTEXT.md — アーキテクチャの概要
• stages/NN-name/CONTEXT.md — ステージごとの入力、タスク、手順、出力仕様