autonomous-review

自律レビュー モード

判定を投稿する前に、ヘルパーとラッパーから提供された識別子を使って、長期的に有用なセッション知識を評価します。以前の開発／レビュー候補を確認し、古くなった事実を修正または破棄し、該当する場合は更新しない理由を明示的に記録します。 ../autonomous-common/references/session-knowledge.mdを読みます。Stop フックが確認するのはこの評価であり、教訓の有無ではありません。マージが確認されると、ラッパーが有用で範囲を限定したドキュメントの更新をコミットし、別の PR を作成します。ローカル環境や認証情報への参照は引き続き無視されます。

プロバイダーレーンの適用範囲。 以下の説明は GitHub に関する用語（gh pr review、gh pr merge、gh pr checks、gh pr view、gh issue view）で記述されています。これらは GitHub レーンにおける具体的な形式だからです。すべての INV-52／INV-44 ルール（エージェントが判定コメントを投稿する、ラッパーが承認／変更要求／マージを担う、ラッパーがマージ可能性のハードゲートを適用する）はプロバイダーに依存せず、GitLab レーン（CODE_HOST=gitlab）にもそのまま適用されます。この場合、ラッパーは gh pr * コマンドの代わりに、プロバイダーシーム chp_approve／chp_merge／chp_mergeable を使用します。プロンプトが CODE_HOST=gitlab で実行されている場合は、gh pr …／gh issue … の例をすべてラッパーから提供されるシームのプレースホルダーとして扱います。置き換えとして glab の呼び出しを独自に作成してはいけません。

自律開発セッションで作成された PR を、徹底的かつ客観的にレビューし、その後 判定コメント（Review PASSED または Review findings:）を投稿します。GitHub ネイティブのアクションはレビュー ラッパーが担います。PASS の場合は、マージ可能性と no-auto-close のゲートを通過した後に --approve を送信してマージし、ブロッキング対象の FAIL の場合は --request-changes を送信します。gh pr review や gh pr merge を自分で実行してはいけません。詳しくはGitHub ネイティブの PR アクションを送信するのは誰か（INV-52）を参照してください。

使用する場面

このスキルを使用	別のスキルを使用
完了した PR の最終判定（判定コメントを投稿し、ラッパーが承認してマージするか、変更を要求します）	実装中の開発側による進行中のセルフレビュー → autonomous-dev Step 8（pr-review）を使用
ディスパッチャーから pending-review または reviewing ラベル付きの PR を引き継いだ場合	ドラフト PR の部分的な手動レビュー → pr-review-toolkit エージェントを直接使用
E2E 検証の実行、受け入れ基準の確認、マージコンフリクトの解決	CI ステータスの確認のみ → gh pr checks を直接使用

クロスプラットフォームに関する注意事項

このスキルは、スキルをサポートするすべての IDE／CLI で動作します。ブラウザーの自動化手順では Chrome DevTools MCP を使用します。E2E 検証を行うには、IDE でこの MCP サーバーが設定されていることを確認してください。

フック（任意）

IDE がフック（Claude Code、Codex CLI、Kiro CLI）をサポートしている場合、hooks/ のワークフロー強制フックが自動でゲートを確認します。フックがない場合は、各手順を手動で実行してください。

レビューチェックリスト

以下のすべてを確認します。

コードに関する指摘には、プロジェクト設定またはラッパープロンプトにある REVIEW_BLOCKING_SEVERITY を使用します。デフォルトの P1 は、第 1 ラウンドでは P0／P1 のみをブロッキング対象にします。P2／P3 の指摘は、修正を必須とせずに表示されたままにします。P2／P3 は、より厳しい固定の基準を選択します。adaptive は、ラウンドに応じて変わる従来の基準を選択します。必須の受け入れ基準、セキュリティ制御、テスト、CI、マージゲートは引き続きブロッキング対象です。タグのない正確性に関する指摘は、対応を先送りする前に分類します。スタイル上の好みを P1 に格上げして、整理を強制してはいけません。助言としての対応方針が文書化されていれば、対応済みとみなします。

