parallel-review

並列コードレビュー

ローカルの差分をすべてのレビュアーに同時に確認してもらい、各自の指摘を統合して、優先順位を付けたリストを作成します。迅速で、ほかのレビュアーの作業内容が見えないため、指摘の独立性も保たれます。

ワークフロー

Step 1: 対象範囲を決める

• ユーザーがファイルを指定した場合は、そのファイルをレビューします。
• それ以外の場合は、git diff HEAD を使って、ステージされていない変更とステージ済みの変更をすべてレビューします。
• ディスパッチの前に比較ベースを固定します。呼び出し元から done のようにマージベースの SHA が渡された場合は、それを使います。それ以外の場合は、gh repo view --json defaultBranchRef からデフォルトブランチを読み取り、git merge-base HEAD origin/<default branch> を解決します。レビュアーは、ベースブランチの挙動と、このブランチの過去のコミットで導入された挙動を区別するためのコンテキストとして使います。これによってレビュー対象範囲が広がることはありません。レビュー対象は常に Step 1 で定めた範囲です。
• 以前の収束成果物が存在する場合は、ディスパッチ前に、現在のベースライン、差分のハッシュ、パス、依頼内容、予定しているレビュアー構成と観点を指定して converge-reviews を呼び出します。変更のない結果は再利用します。continue が返された場合は、指定された無効化対象のレビュー範囲だけをディスパッチします。それ以外の結果が返された場合は、別のレビューラウンドを開始せず、その結果を適用します。

Step 2: レビュアー構成を決めてからディスパッチする

最初にレビュアー構成を決め、その後、Agent ツールを使って全メンバーを並列で起動します。

以下のメンバー1〜3は subagent_type の値であり、そのまま Agent ツールに渡します。メンバー4はスキルを実行するエージェントです。/web-interface-guidelines と /rams はスキルであり、エージェントタイプではないため、subagent_type として指定できません。代わりに、これらを呼び出す general-purpose エージェントをディスパッチします。

レビュアー構成は、決定する前に差分の規模に合わせます。done はすべてのタスクの後にこのスキルを実行するため、構成の規模を調整しないと、1行の修正にも大規模な書き換えと同じコストがかかります。Step 1 の対象範囲は、ファイルが指定されている場合は git diff --shortstat HEAD -- <paths>、指定されていない場合は引数なしの git diff --shortstat HEAD で計測します。

• 1ファイルで変更行数がおよそ50行未満の場合、またはユーザーが簡易レビューを依頼した場合は、構成を pr-review-toolkit:code-reviewer のみにして、このステップの残りは適用しません。
• それ以外の場合は、以下のメンバーから構成を作成します。

常に構成に含めるメンバー：

1. Code Review Agent。subagent_type: "pr-review-toolkit:code-reviewer" を指定します。
2. CodeRabbit Review Agent。subagent_type: "coderabbit:code-reviewer" を指定します。

次の条件に該当する場合は、構成に追加します。

3. Silent Failure Hunter。subagent_type: "pr-review-toolkit:silent-failure-hunter" を指定します。差分にエラー処理、try-catch、またはフォールバックロジックが含まれる場合に追加します。
4. UI Review Agent。subagent_type: "general-purpose" を指定します。差分にフロントエンドコードまたは UI コードが含まれる場合に追加します。差分を対象に /web-interface-guidelines と /rams を呼び出し、それらの指摘を統合して返すよう指示します。

全エージェント共通のプロンプトに、エージェントごとの観点を加えた指示は次のとおりです。「変更された以下のファイルについて、バグ、ロジックエラー、およびプロジェクトの CLAUDE.md の規約への準拠をレビューしてください：[files]。レビュー対象は [scope diff command] のみで、Step 1 の対象範囲または修正差分です。比較ベースである [merge-base SHA] は、プロダクトの意図を確認する場合に限ったコンテキストです。ベースブランチの内容は git show [merge-base SHA]:<file> で確認してください。」

すべてのレビュアーに、プロダクトの意図に関する指示も適用します。指摘への修正によって、ベースブランチ（このブランチの過去のコミットではなく、固定したマージベース時点）にすでに存在する外部から観察可能な挙動が変わる場合、レビュアーはその指摘に product-intent タグを付け、確認した内容を報告します。報告内容には、現在の挙動をテストがアサートしているかどうか、コメントやドキュメントで説明されているかどうか、git blame または git log -S で特定した導入コミットを含めます（何も見つからなかった場合は「見つからなかった」と明記します）。タグ付きの指摘は実際の重大度で報告し、修正はしません。

ディスパッチの前にレビュアー構成を明示します。Step 3 では、この構成をチェックリストとして統合します。

ステップ 3：マージ

レビュアーが名簿に残っている間は、マージを行いません。報告済みか、失敗して再割り当て済みかを含め、全メンバーを名前で把握します。

1. すべての指摘をマージし、レビュアー間の重複をまとめます。いずれかの元の指摘に付いた product-intent タグは、重複をまとめた後も維持し、その根拠もマージ後の指摘に引き継ぎます。
2. マージ後の各指摘に、ファイル、包含するシンボル、正規化した欠陥クラス、欠陥インスタンスのフィンガープリントから安定した ID を割り当てます。フィンガープリントは、呼び出し先、アクセスされるフィールド、分岐ラベル、データフローの端点など、最小の安定した意味上のコードアンカーと、違反された不変条件から導出します。2 つの欠陥が同じアンカーを共有する場合は、最も近い、異なる意味上の親またはオペランドを加えて拡張します。付随的な書式、リテラル、レビュアーの表現は正規化し、生の行番号は除外します。4 つの要素すべてが一致する場合にのみマージし、すべての元のレビュアーを保持します。これらの ID とその処置の管理は呼び出し元が担います。共有の指摘 ID 管理者は作成しません。
3. 優先度を、Critical > Serious > Moderate > Minor の順に付け、追跡可能なリストを 1 つ提示します。product-intent タグは重要度に付随し、重要度を下げることはありません。このタグには拘束力があります。ユーザーの承認なしに、エージェントがタグ付きの指摘を修正することはできません。また、リストを引き継ぐ際に、エージェントがその指摘を削除したり、優先度を下げたりすることもできません。
4. converge-reviews を呼び出し、元の依頼、ローカルベースラインと現在の diff ハッシュ、レビュー対象パス、レビュアーの名簿と観点、マージ後の指摘、処置、以前の収束アーティファクトを渡します。その結果の契約を適用し、優先度順のリストと収束結果を呼び出し元に返します。