review-all

Review All - 2 つのクリーンエージェントによるコードレビュー

この機能の内容と、この形式を採用している理由

2 人の独立したレビュアーが同じ変更を調べ、その後、指摘事項を照合します。価値があるのは「2 つのレビュー」ではなく、合意のシグナルです。両方のクリーンエージェントが独立して同じ問題を指摘した場合、確信度は高くなります。一方だけが指摘した場合は、精査する価値があります。

このシグナルを有効にする 4 つの特性があり、手順はその維持を目的としています。

1. 各レビュアーにクリーンなコンテキストを用意する。 各レビュアーは、このオーケストレーションや互いについての記憶がない状態で、まっさらな状態から開始する必要があります。そうでなければ、独立性が失われます。クリーンなコンテキストで 2 つのエージェントを起動してください。エージェント API が fork_context フラグに対応している場合は、false に設定してください。どちらのレビュアーの出力も、もう一方に貼り付けないでください。
2. 同じ対象をレビューする。 両方がまったく同じ差分を確認していなければ、合意に意味はありません。対象を一度だけ解決し、同一の base...HEAD 範囲を両方に渡してください。
3. 相互補完的な 2 つのレビュー経路を用いる。 一方のクリーンエージェントは、Codex ネイティブの codex review --base "$base" コマンドを実行します。もう一方のクリーンエージェントは、Google の「コードレビューで確認すべきこと」に基づく references/review-guide.md を使用して、直接レビューを行います。 https://google.github.io/eng-practices/review/reviewer/looking-for.html
4. 実際に並行して実行する。 どちらかの結果を待つ前に、両方のエージェントを起動してください。レビューを逐次実行しないでください。

このスキルはレビュー専用です。--fix / --comment を渡したり、パッチを適用したり、コードを変更する予定だとユーザーに伝えたりしてはいけません。

PR を完了させるための反復ではありません

このスキルは、一括修正の後に 1 回実行してください。有効な P0～P2 の指摘事項が残っている場合に限り、2 回目の一括修正後にもう 1 回実行できます。個々の修正ごとに review-all を再実行しないでください。

手順

ステップ 1 — 共通の対象を解決する（ベース 1 つ、範囲 1 つ）

対象は base...HEAD（現在のブランチのマージベース差分）です。これにより、両方のレビュアーがこのブランチで追加されたコミットを正確に確認できます。

current=$(git rev-parse --abbrev-ref HEAD)

# Base precedence: user-provided --base > origin's default branch > main > master
base="$ARG_BASE"   # whatever the user passed, may be empty
if [ -z "$base" ]; then
  base=$(git symbolic-ref --quiet refs/remotes/origin/HEAD 2>/dev/null \
         | sed 's@^refs/remotes/origin/@@')
fi
[ -z "$base" ] && git show-ref --verify --quiet refs/heads/main   && base=main
[ -z "$base" ] && git show-ref --verify --quiet refs/heads/master && base=master

echo "current=$current base=$base"
git diff --shortstat "$base"...HEAD
git diff --name-only "$base"...HEAD

ステップ 2 — 事前確認（問題があればすぐに終了し、レビューを無駄にしない）

以下のいずれかに該当する場合は停止し、ユーザーにはっきり伝えてください。

• git リポジトリ内ではありません。
• ベースブランチを解決できない場合 → どのベースとの差分を確認するか、ユーザーに尋ねてください。
• current がベースブランチの場合 → 比較対象がありません。ベースを指定するようユーザーに尋ねてください。
• 差分が空の場合（git diff --shortstat "$base"...HEAD の出力がない場合）→ レビュー対象となるコミット済みの変更がありません。このモードではコミット済みの変更だけをレビューすることをユーザーに伝えてください。作業が未コミットの場合は、先にコミットする必要があります。
• Codex を使用できる状態ではない場合：codex login status でログイン済みアカウントが確認できない場合。ユーザーにその旨を伝え、Google の評価基準を使ったレビューのみを実行するか提案してください。

ステップ 3 — 両方のクリーンなエージェントを並行して起動する