フォローアップラウンドでは、既存のブロッキング対象と、変更されたコードおよび影響を受ける契約を確認します。新たな根拠がある場合にのみ、解決済みの指摘を再度取り上げます。変更内容に応じてレビューの範囲を広げます。同じ HEAD に対する有効な検証結果は再利用します。ラッパーがすでに E2E を実行している場合は、再実行せず、その結果とカバレッジを確認します。

1. プロセス遵守

• 変更内容またはリポジトリのポリシーで必要な場合、設計キャンバスがある
• ブランチ名が命名規則（feat/、fix/、refactor/ など）に従っている
• 必要な場合、テストケースが文書化されている。既存のリグレッションテストで小規模な修正を文書化できる場合もある
• PR の説明がテンプレートの各セクション（概要、設計、テスト計画、チェックリスト）に従っている
• PR がイシューを参照している（Closes #N または Fixes #N）

2. コード品質

• セキュリティ上の問題がない（認証情報やインジェクションの脆弱性がない）
• TypeScript の型が正しい（any を不適切に使用していない）
• エラー処理が適切である
• コードがコードベースの既存パターンに従っている
• 明らかなパフォーマンスの低下がない

3. テスト

• 新機能のユニットテストがある
• 新しいコードのユニットテストカバレッジが妥当である
• UI に変更を加えた場合、E2E テストが更新されている
• すべての CI チェックに合格している

4. インフラストラクチャ（該当する場合）

• Infrastructure-as-Code の変更が安全である
• リソースが誤って削除されない
• IAM 権限が最小権限の原則に従っている

5. 任意：ボットレビュアーの確認

• 設定済みのボットレビュアーがレビューを投稿している場合、指摘事項に対応済みであることを確認する
• すべてのボットレビューのスレッドが解決済みである
• ボットレビューがなく、設定済みの場合は、scripts/gh-as-user.sh を使って実行する（下記「ボットレビュアーの実行」を参照）

ボットレビュアーの実行

必須ボットのセットは、プロジェクトの autonomous.conf にある REVIEW_BOTS によって決まります。REVIEW_BOTS が空の場合、このセクション全体をスキップします。それ以外の場合は、設定されている各ボットを実行します。

scripts/gh-as-user.sh が必須です。 組み込みのボット（Amazon Q、Codex、Claude）は、GitHub App のボットアカウントが投稿した実行コメントを拒否します。このラッパーを使うと、実際のユーザーとして投稿できます。

組み込みボットの実行方法：

# When q ∈ REVIEW_BOTS:
bash scripts/gh-as-user.sh pr comment {pr_number} --body "/q review"

# When codex ∈ REVIEW_BOTS:
bash scripts/gh-as-user.sh pr comment {pr_number} --body "/codex review"

# When claude ∈ REVIEW_BOTS (note: @claude, not /claude):
bash scripts/gh-as-user.sh pr comment {pr_number} --body "@claude review"

REVIEW_BOTS_<NAME>_TRIGGER で宣言されたカスタムボットには、設定済みのトリガーを使用してください。

ボットレビューを実行するコメントには、デフォルトの gh pr comment を使用しないでください。ボットとして認証されるためです。プロジェクトで scripts/gh-as-user.sh を利用できない場合は、gh pr comment にフォールバックし、一部のボットが実行トリガーを無視する可能性を許容してください。

6. E2E 検証

E2E 検証が設定されている場合、このセクションは必須です。 ラッパーは E2E_MODE に応じて、2 つの手順のいずれかを挿入します。どちらの手順もプロンプトにない場合は、このセクションをスキップしてください。

ブラウザーモード（E2E_MODE=browser、SaaS ウェブアプリ向け）：

