review

レビュー

HEAD と固定点との差分を、複数の軸からレビューします。デフォルトの固定点は PR のターゲットブランチです（手順 1 を参照）。各軸はそれぞれ並列のサブエージェントとして実行されるため、互いのコンテキストに影響しません。検出事項は誤検出がないか確認したうえで、軸を統合せずに集約します。ユーザーは各軸を個別に評価できます。

4 つの軸は次のとおりです。

• 規約 — コードはリポジトリに記載された規約に従っていますか？また、その規約自体は妥当ですか、それとも指摘すべき技術的負債がありますか？
• 仕様 — コードは元となるチケットや仕様を忠実に実装していますか？
• アーキテクチャ — 変更されたコードに、より深く改善できる機会はありますか？（/improve-codebase-architecture の観点）
• 代替案 — 変更ごとに、PR の範囲を踏まえたうえで、これは代替案の中で最善の選択でしたか？

プロセス

1. 固定点を決める

固定点はPR のターゲットブランチ、つまり今回の作業がマージされるブランチです。質問せずに解決してください。

• ブランチに PR がある場合は、そのベースを読み取ります：gh pr view --json baseRefName -q .baseRefName。
• PR がない場合は、リポジトリのデフォルトブランチに切り替えます：gh repo view --json defaultBranchRef -q .defaultBranchRef.name（通常は main）。
• ユーザーが別の固定点（コミット SHA、タグ、HEAD~5 など）を明示的に指定した場合に限り、それをそのまま使用します。

差分コマンドを一度だけ記録します：git diff <fixed-point>...HEAD（3 点ドットで、マージベースとの比較）。この差分をレビューします。git log <fixed-point>..HEAD --oneline でコミット一覧も記録します。これは変更の理解や仕様の特定に役立つコンテキストであり、レビュー対象ではありません。レビュー対象は差分内のコードに限られ、コミットメッセージ、PR のタイトルや説明、ブランチ名は含みません。

2. 仕様の参照元を特定する

元となる仕様を、次の順に探します。

1. コミットメッセージ内のチケット参照（#123、Closes #45 など）。プロジェクトのチケット管理システムから取得します。
2. ユーザーが引数として指定したパス。
3. ブランチまたは機能に該当する docs/、specs/、.scratch/ 配下の仕様ファイル。
4. 何も見つからない場合は質問します。仕様がない場合は、仕様軸をスキップし、「利用可能な仕様なし」と報告します。

3. 規約の参照元を特定する

コードの書き方を定めている文書が対象です：CLAUDE.md、AGENTS.md、CONTRIBUTING.md、CONTEXT.md／CONTEXT-MAP.md、docs/adr/、STYLE.md／STANDARDS.md、設定ファイル（eslint.config.*、biome.json、tsconfig.json — 記録しますが、ツールで強制される内容は再確認しません）。ファイル一覧をまとめ、規約サブエージェントが読み取ります。コミットメッセージや PR の規約を定める文書（例：commit-style.md）は対象外です。レビュー対象はコードに限られます。

4. トリアージしてから、軸ごとのサブエージェントを並列で起動する

まずトリアージします（数式は使わず、1つの判断を行います）。実質的に検討すべきことがありますか？

• 明らかに表面的な変更のみ（ドキュメント／コメント／フォーマットのみ、バージョンの更新、生成ファイルの変更など）→ Standards + Spec のみを実行し、Architecture と Divergent は省略します。省略したことを記録してください。
• 明らかに自動処理による変更、または実質的な変更がないもの（例：CIですでにゲートされている dependabot の更新）→ レビューを省略し、「レビューすべき実質的な変更はありません」と1行で記載します。
• それ以外、または少しでも判断に迷う場合 → 4つすべてを実行します。実行する軸は多めにする方針です。1行の変更でも重要な意味を持つことがあります（セキュリティチェックの微調整は、まさに isV4 の例です）。明らかに表面的な変更のみの場合に限り、軸を省略してください。

次に、該当する軸ごとに Agent を1回ずつ呼び出し、単一のメッセージを送信します（すべて general-purpose サブエージェントを使用します）。自分で diff やドキュメントを読んではいけません。簡潔なディスパッチャーに徹してください。各サブエージェントには、それぞれのブリーフファイルを読んで、その指示に従うよう伝えます。渡すのは diff コマンド、コミット一覧（背景情報のみ。レビュー対象ではありません）、必要なソースパスのみです。

• Standards → axes/standards.md（＋ステップ 3 で取得した標準のソースパス）
• Spec → axes/spec.md（＋仕様パス）。仕様がない場合は省略し、レポートにその旨を記載します
• Architecture → axes/architecture.md
• Divergent → axes/divergent.md

各ブリーフは共通の指摘事項契約（axes/_contract.md）に従います。上限は約400語で、各指摘には軸に応じた判定（正しさを扱う軸では確信度スコア、Architecture／Divergent では推論が成り立つかどうかの判断）と根拠が含まれます。これにより、ステップ 5 のフィルターに必要な情報が揃います。

5. 誤検出がないか各指摘を検証する

軸エージェントが返した指摘を集め、集約する前に FILTER.md のゲートに通します。正しさを扱う軸（Standards／Spec）では指摘ごとに独立して検証し、ファイルと行番号で重複排除したうえで、軸ごとに判定して残りを除外します。判断を行う軸（Architecture／Divergent）には検証役はありません。ゲートは軸のブリーフに定められているため、オーケストレーターはそのまま受け取り、重複排除と常時除外リストの適用のみを行います。このゲートがあることで、自律的な投稿を安全に行えます。作者に否定される指摘は、細かな指摘を見逃すよりも信頼を損ないます。判定方法、基準、しきい値、常時除外リストについては FILTER.md を唯一の参照元とし、ここで再解釈せず、その指示に従ってください。

6. 集約する

残った指摘を、各軸の見出し（## Standards、## Spec、## Architecture、## Divergent）の下に、軽く整えて提示します。軸をまたいで指摘を統合したり、順位を付け直したりしてはいけません。軸を分けて提示することが重要です（ステップ 5 でのファイルと行番号による重複排除のみ、軸をまたぐ統合です）。最後に、軸ごとに残った指摘数、最も重大な問題1件、しきい値未満として除外された指摘数を1行でまとめます（黙って切り捨てないでください）。

7. （任意）PRコメントとして投稿する

ユーザーから投稿を依頼された場合に限ります。すべての指摘をインラインにしたレビューを、一括で投稿します。残った指摘はすべて該当する行に紐づけ、紐づけのない gh pr comment は使用しません。指摘が残らなかった場合は、その旨を伝え、細かな指摘を捏造しないでください。 このツールですでにPRをレビューしている場合は、再投稿せず差分のみを投稿してください。 クローズ済み、マージ済み、ドラフトのPRはスキップします。判定方法、確信度の表示、複数箇所にまたがる指摘の扱い、形式、ラベル、AIに関する免責事項、指摘がない場合の処理、再レビューのロジックについては、ここで再解釈せず COMMENTS.md を参照してください。

軸を分ける理由

変更は、ある軸では問題なくても、別の軸では問題がある場合があります。

• すべての標準に従っていても、実装内容が間違っている → Standards は合格、Spec は不合格。
• チケットの要求どおりでも、規約に反している → Spec は合格、Standards は不合格。
• 正しく、規約にも沿っているものの、モジュールの設計が浅い、または代替案より悪い選択になっている → Architecture／Divergent でのみ検出されます。

別々に報告することで、ある軸の結果が別の軸を覆い隠すのを防ぎます。