cto-review

目的

単一 PR に対する CTO レベルの戦略的レビューを、重要な判断（差分全体のレビュー）がクリーンなコンテキストウィンドウで行われるよう、独立したステージに分けて実施します。ステージ 01 では、PR のメタデータ、差分全体、リポジトリのコンテキスト、マージ状態を収集します。ステージ 02 では、分離されたコンテキストで、ドキュメントの不足、外部依存関係、下流／テンプレートへの影響、正確性、セキュリティ、マージ戦略、アクション項目など、あらゆる観点から差分全体を一貫してレビューします。ステージ 03 はインラインで実行され、GH レビューコメントの投稿、判定ラベルの適用、マージ状態を尊重したマージまたはラベル付け、レポートファイルの書き込み、結果マーカーの出力を行います。

この手順はPR レビュー専用です。ハートビートモードはありません。

引数

Param	Required	Default	Notes
PR_NUMBER	yes	—	レビュー対象の PR 番号
org/repo	yes	—	対象リポジトリ。例：fellowship-dev/booster-pack

$ARGUMENTS から位置順に解析します。1 つ目のトークンは PR 番号、2 つ目は org/repo です。 例：/cto-review 742 fellowship-dev/booster-pack。

実行内容

3 ステージの ICM 手順（順次実行）：

Stage	Mode	Description
01-setup	subagent	リポジトリのコンテキスト、PR メタデータ、差分全体、マージ状態、すべての PR コメントとラベルのスナップショット（#2918）、パイプラインのレーンを解決（#2996、ステップ 5.3）し、DB を正とするチームの deploy.release_mode からマージ権限を解決します。自動マージが許可されるのは、明示的に ship が指定された場合のみです。それ以外の状態ではラベルのみを付けます。早期終了するのは CLOSED かつ未マージの場合のみです。ステージング証拠のゲートはありません（pylot#3389）。視覚的証拠（5.6）は通知であり、早期終了の条件ではありません。最初に PR 本文を検索し、その後コメントを新しい順に検索します。見出しから 3 行以内の N/A を免除として受け入れます。
02-review	subagent	まず判断レイヤー（#2918）：すべてのラベルとコメントを読み、すべてのブロッカーを特定して分類（解決済み／未解決）します。その後、差分全体をあらゆる観点から一貫してレビューし、判定、チェックリスト、アクション項目、根拠ブロックを作成します。レビューの深さはどちらのレーンでも同じです。
03-synthesize-act	inline	GH コメントを投稿（常に ## Checked / Found の根拠を含む）し、ラベルを適用します。ステップ 3.0：オーナーゲート（#2918、#3240）— 人間が付けた waiting-on-owner が存在する（ラベルを最新の状態で再取得）か、ステージ 02 の owner_authority_class != none の場合は、保留コメント（判断を示す 1 行と回答者の名前）を投稿し、waiting-on-owner を適用して status=blocked を出力し、停止します。security はトリガーになりません。ステップ 3.1：レーンのマージ基準（#2996）— 同じ最新の読み取り結果に基づき、lane:fast では reviewed のみ、それ以外では reviewed と double-checked の両方が必要です。条件を満たさない場合は、マージ状態を尊重してマージまたはラベル付けを行い、レポートファイルを書き込み、結果マーカーを出力します。

ステージ 02 は、重要な判断を行う分離されたステップです。受け取るのはステージ 01 からの引き継ぎ情報と自身の CONTEXT.md のみで、オーケストレーターの履歴は受け取りません。

引き継ぎ情報の保存場所

すべての引き継ぎ情報は、リポジトリの作業ディレクトリに保存されます：

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

ステージ 01 は setup を書き込みます。ステージ 02 は setup の引き継ぎ情報のみを読み取ります。ステージ 03 は両方を読み取ります。

実行

ステージ 01（subagent）

Task を 1 つ起動します。引数（PR 番号、org/repo）とステージの CONTEXT.md のパスのみを渡します。

Task プロンプトのテンプレート：

You are running stage 01-setup of the cto-review procedure.

Arguments:
  PR_NUMBER = {PR}
  REPO = {org/repo}

Read your stage instructions:
  skills/cto-review/stages/01-setup/CONTEXT.md

Write your output to:
  .procedure-output/cto-review/01-setup/handoff.md

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

ステージ 01 の完了後、.procedure-output/cto-review/01-setup/handoff.md を読み、short_circuit を確認します：