• PR のコメントからプレビュー URL を取得している
• Chrome DevTools MCP 経由でプレビュー URL に正常にアクセスしている
• プレビュー環境でテストユーザーのログインを確認している
• ハッピーパスのテストケースを選択して実行している（下記のセクションを参照）
• 稼働中のプレビュー環境で機能テストケースを実行している
• リグレッションテストを実行している（認証、ナビゲーション、コンソールエラー）
• スクリーンショットを取得してアップロードし、証拠としてリンクしている
• スクリーンショットへのリンクを含む E2E 検証レポートを PR コメントとして投稿している

コマンドモード（E2E_MODE=command、バックエンドパイプライン／CLI／ライブラリ向け）：

• 前処理フックを実行している（設定されている場合）— 終了コード 0
• タイムアウト時間内に検証コマンドを実行している — 終了コード 0（または回復可能なタイムアウト）
• 証拠パーサーが `` で終わる Markdown ブロックを生成している
• 証拠ブロックを PR コメントとして投稿している
• 検証可能な成果物を指定する、イシュー本文内のすべての受け入れ基準が証拠ブロックで網羅されている

マージ競合の解決 — レビュー前の必須手順

レビューを開始する前に、PR ブランチと main の間にマージ競合がないか確認してください。競合がある場合は、PR をマージ可能な状態にするため、ブランチをリベースしてください。リベース手順、競合への対処、失敗時のプロトコルについては、references/merge-conflict-resolution.md を参照してください。

簡易チェック：

MERGEABLE=$(gh pr view <PR_NUMBER> --repo <REPO> --json mergeable -q '.mergeable')

• MERGEABLE — レビュープロセスに進みます
• CONFLICTING — references に記載されたリベース手順に従います。これはブロッキング指摘事項です（FAIL）
• UNKNOWN — 待機して再試行します（最大 3 回）。それでも UNKNOWN の場合、MERGEABLE として扱わず、次のティックまでレビューを未確定のままにします

この手順はベストエフォートのプロンプトガイダンスです。レビューラッパーは、判定結果を集約した後、同じルールを機械的に強制します（マージ可能性のハードゲート、INV-44）。この手順を省略しても、CONFLICTING の PR が承認されることはありません。また、UNKNOWN が続く PR は自動承認されず、再キューイングされます。

レビュープロセス

1. イシューを読む — 要件を理解します
2. イシューのコメントをすべて読む — 要件の変更がないか確認します（下記の「要件の変更の検出」を参照）
3. PR の差分を十分に読む — (gh pr diff <number>)
4. CI のステータスを確認する — (gh pr checks <number>)
5. 設計ドキュメントやテストケースなどのファイルを読み、それらが存在することを確認します
6. 上記のチェックリストに照らしてコード品質を評価する
7. ボットレビューアーの指摘事項を検証する（設定されている場合。チェックリストのセクション 5 を参照）
8. PR の差分分析に基づいてハッピーパステストケースを選択する（下記を参照）
9. E2E 検証を実施する（設定されている場合。下記の手順を参照）
10. 受け入れ基準に印を付ける — 検証済みの各基準について、イシュー本文のチェックボックスに印を付けます（「受け入れ基準への印付け」を参照）
11. 必須のセルフチェックゲート — レビュー判定を提出する前に、「指摘事項から判定へのゲート」を実行します（下記を参照）

要件の変更の検出 — 必須

この手順は、PR の差分を読む前に必ず実施してください。リポジトリのオーナーやメンテナーからのイシューコメントにより、実装後に要件が変更される場合があります。

イシューの本文だけでなく、コメントをすべて読み、以下を確認してください。

• スコープの変更（「削除」「不要になった」「取り下げ」「サポートしない」「〜の代わりに」）
• 元のイシュー作成後に追加された新しい要件
• リポジトリのオーナーによる訂正や明確化
• まだ PR のコードに反映されていない可能性のある、開発エージェントへの明示的な指示

