review

Pre-Landing Review

依頼された変更に実際の不具合がないか、受け入れ条件を裏付ける証拠が不足していないかをレビューします。レビュー依頼では、デフォルトで報告のみを行います。修正は依頼された場合、またはすでに許可されている場合に限り適用します。レビューの実行から、コミット、プッシュ、マージ、PR の許可を推測してはなりません。

レビュー範囲を固定する

PR のターゲット、または明示的に指定されたベースを特定し、その参照が存在することを確認します。リポジトリの設定やデフォルトブランチを使うのは、あくまで代替手段とし、不確実性があれば明示します。必要に応じて利用可能な場合は、../../../scripts/detect-base-branch.sh で候補を特定できますが、そのフォールバックは証明にはなりません。このパスは、想定上の Claude 環境変数ではなく、読み込まれたスキルディレクトリを起点に解決します。

ネットワークアクセスが可能で、最新性が重要な場合は、ベースを一度フェッチします。ベースの SHA、HEAD、マージベースを記録します。新しいベースの先端に対する差分ではなく、コミット済みのブランチ変更を対象に git diff <merge-base> <head> をレビューします。review-scope.py を --base <verified-ref> とともに使用して、レビュー範囲とフィンガープリントを記録します。作業ツリーの変更を依頼された場合に限り、--include-local を追加します。ローカルパッチと未追跡ファイルは、別個の証拠として扱います。ベースブランチの名前を指定しても、ローカル変更がレビュー対象から除外されるわけではありません。依頼された範囲に変更がなければ、レビューするものはありません。

無関係な変更を保持します。レビュー前にチェックアウトの状態をスナップショットとして記録します。レビュー中に HEAD または対象ファイルが変更された場合は作業を停止し、変更した主体を特定して、影響を受ける証拠の基準点を設定し直します。他の作業者による変更を元に戻してはなりません。

レビュー

スコープを確定したら、差分を読む前にスナップショットだけで進められる作業に着手します。必要な独立レビュー担当者を割り当てます（下記参照）。外部への影響がない場合は、リポジトリに既存のテストコマンドと lint コマンドをバックグラウンドで実行します。テストスイートはポート、データベース、フィクスチャを共有するため、一度に実行するのは1つにします。lint、型チェック、静的解析などの静的チェックはこれらを共有しないため、テストスイートと並行して開始します。独立したレビュー担当者が不要な小規模な差分の場合、バックグラウンドチェックのみを並行作業とします。

同じチェックをバックグラウンドで実行中にフォアグラウンドで実行してはいけません。また、そのログをループでポーリングしてはいけません。レビューを続け、完了通知が届いたら結果を読みます。独立した読み込みと検索は、ターンごとに1つずつではなく、1回のステップでまとめて実行します。

checklist.mdを読みます。利用できない場合は、チェックリストの対象範囲に不足があることを報告します。診断ルールと抑制ルールは適用されますが、スコープ、実行権限、判定についてはこのエントリーポイントが優先されます。

差分をユーザーの目標と PR の意図に照らし合わせ、スコープの追加や要件の漏れがあれば、根拠とともに報告します。変更内容に応じて、差分の範囲外にある共有呼び出し元、永続化データ、列挙型の利用箇所、エラーパス、認可、信頼境界を追跡します。指摘を挙げる前に、既存の処理を確認します。

データ／SQL とマイグレーションの安全性、並行処理、認証、API 契約、LLM の信頼境界を優先します。次に、関連するエラー処理、条件付きの副作用、結合度、テスト、パフォーマンス、フロントエンドの動作を調べます。重要度は、どのチェックリスト項目で見つかったかではなく、実証された影響に基づいて判断します。根拠として使用する前に、該当するセキュリティパターンのみを読みます。