• short_circuit: closed-no-merge の場合 → ステージ 02 をスキップし、ステージ 03 に進みます（何も投稿せず、blocked／closed の結果を出力します）。
• それ以外の場合 → ステージ 02 に進みます。

視覚的証拠がないことは早期終了の条件ではなく、ここには表示されません。引き継ぎ情報では ## Visual Evidence → notice: yes として記録され、ステージ 03 でレビューコメントに助言の行として追加されます。マージ基準には影響せず、needs-work も適用せず、どのステージも抑止しません。「ゲートではなく通知である理由」については、ステージ 01 の CONTEXT.md を参照してください。

ステージ 02（サブエージェント）

Task を 1 つ起動します。ステージ 01 の引き継ぎパスと、ステージの CONTEXT.md パスのみを渡してください。オーケストレーターの履歴や、それ以前の推論は渡さないでください。レビューは、履歴から隔離されたクリーンなコンテキストで実行する必要があります。

Task プロンプトのテンプレート：

You are running stage 02-review of the cto-review procedure.

Read your stage instructions:
  skills/cto-review/stages/02-review/CONTEXT.md

Your inputs:
  .procedure-output/cto-review/01-setup/handoff.md

Write your output to:
  .procedure-output/cto-review/02-review/handoff.md

Review the WHOLE diff cohesively across all dimensions. Write handoff.md before exiting.

ステージ 03 に進む前に、ステージ 02 の完了を待ちます。

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

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

skills/cto-review/stages/03-synthesize-act/CONTEXT.md

オーケストレーターからコメントを投稿し、ラベルを適用し、マージまたはラベル付けを行い、レポートファイルを書き込み、[pylot] outcome=... マーカーを出力します（サブエージェントからではありません）。

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

01-setup ──► 02-review ──► 03-synthesize-act (inline, reads 01 + 02)
   │   (labels+comments│    (judgement layer: labels/comments/blockers → receipts)
   │   +lane captured) │         │
   │                   ▼         ▼
   │                        Step 3.0: Owner Gate (human label fresh + stage-02 class) — LANE-INDEPENDENT
   │                              │
   │                              ├── waiting-on-owner OR owner_authority_class≠none ──► park + status=blocked
   │                              └── clear ──► Step 3.1: lane merge bar
   │                                              ├── lane:fast ──► require `reviewed`
   │                                              └── else      ──► require `reviewed` + `double-checked`
   │
   └── short_circuit: closed-no-merge ──────────────────────► 03 (no-op)

   (visual evidence: notice only — flows through 02/03 as an advisory line, never blocks)

終了パス

• 成功：ステージ 03 が [pylot:$PYLOT_OUTCOME_NONCE] outcome="cto-review PR #{N} complete — verdict={verdict}, action={merged|labeled}" status=success を出力します
• 失敗：失敗したステージが [pylot:$PYLOT_OUTCOME_NONCE] outcome="cto-review failed at stage NN: {reason}" status=failed を出力します
• ブロック（クローズ済み）：[pylot:$PYLOT_OUTCOME_NONCE] outcome="cto-review skipped: PR #{N} closed without merge" status=blocked
• ブロック（オーナー判定）：[pylot:$PYLOT_OUTCOME_NONCE] outcome="cto-review parked: PR #{N} — owner decision required" status=blocked（#2918、#3240 — 人間が waiting-on-owner を適用した場合、またはステージ 02 のオーナー権限判定器が 5 つの限定されたクラスのいずれかに一致した場合に発生します。security はトリガーになりません。保留コメントと waiting-on-owner ラベルが適用されます）

厳守事項