# Read all issue comments to check for requirement changes
gh issue view <ISSUE_NUMBER> --repo <REPO> --json comments \
  -q '.comments[] | "\(.author.login) [\(.createdAt)]: \(.body[0:500])"'

PR のコードに反映されていない要件変更が見つかった場合：

• これは**[BLOCKING] 要件の変更**に関する指摘事項です
• 変更内容について具体的に指示し、PR を開発担当者に差し戻す必要があります
• 要件を変更したコメントを引用します
• 更新が必要なコードやファイルを具体的に列挙します

ハッピーパステストケース

ハッピーパステストケースはプロジェクトによって異なります。レビューエージェントは、以下に基づいてケースを選択します。

1. docs/test-cases/ ディレクトリを読み、利用可能なテストケースのドキュメントを確認します
2. PR の差分を分析し、変更された領域を特定します
3. 変更された機能を対象とする、最も関連性の高いテストケースを選択します
4. レビューごとに、少なくとも 1 つのハッピーパステストケースを実行します

テストケースのドキュメントが存在しない場合は、基本的なスモークテストを実行します。

• アプリケーションのルート URL に移動します
• ページがエラーなく読み込まれることを確認します
• ブラウザーのコンソールで JavaScript エラーを確認します

E2E 検証手順

このセクションは、E2E 検証が設定されている場合にのみ適用されます。 レビューラッパースクリプト（autonomous-review.sh）は、autonomous.conf のプロジェクト設定 E2E_MODE に応じて、以下の 2 つの E2E 手順のいずれかをプロンプトに挿入します。

• E2E_MODE=browser — Chrome DevTools MCP UI スモークテスト（ログイン、移動、スクリーンショット）。PR ごとのプレビュー URL がある SaaS Web アプリ向けです。
• E2E_MODE=command — プロジェクトが提供する検証コマンドを実行し、出力された証跡を検証します。バックエンドパイプライン、CLI ツール、ライブラリ、インフラストラクチャ・アズ・コード、ML パイプライン向けです。

どちらのブロックもプロンプトに含まれていない場合、プロジェクトでは E2E が無効になっています（E2E_MODE=none または未設定）。このセクションはスキップしてください。

ブラウザーモード

ブラウザーモードの手順全体（ブラウザーの自動化、スクリーンショットのアップロード、テストの実行、レポート形式）については、references/e2e-verification.md を参照してください。

主な手順：

1. プレビュー URL にアクセスできることを確認する
2. Chrome DevTools MCP 経由でブラウザーを開き、移動する
3. テストユーザーの認証情報でログインする
4. 正常系と機能テストのケースを実行する
5. リグレッションチェック（認証、ナビゲーション、コンソールエラー）を実行する
6. スクリーンショットの証拠を添えて、構造化された E2E レポートを PR に投稿する

コマンドモード

契約全体（プロジェクト側のスクリプト要件、証拠ブロックの形式、終了コードの意味、オンボーディングの例）については、references/e2e-command-mode.md を参照してください。

主な手順：

1. 設定されている場合は、事前フックを実行する（例：PR ごとのステージング環境にテストデータを投入する）
2. タイムアウトを設定して検証コマンドを実行する
3. 終了コードを確認する（0 = 成功、124 = タイムアウト、その他 = 失敗）
4. 証拠パーサーを実行して、構造化された Markdown ブロックを抽出する
5. ブロックの末尾に SHA バインドマーカー `` があることを検証する（以前のコミットの古い証拠がコメントに再利用されるのを防ぐため、SHA が必要です）
6. 証拠ブロックを PR コメントとして投稿する
7. 終了コードと、証拠と AC の網羅性に基づいて PASS/FAIL を判断する

受け入れ基準のチェック

E2E 検証中に確認したら、イシューボディ内の各受け入れ基準のチェックボックスにチェックを入れてください。

手順