現在の環境で利用可能なエージェント／サブエージェント機能を使用します。両方のレビューエージェントを起動してから、結果を待ってください。API が fork_context を公開している場合は、各エージェントで false に設定してください。各エージェントには、リポジトリのパス、解決済みのベース、およびタスクのみを渡します。

エージェント A：Codex レビューコマンドエージェント

タスクプロンプト：

クリーンなコンテキストでレビューコマンドを実行してください。<repo path> にあるリポジトリで、コミット済みブランチの差分に対して Codex のネイティブレビューコマンドを実行してください。

codex review --base <base>

これはレビューのみです。--fix や --comment は渡さず、GitHub に何も投稿せず、ファイルも変更しないでください。ネイティブコマンドの出力と、可能であれば次の形式の正規化された JSON 配列で指摘事項を返してください。 {"file":"...","line":<int or null>,"priority":"P0|P1|P2|P3","category":"design|functionality|complexity|tests|naming|comments|consistency|documentation|security|other","title":"<one line>","description":"<evidence and impact>"} コマンドで何も見つからなかった場合は、出力の概要の後に [] を返してください。コマンドが失敗した場合は、正確なエラーを返して終了してください。

エージェント B：Google の基準によるレビューエージェント

この SKILL.md の隣にある references/review-guide.md を読み込み、その後、ルーブリック全文を貼り付けたうえで、次のタスクをエージェントに渡してください。

クリーンなコンテキストを持つ独立したコードレビュアーとして、<repo path> にあるリポジトリの、コミット済み変更 git diff <base>...HEAD のみをレビューしてください。Google の「コードレビューで確認すべきこと」に基づく次のレビュー基準を適用してください。

<references/review-guide.md の全文をここに貼り付ける>

制約：これはレビューのみです。--comment や --fix は渡さず、GitHub に何も投稿せず、ファイルも変更しないでください。変更行を判断する際の観点としてシステムコンテキストを利用しますが、すべての指摘は差分に根拠を置いてください（変更行、またはテストの欠落など、変更によって対応すべきだった箇所）。リンター、フォーマッター、型チェッカー、コンパイラーで検出できる細かな指摘は省いてください。

指摘事項を JSON 配列のみで返してください。それぞれの指摘は次の形式にします。 {"file": "...", "line": <int or null>, "priority": "P0|P1|P2|P3", "category": "design|functionality|complexity|tests|naming|comments|consistency|documentation|security|other", "title": "<one line>", "description": "<why it's a problem, with evidence>"} priority には、ルーブリックの P0〜P3 の尺度に従って割り当ててください。何も見つからなかった場合は [] を返してください。変更に特筆すべき良い点があれば、priority を P3、category を other、タイトルを「Good: …」とする指摘を 1 件追加してもかまいません。

両方のエージェントを起動した後、それぞれの結果を待ってください。

ステップ 4 — 両方の結果を収集する

• Google の基準によるレビューエージェントの JSON を待ちます。
• Codex レビューコマンドエージェントの生出力および／または正規化された JSON を待ちます。 Codex のネイティブ出力は意味に基づいて解析してください。厳密な正規表現には頼らないでください。ネイティブレビュアーの出力は、しばしば次のような形式です。
  • 前置きのブロック（Codex のバージョン、作業ディレクトリ、モデル、差分のダンプ、実行したシェルコマンド）— すべて無視してください。
  • 指摘事項は codex マーカーの後に、概要の行、続いて Full review comments: とエントリーのリストが表示されます。各エントリーは - [P2] <title> — <path>:<start>-<end> の形式で、その下に説明の段落が続きます。各エントリーが 1 件の指摘です。
  • 指摘事項のブロックは（ストリーミング表示と最終メッセージで）2 回出力されることがよくあります。重複を除いてください。同じ指摘事項であり、新たな指摘ではありません。
  • Codex は各指摘に [P0]〜[P3] のラベルを付けています。Google の基準によるレビュアーと同じ尺度なので、ラベルはそのまま維持し、再割り当てしないでください。
  • 無害な git: warning: confstr()／xcrun_db の行は読み取り専用サンドボックスに由来するため、無視してください。

