review-code

コードレビュー

安全境界

ローカルでのコードレビューは読み取り専用とし、指摘事項のみを報告します。

• ファイルの編集、変更のステージング、コミット、プッシュ、プルリクエストの作成、GitHub コメントの投稿、レビュー スレッドの変更は行わないでください。
• 作業ツリーに書き込みを行うフォーマッター、ジェネレーター、修正ツール、インストーラー、その他のコマンドを実行しないでください。
• シークレットを読み取ったり、要求したり、表示したり、推測したりしないでください。
• 同じスレッド内でのレビューに切り替えないでください。新しいレビュアーを起動できない場合は中止してください。

スコープ

1. gh repo view --json defaultBranchRef --jq .defaultBranchRef.name または git rev-parse --abbrev-ref origin/HEAD を使って、リポジトリのデフォルトブランチを特定します。フォールバックの場合は、先頭の origin/ を取り除いて正規化し、ブランチ名を origin/main ではなく main にします。どちらの方法でもデフォルトブランチを特定できない場合は、たとえば git remote set-head origin --auto を実行するなど、このスキルの外部で origin/HEAD を設定する手順を示して中止します。
2. 現在の origin/<default-branch> ref を使います。レビュー中に ref を更新してはいけません。git rev-parse --verify origin/<default-branch> を使ってローカル ref の存在を確認します。gh が利用できる場合は、gh repo view --json nameWithOwner --jq .nameWithOwner を使って {owner}/{repo} を特定し、ローカルの SHA と gh api repos/{owner}/{repo}/branches/{branch} --jq .commit.sha で取得したリモートのデフォルトブランチの SHA を比較します。異なる場合は、両方の SHA を報告して中止します。リモートの最新状態を確認できない場合は、レポートに最新状態が未確認であることを記録したうえでのみ続行します。
3. 正規化後、git merge-base origin/<default-branch> HEAD を使ってレビューのベースを計算します。
4. デフォルトブランチのマージベースから現在のブランチまでに加え、ステージ済み、未ステージの変更、および未追跡のローカル変更をレビューします。削除されたファイルも含めます。
5. レビューの前にリポジトリの指示を読み込みます。AGENTS.md、存在する場合は CLAUDE.md、およびそれらが明示的に読み込むドキュメントが対象です。
6. リポジトリの指示または差分によって関連性がある場合を除き、生成ファイル、ロックファイル、ベンダー ファイル、dogfood オーバーレイのパスは重要度の低い情報として扱います。

新しいレビュアーの起動

プライマリエージェントはスコープの計算とコンテキストの収集を行ってもかまいませんが、実際のレビューは、新しいレビュアーエージェント、または同等の隔離された実行環境で、コンテキストを新たにして実施する必要があります。実装に関する会話を引き継いではいけません。ブランチ差分のレビューはスコープが限定されたコードベースの問題であるため、利用可能な場合は、ホストが提供する読み取り専用の Explorer またはバックグラウンドレビュアーエージェントを優先してください。

Codex では、呼び出し元がすでにローカルレビュー、/review-code、またはレビューゲートに進むイシューワークフローを依頼している場合、ユーザーに再確認を求めず、新しい Explorer バックグラウンドエージェントを起動してレビューを行います。1 回のレビューにつきレビュアーは 1 人だけにしてください。同じ未解決のレビューを重複して行ってはいけません。

レビュアーには、起動、完了待ち、結果の取得と報告、終了というライフサイクルがあります。最終レポート、タイムアウトの通知、または要求された途中結果を取得する前に終了してはいけません。タイムアウトまたは途中結果が要求された場合は、有用な出力を取得して報告した後に終了します。起動前に、出力をすでに使用した、キャンセルした、または置き換えた、以前の review-code Explorer、レビュアー、ワーカーエージェントは終了するか、非アクティブとしてマークしてください。ホストが終了できない場合は、非アクティブまたは置き換え済みとラベル付けします。表示されるエージェント一覧からは、現在のレビュー状態だけが分かるようにし、人が古い実行のエージェントを見分ける必要がないようにしてください。

渡す情報は次のものに限ります。

• リポジトリのパス
• デフォルトブランチ、マージベース、HEAD、変更済み／未追跡のスコープ
• 変更されたファイルの一覧と、関連する差分コマンド
• リポジトリの指示
• この読み取り専用レビュー契約

ホストのランタイムで、新しいレビュアーまたは同等の隔離されたレビュー環境を作成できない場合は、隔離が利用できないことを報告して中止します。現在の実装に関する会話にレビューを行わせてはいけません。

レビュアーモデル

ディスパッチ時にレビュアーモデルを明示的に選択してください。ホストのフレッシュコンテキスト用プリミティブがたまたま既定としているモデルを引き継がないでください。ホストの既定が小規模モデルの場合、このゲートの品質が気づかれないまま低下し、主要な品質管理が損なわれるためです。十分な能力を持つモデルを必須とし、サブエージェントの既定モデルよりも、セッションモデルまたはメインモデルを優先してください。選択方法はホストに依存しないようにします。サブエージェントや Agent の model パラメーター、explorer モデル、CLI の --model フラグなど、ディスパッチ機能が提供する手段を使って設定してください。実際にレビュアーが実行したモデルを記録して報告できるようにし、ホストの UI を確認しなくてもモデルのダウングレードを把握できるようにしてください。

レビュアーの契約

レビュアーは、スコープ対象の差分について、マージに関わるリスクを調査してください。

• 正確性、セキュリティ、データ損失、要件への適合性、エラー処理、テストの品質、エッジケース、本番環境への適合性、明瞭さ、保守性
• 変更された動作に対するテストの不足、または誤解を招くテスト
• リポジトリの指示やイシューの受け入れ基準との不整合

指摘事項は、重大度別にブロッキング、非ブロッキング、低重大度に分類してください。各指摘事項には、ファイルと行番号への参照、理由、修正案を含めてください。称賛に偏ったコメントは報告に含めないでください。指摘事項がない場合は、その旨を明記し、残存リスクやテスト上の不足にも触れてください。

ホスト型レビューとの違い

review-code は、ブランチ差分の指摘を行う、ローカルで分離されたレビュアーです。code-review.yml をエミュレートするものではなく、PR 番号も必要とせず、コメントも投稿しません。ホスト型レビューのワークフローは、それぞれ独自のプロンプト、権限、PR コメント投稿の契約を持ちます。

報告

• 使用したベース、ヘッド、既定ブランチ
• ローカルの既定ブランチ参照の最新性確認、または最新性を確認できなかった理由（例：Freshness unverified: gh unavailable; reviewed current origin/main only）
• ステージ済み、未ステージ、未追跡のファイルを含む変更ファイル
• 新規レビュアーのディスパッチ方法、または停止した理由
• レビューで実際に使用されたレビュアーモデル
• 重大度別に分類した指摘事項
• 重要度の低いパスについて、スキップしたかレビューしたかとその理由