1. イシューボディを読み、## Acceptance Criteria セクションを特定する
2. 各基準について： a. Chrome DevTools MCP、コードの確認、または CI チェックの結果を使って検証する
   b. 合格した場合は、チェックボックスにチェックを入れる：

   bash scripts/mark-issue-checkbox.sh <ISSUE_NUMBER> "<criterion text>"
   

   c. 失敗した場合は、チェックを入れるのを中止し、失敗を記録して「Review findings」に進む
3. このスクリプトは gh を使用します（GH_TOKEN_FILE を介してアクティブな App トークンを取得するため、編集は設定済みのレビューボットによるものとして表示されます）

重要なルール

• 基準にチェックを入れるのは、検証した後だけにしてください。事前にチェックを入れてはいけません
• 基準が1つでも失敗した場合は、チェックを入れず、代わりに「Review findings:」を投稿してください
• Requirements のチェックボックスにはチェックを入れないでください。これらは開発エージェント用です
• PR を承認する前に、すべての受け入れ基準にチェック（- [x]）を入れてください

Findings → Decision Gate — 必須

このゲートは絶対に省略できません。PR レビュー（APPROVE または REQUEST_CHANGES）を提出する前、および issue に判定コメントを投稿する前に、必ずこのセルフチェックを実施してください。

ゲートの手順（指摘事項の分類、ブロッキングと非ブロッキングのルール、セルフチェックの質問、判定基準、出力形式）の詳細については、references/decision-gate.md を参照してください。

厳守すべきルールの概要：

• ブロッキング指摘事項が1つでもある場合 -> 判定は必ず FAIL — Review findings: を投稿します（その後、ラッパーが --request-changes を送信します）。
• ブロッキング指摘事項が0件の場合 -> 判定は PASS — Review PASSED を投稿します（その後、ラッパーがゲートを通過したうえで --approve を送信し、マージします）。
• 中間の判定はありません — ブロッキング項目を含む Review findings: コメントと Review PASSED コメントは、相互に両立しません。

レビュー結果は issue にコメントとして投稿してください（PR ではありません）。投稿には、決定論的なヘルパー bash scripts/post-verdict.sh <issue> <pass|fail> <body-file> <agent-name> <session-id> [<model>] だけを使用してください。判定の投稿に、単独の gh issue comment を使用してはいけません（INV-56）。このヘルパーは、ラッパーがポーリングする Review PASSED / Review findings: の1行目を保証し、さらに Review Session: \`とReview Agent: のトレーラーを自動で追加するため、自分で記述する必要はありません。省略可能な6番目の引数 を指定すると、ヘルパーはエージェントの行にこれを含め、判定コメントにどのモデルが生成したかを記録します（Review Agent: (model: )）（[INV-60](../../docs/pipeline/invariants.md)）。複数行の指摘事項本文にあるバッククォートや引用符が壊れないよう、本文は argv 文字列ではなく **ファイル** で渡してください。ラッパーがプロンプトで 、、` を指定するので、そのまま渡してください。出力するのは判定コメントだけです — GitHub ネイティブの PR アクション（以下を参照）はラッパーが実行します。

Claude のレビューメンバーについては、ラッパーは起動時に、少なくとも1つの無人判定報告経路が設定されていることも確認します。#524 の障害シグネチャ、修正方法、抑制の契約については、Claude の無人判定経路に関する起動時警告を参照してください。

GitHub ネイティブの PR アクションを実行するのは誰か（INV-52）

GitHub ネイティブの PR レビュー／マージアクションを実行するのはレビューラッパーであり、あなたではありません。 post-verdict.sh を使って判定 コメント を投稿すると、ラッパーがそのコメントを読み取って処理します。