差分が触れる箇所	読むパターン
バッファー／配列の処理（C/C++）	01 Bounds, 11 Integer Arithmetic
新規／変更された認証またはミドルウェア	03 Auth
暗号処理（ハッシュ化、署名、RNG）	04 Crypto Hygiene
パーサー／デシリアライゼーション／アップロード	17 Canonicalization, 02 Injection, 01
並行処理／ゴルーチン／ロック	05 Race Conditions
特権操作のエラーパス	07 Error Handling
依存関係／ロックファイル／CI 設定	08 Supply Chain
Web／ブラウザー／フロントエンド	16 Web App Security
新しい HTTP エンドポイント	03 Auth, 02 Injection, 16 Web
セキュリティ上重要なコードのリファクタリング	14 Regression Prevention

パターンのパスは../../core/review-security/patterns/以下にあります。CVE との類似性は仮説にすぎません。このコードで入力が到達可能か、またその影響を確認してください。API はインストール済みバージョンと信頼できるドキュメントに照らして確認します。利用できないチェックは未検証として示します。

フロントエンドの変更では、既存のデザインシステム、トークン、コンポーネントを使用します（DESIGN.md がある場合はそれも参照します）。該当するチェックにはdesign-checklist.mdを読み込みます。コードだけから推測される懸念は、視覚上の欠陥として扱う前に、レンダリング結果または計算結果で確認します。フォント、グリッド、CSS オーバーライド、小さなラベルが、それだけで欠陥になるわけではありません。複数ファイルにわたる変更や、変更されたフロントエンドのコードが200行を超える場合など、大規模なフロントエンド変更では、読み取り専用のサブエージェント1つにデザインチェックリストを渡してもかまいません。確定したスコープと変更されたフロントエンドのファイルを渡し、チェックリストの形式でコードレベルの指摘を返すよう依頼します。レンダリング結果の確認は主担当レビュー担当者が行い、一度に確認するブラウザーは1つとします。

独立レビュー

主担当のレビューオーナーとして対応する場合、認証／決済／セキュリティに関する重要な変更、新しい外部連携、変更行数が200行を超える差分、または明示的な依頼がある場合は、読み取り専用の別レビュー担当者を利用してください。実際のランタイムでサポートされているツールとモデル設定を使用して依頼してください。API フィールドを勝手に作ったり、Claude のエージェント命名規則が Codex にも適用されると想定したりしないでください。親からの委任制限を守ってください。利用できない場合は、そのカバレッジの不足を記録してください。スコープが確定したらすぐに、あなた自身のレビューを始める前に依頼し、最終判断を下す前に結果を待ってください。

独立レビュー担当者または設計サブエージェントとして割り当てられた場合は、レビューを実施し、根拠を親に返してください。さらに委任したり、テストスイートを開始したり、3人目のレビュー担当者がいないことをカバレッジ不足として記録したりしないでください。確認作業は親が担当します。

レビュー担当者には、目標、正確なベース／ヘッドまたはローカルスナップショット、絶対パスで示したチェックアウト先、関連する未加工の成果物、読み取り専用の制約だけを伝え、あなた自身の所見は伝えないでください。トリガー、ファイル／行の根拠、影響を含む、確認済みの所見を求めてください。所見がゼロでも問題ありません。レビュー対象の範囲と未完了の確認事項を含め、最終回答を求めてください。親としてエージェント ID を記録し、返された根拠を保存してください。応答がない、または部分的な応答は、クリーンなレビューとは見なせません。必要であれば、利用可能な結果を一度だけ確認し、繰り返し依頼せずに不足を報告してください。

所見と許可された修正

各所見には、重要度、ファイル／行、具体的な不具合発生シナリオ、根拠、修正案を記載してください。確認済みの不具合、調査の手がかり、リスクの受容を区別してください。件数のノルマを満たすために所見を作り出してはいけません。

報告のみのモードでは、所見、バックグラウンド確認の結果、最終判断を示した時点で終了してください。修正モードでは、既存の許可範囲内で対象を限定して修正し、実際に設計やスコープに関する判断が必要な事項はまとめ、無関係な変更は含めないでください。修正後は、修正の影響を受ける可能性のあるすべての確認を、最終ファイルに対して再実行してください。それ以外については、バックグラウンドで得られた結果を有効なものとして扱ってください。実際の不具合を明らかにする回帰テストの失敗はそのまま残してください。独立レビューが必要な場合も含め、変更した範囲を再レビューしてください。特定の記述が事実でなくなった場合に限り、ドキュメントの問題を指摘してください。