1. 逐次実行のみ — サブエージェントは一度に 1 つだけ実行し、Task を並列で起動してはいけません。
2. Stage 02 は独立した判断ステップです — 受け取るのはセットアップの引き継ぎ情報と、その CONTEXT.md のみです。
3. オーケストレーターのコンテキスト全体をサブエージェントの Task プロンプトに渡してはいけません — 入力情報のみを渡します。
4. 差分全体は、まとまりのある 1 つのステージでレビューします — ファイルごと、または観点ごとに分割してはいけません。
5. Stage 03 はインラインで実行します — GitHub への副作用と [pylot] outcome=... マーカーは、オーケストレーターが出力しなければなりません。
6. 各ステージは、次のステージが読み取る前に handoff.md を書き込みます。
7. ステージを省略してはいけません — CLOSED-no-merge の短絡時に Stage 02 を省略する場合を除き、すべてのステージを実行します。
8. マージ状態を尊重します — CLOSED の PR は決してマージせず、すでにマージ済みの PR ではマージ後の注記としてレビューを投稿し、マージを試みてはいけません。
9. CI がブロックされている場合はマージしません — Stage 01 は CI を pass、block、na-no-configured-checks のいずれかに一度だけ分類します。CI の前提条件を満たすのは pass または N/A のみです。N/A の場合も、通常のレビュー、レーン、オーナーゲート、マージ権限の要件は引き続き必要です。
10. Quest は使用しません — 報告はローカルのレポートファイルのみです。
11. エビデンス確認による短絡はありません。ステージングエビデンスのゲート（ルール 16）はありません。 ビジュアルエビデンス（ステップ 5.6）は通知であり、ブロッカーではありません — 引き継ぎ情報に記録し、Stage 03 が助言の行として追記します。短絡することも、ラベルを適用することも、マージ条件に影響することもありません。この通知には、セルフサービスの手順を必ず記載しなければなりません。「スクリーンショットを追加してください」だけのメッセージをなくすことが、このルールの目的です。
12. 以前のレビューのコメントに基づいて範囲を決め、推測しないでください — セットアップではすべての PR コメントを取得します。レビューでは、review-pr/double-check コメントで確認されている内容を信頼し、確認されていない内容を抜き取り確認し、未解決の指摘を判定材料として扱います。以前のレビューが見つからない場合は、何も確認されていないものとして、全面的にレビューします。
13. オーナーゲートは無条件です（#2918、#3240） — Stage 03 のステップ 3.0 は、独立した 2 つのトリガーのいずれかで発動します。人が適用した waiting-on-owner（GitHub ラベルを新たに読み取って確認）か、Stage 02 の owner_authority_class != none（5 種類の分類に限定した分類体系との一致。値をそのまま読み取り、Stage 03 では再判定しない）のいずれかです。security は単独ではトリガーにならず、分類メタデータとしてのみ扱います。どちらのトリガーも、判定、CI の状態、PR 内の文章にかかわらず発動します。LGTM 判定でゲートを解除することはできません。waiting-on-owner を解除できるのは人の操作のみです。このルールは、連続して 2 回発生した実際の迂回事例（#2912、#2935）を受けて設けられました。どちらの場合もモデルが自らを説得してマージしたため、このチェックはプロンプトではなくコードで実装されています。
14. すべての判定コメントに確認内容を記載します（#2918） — Stage 03 が投稿するすべてのコメントで、## Checked / Found セクション（確認したラベル、コメント数と最終投稿者、ブロッカー → ステータス）は必須です。確認内容を列挙せずに、暗黙の LGTM を出してはいけません。ファストレーンの PR では、確認内容にレーンと補完的な制御（ステップ 3.1 のリスト）も記載します。この取引の要点は、補完的な制御を前提とせず、明示することにあります。
15. レーンは LEGACY です（オーナー裁定 2026-09-06） — lane:fast／lane:staging ラベルは、もはや単なる情報ではありません。マージ条件のデフォルトは reviewed double-checked です。歴史的なファストレーンの例外（double-check が意図的に実行されなかった lane:fast PR）は、引き続き reviewed のみでマージされます。このような PR に対して、double-checked がないことを理由に needs-work にしてはいけません。新しいレーンラベルは出力されません。
16. ステージングエビデンスの要件はありません（pylot#3389） — cto-review は、どの PR についてもステージングエビデンスを要求、確認、またはブロッカーとして扱いません。ステージングはリリースプロセスが担当するリリーストレインのステップであり、本番環境に到達する前に scripts/ci-release-gate.sh が引き続き全範囲のコーパスを実行します。「ステージングエビデンスがない」と、ブロッカーや needs-work 項目に記載してはいけません。
17. マージ権限は明示的で、DB を正とします — Stage 01 は、Pylot CLI 経由で実際のチーム設定を読み取る resolve-merge-strategy.sh を必ず使用しなければなりません。自動マージ権限を付与するのは deploy.release_mode=ship のみです。propose、設定の欠落、参照の失敗、不正な出力、またはリポジトリとチームの対応関係が曖昧な場合は、すべて label-only になります。古い crew.yml を読み取ってはいけません。また、自動マージをデフォルトにしてはいけません。

参照ファイル

• CONTEXT.md — アーキテクチャの概要
• shared/review-comment-format.md — 正確な GH レビューコメントのテンプレート（元のスキルからの原文）
• shared/report-format.md — ローカルレポートファイルのテンプレート
• stages/NN-name/CONTEXT.md — 各ステージの入力、タスク、出力仕様