• PASS の場合、ラッパーは機械的なマージ可能性のハードゲート（INV-44）と no-auto-close によるマージスキップの確認を行った後、gh pr review --approve を送信し、issue に no-auto-close が設定されていなければ gh pr merge を実行します。
• ブロッキング指摘事項による FAIL の場合、ラッパーは gh pr review --request-changes を送信し、PR の reviewDecision を CHANGES_REQUESTED にします。これは、人間、ブランチ保護、dev-resume エージェントにとっての正式な判断となります（INV-52）。
• 自分で gh pr review --approve、gh pr review --request-changes、gh pr merge、または MCP のマージツールを実行してはいけません。 これを行うとラッパーのゲートとの競合状態が発生します。自分で承認してマージすると、マージ可能性が UNKNOWN のままの PR（INV-44）や、no-auto-close が設定された issue の PR をマージするおそれがあります。これはまさに INV-52 のきっかけとなった PR #191 のインシデントです。GitHub の PR レビューまたはマージを実行するエージェントは、近道をしているのではなく、欠陥です。

マルチエージェントレビュー（設定されている場合）

プロジェクトで AGENT_REVIEW_AGENTS に複数の CLI が設定されている場合、複数のレビューエージェントが並行して同じ PR をレビューします。それぞれが完全に独立したレビュアーとして動作します。そのうちの 1 つである場合：

• Findings -> Decision Gate を独立して実行し、自分自身の調査結果に基づいて PASS／FAIL を判断してください。他のエージェントと調整したり、他のエージェントの判断に委ねたりしないでください。他のエージェントの判定を見ることはできません。
• 割り当てられたエージェント名とセッション ID（どちらもプロンプトに記載されています）を指定して、bash scripts/post-verdict.sh で自分の判定を投稿してください。gh issue comment を直接使用してはいけません（INV-56）。このヘルパーは、渡された引数から Review Agent: <name> という識別行を記述するため、常に正しい内容になります。この行によって、ラッパーは並行レビュー担当者の中からあなたの判定を識別します（INV-40）。
• ラッパーは、すべてのエージェントが PASS することを条件に判定を集約します。利用可能なエージェントがすべて PASS した場合にのみ、ラッパーは承認してマージします。1 つでも FAIL があれば、ラッパーは --request-changes を送信し、PR を開発担当者に差し戻します。これは、エージェント間にも適用した、ゲートの「ブロッキング対象の指摘が 1 つでもあれば FAIL」という方針です。前述のとおり、GitHub ネイティブのアクションを送信するエージェントはありません。集約後にラッパーが一度だけ送信します。

内部レビューサブエージェントは助言を行います

Claude または Codex の内部サブエージェントは、セキュリティ、テスト、保守性など、さまざまなレビュー観点を並行して調査する場合があります。調査結果と指摘を親エージェントに返します。これらは助言を行うものであり、AGENT_REVIEW_AGENTS の一員ではありません。

ラッパーによって割り当てられた判定セッションでは、親レビューセッションのみが Findings -> Decision Gate を実行し、ラッパーから提供されたエージェント名とセッション ID を指定して post-verdict.sh を呼び出します。内部サブエージェントに post-verdict.sh を委任しないでください。各親エージェントは、助言として得た指摘を自身の PASS／FAIL 判定にまとめる必要があります。

次の 3 つの仕組みを区別してください。REVIEW_BOTS は外部のコードホスト上のレビュアー、AGENT_REVIEW_AGENTS は独立して判定を行うラッパー管理下のセッション、内部サブエージェントはそのようなセッション内で助言を行う作業者です。

---

参考資料

詳細な手順については、以下を参照してください。

• references/merge-conflict-resolution.md -- リベースの全手順、競合への対処、失敗時のプロトコル
• references/e2e-verification.md -- ブラウザー自動化の手順、スクリーンショットのアップロード、テストの実行、E2E レポート形式（E2E_MODE=browser）
• references/e2e-command-mode.md -- プロジェクト提供の検証コマンドの仕様、エビデンスブロックの形式、導入例（E2E_MODE=command）
• references/decision-gate.md -- 指摘の分類、ブロッキングルール、判定基準、出力形式