結果

人が読むレポートには、次の読みやすい出力形式を使用してください。機械処理用のパスでは、呼び出し元が明示したスキーマによって表示形式を置き換えられますが、主担当者は引き続き証拠と判定を報告します。

Pre-Landing Review: N issues (X critical, Y informational) で始めてください。このレビュー中に修正されたものも含め、確認済みの個別の指摘事項を数えてください。実証された影響に基づいて分類します。CRITICAL の指摘事項は未解決の間はランディングを阻止し、INFORMATIONAL の指摘事項は阻止しません。チェックリストのカテゴリ、情報源、修正が機械的なものかどうかによって重大度を決めないでください。未確認の調査上の手掛かりは分けて記載し、件数に含めないでください。

次の両方のセクションを、クリティカルな項目を先にして表示し、空のセクションには None. と記載してください。各指摘事項は簡潔かつ具体的に記述してください。

### CRITICAL — X findings

1. **file:line — Problem title** — UNRESOLVED / FIXED / RISK ACCEPTED

   Problem: failing scenario, consequence and evidence.

   Fix: proposed correction, or the correction applied and its verification status.

### INFORMATIONAL — Y findings

2. **file:line — Problem title** — UNRESOLVED / FIXED / RISK ACCEPTED

   Problem: failing scenario, consequence and evidence.

   Fix: proposed correction, or the correction applied and its verification status.

続いて、簡潔な Markdown の完了テーブルを表示してください。実際の結果を記入し、該当する場合は理由とともに NOT RUN、SKIPPED、または NO RESPONSE を使用してください。失敗したチェックの詳細と未解決の指摘事項への参照は、件数の中に埋もれさせずに保持してください。

完了サマリー	結果
レビュー対象範囲	ベースおよびヘッドの SHA；コミット済みおよび／または依頼されたローカル変更
差分の規模	変更ファイル数、追加行数、削除行数
スコープチェック	CLEAN / DRIFT DETECTED / REQUIREMENTS MISSING。詳細も記載
CRITICAL の指摘事項	合計 X 件；修正済みと未解決の件数；受け入れたリスクは別途記載
INFORMATIONAL の指摘事項	合計 Y 件；修正済みと未解決の件数；受け入れたリスクは別途記載
修正	適用した修正、またはレポートのみ
チェック	コマンドと PASS / FAIL / NOT RUN の結果。影響を受ける修正後のチェックを含む
独立レビュー	完了した結果 / SKIPPED / NO RESPONSE / 利用不可。対象範囲と理由も記載
未解決項目	指摘事項への参照、判断、必要な証拠の不足。なければ None
提出状態	レポートのみ / 未コミットの修正 / その他、明示的に承認された提出

指摘事項がない場合は、Pre-Landing Review: 0 issues (0 critical, 0 informational) を使用し、両方のセクションに None. を記載して、同じテーブルを表示してください。指摘事項がゼロでも、検証が完了したことを意味するわけではありません。

最後に、既存の判定基準に従って、太字のランディング判定と簡潔な理由を記載してください。

• SAFE TO LAND： 未解決のブロッカーがなく、安定した最終ファイルに対する必須の検証と独立レビューが完了している。
• LAND WITH CAUTION： 未解決のブロッカーがなく、必須のゲートがすべて完了しており、明示的にブロッキングではない注意事項または任意のカバレッジ不足がある。
• DO NOT LAND： 確認済みのブロッカー、リグレッション、または必須の証拠の不足がある。「不具合が見つかった」場合と「準備状況が未検証」の場合を区別する。

スキップされたクリティカルな指摘事項は未解決のままであり、判定は DO NOT LAND となります。ユーザーによるリスクの受け入れは別途記録してください。これは指摘事項の重大度や検証状況を変えるものではありません。必須レビュアーから応答がない場合は、指摘事項がゼロなのではなく、証拠が不足しています。判定はマージを承認するものではありません。