片方の結果が得られなかった場合（Codex がエラーになった、エージェントから有効な内容が返らなかったなど）も、得られた結果で続行し、レポートでその旨を明示してください。何も知らせないより、片方だけのレビューであることを明記するほうが適切です。

ステップ 5 — 統合、重複排除、順位付け

両方の結果を同じ指摘形式に正規化してから、照合します。

• 同じファイル、重複または隣接する行、同じ根本的な問題に該当するものを重複排除します （文字列の一致ではなく、意味上の一致で判断します。2 つのエージェントは異なる表現を使います）。
• すべての指摘に出所をタグ付けします：both、google、codex。
• 統合した各指摘の優先度を決定します。両方のレビュアーが指摘していて優先度が異なる場合は、より高い（より深刻な）優先度を採用し、差異を記載します。
• 主に優先度（P0 → P3）に基づいて順位付けします。同じ優先度内では、両方のエージェントが同意した指摘を先に示します。独立した合意は、このスキルが生み出す最も強い信頼性のシグナルです。
• 意見の相違は隠さずに示します。ある点がバグかどうかについて 2 つのエージェントの見解が食い違う場合は、双方の立場を簡潔に記載します。その食い違いこそ、レポートの最も有益な部分であることも少なくありません。

ステップ 6 — 統合レポートを提示

まず判定を示し、次に優先度の概要表を掲載し、その後、優先度ごとに指摘をまとめます。すべての指摘に、優先度、出所（both／google／codex）、ルーブリックの評価項目をタグ付けします。

## Review-all: <current> vs <base>  (<N> files, +<adds>/-<dels>)

**Verdict:** APPROVE / REQUEST CHANGES / COMMENT
**Overall correctness:** patch is correct / patch is incorrect
Codex review and Google-rubric review examined the same diff independently; <X>
findings agreed.

### Findings overview
| Priority | Count | Where | Summary |
| -------- | ----- | ----- | ------- |
| P0 | <n> | <file:line or —> | <short or "none"> |
| P1 | <n> | … | … |
| P2 | <n> | … | … |
| P3 | <n> | … | … |

### P0      ← show only tiers that have findings
1. [P0] **<title>** — `file:line` · _both_ · functionality
   <merged description>

### P1
...

### P2
...

### P3
...

判定は優先度から導きます（kelos レビュアーと同じロジックです）。

• 全体的な正確性は、P0 または P1 の指摘が 1 つでもあれば「パッチは不正確」、それ以外は「パッチは正確」です。この判定では P2／P3 の軽微な指摘は無視します。
• P0／P1 がある場合は REQUEST CHANGES、P2／P3 のみ（または指摘なし）の場合は APPROVE、判断する前に作者の意見を本当に確認する必要がある場合は COMMENT とします。

簡潔にまとめます。絵文字は使わず、file:line 形式で該当箇所を示し、合意した指摘（both）は最高の信頼性を示すものとして明確に記載します。また、単一モデルのみの指摘を合意のように見せるために水増ししないでください。両方のエージェントが何も見つけなかった場合は、その旨を伝えて終了します。注目すべき長所があれば、最も低い優先度のセクションの下に「Good:」という一行の注記を付けてもかまいません。事実に即した記述とし、お世辞は避けてください。

注意事項と例外

• コミット済みの変更のみが対象です。 codex review --base と base...HEAD はどちらも、未コミットまたは未追跡のファイルを対象にしません。ユーザーがそれらのレビューを希望する場合は、先にコミットする必要があります（将来的に --working-tree モードで対応できる可能性があります）。
• 差分が大きい場合。 Codex の処理には時間がかかることがあります。それが専用のクリーンなエージェントで実行する理由です。早めに終了させないでください。
• 引数。 任意でベースを上書きする引数を受け付けます（例：review-all --base develop または review-all develop）。指定がない場合は、ステップ 1 に従って自動的に解決します。
• 二重レビューを避けます。 両方のレビュアーには同一の範囲をレビューさせます。一方だけが作業ツリーを対象にし、もう一方がブランチを対象にするようなずれを決して発生させないでください。