code-review

コードレビュー

それぞれ独立したサブエージェントが実行する、2つの独立した観点から差分をレビューします。

• 規約 — コードはこのリポジトリで文書化された規約に従い、ベースラインの問題を回避していますか？
• 仕様 — コードは要件を ID ごとに実装していますか？

変更によって一方の観点は通過してもう一方は失敗することがあるため、2つの観点は意図的に分離されています。完璧なコードでも誤ったものをビルドすることがあり、仕様に忠実な実装でもリポジトリの規約を踏みにじることがあります。レポートを統合すると、一方の観点がもう一方を覆い隠す可能性があります。

1. 範囲を固定する — 早期に失敗させる

呼び出し元から指定されたベース参照（sha、ブランチ、タグ、またはマージベース）を受け取ります。これが解決できることを確認し（git rev-parse <base>）、git diff <base>...HEAD が空でないことを確認します。不正な参照や空の差分は、2つの並列サブエージェントの内部ではなく、ここで失敗させる必要があります。また、git log <base>..HEAD --oneline も取得します。ベースが指定されていない場合は、ユーザーに尋ねます。完了条件：参照が解決でき、差分が空でないこと。

2. 仕様を特定する

適用される要件を次の順で探します。

1. コミット内の要件 ID トレーラー（Implements:、Guards:）— 機能コードから docs/specs/INDEX.md を介して仕様フォルダーを特定します。
2. ブランチ名または機能名に一致する docs/specs/<date>-<feature>/requirements.md。
3. 呼び出し元から指定されたパス。
4. それ以外の場合はユーザーに尋ねます。仕様が存在しないことをユーザーが確認した場合は、Spec 観点を省略し、最終レポートでその旨を伝えます。

完了条件：requirements.md のパス、または明示的な「仕様なし」が得られていること。

3. 規約の情報源を収集する

このリポジトリでコードをどのように記述すべきかを定めている文書を集めます。CLAUDE.md、リンターとフォーマッターの設定、CONTRIBUTING 形式の文書、およびリポジトリの標準的な用語を定める CONTEXT.md が該当します。docs/agents/project.md がない場合は、その旨を記録し、setup-repo の実行を提案してから、存在する情報源を使って続行します。## Team があり、空でない roster またはバンドの上書き設定がある場合は、そのセクションから band と packaging を読み取ります。2軸レビューは常に実施します。Solo ではレポートを単独の作者に向け、Small/Multi では、存在する場合は ownership notes を使ってパスの所有権を重視します。Team がない場合は、機能着手前のデフォルトを適用します。

リポジトリ固有の文書に加えて、規約の観点では、このファイルと同じ場所にある standards-baseline.md を常に適用します。そこには、リポジトリに何も文書化されていない場合でも適用される12のコード品質上の問題と、差分が信頼境界を越える場合に適用される Security セクションがあります。次の2つのルールが適用されます。文書化されたリポジトリ規約は常にベースラインより優先されます。また、ベースラインへの該当はすべて、絶対的な違反ではなく、判断を要する項目として明示します。ツールによってすでに検査されている内容は省略します。レビュー担当者がリンターの判定を繰り返すのはノイズです。完了条件：情報源の一覧とベースラインのパスが揃っていること。

3a. 既存機能との重複を確認する

差分で変更されたソースファイル（ステップ1で固定した範囲から取得）について、すでにそのパスを指定している仕様を docs/specs/ から検索します。design.md／tasks.md に対して grep -rl <changed-file> docs/specs を実行し、さらに requirements.md 全体から差分の主要な概念を検索します。一致するものがあれば読み込み、要約カード（機能コード、所有パス、Out-of-Scope）として保持します。まず docs/specs/INDEX.md をレジストリとして確認します。この手順がレビューを妨げることはありません。変更されたファイルがどの仕様にも記載されていない場合は、既存機能と差分の対象範囲が重複していないことを明記し、ステップ4には何も追加しません。docs/specs/ が存在しない場合は、その旨を記録して続行します。完了条件：重複する機能のカード、または明示的な「重複なし」が揃っていること。

3b. 不変条件への準拠（参考情報）

docs/architecture/ が存在する場合は、必須のサブスキルとして check-invariants を差分に対して使用します。これは Respects: ARCH-N ごとに（準拠／違反／不明）の判定を返します。違反または不明の判定をステップ5まで保持します。この確認経路は設計上、参考情報として扱われ、2つの必須観点には含まれません。マージを妨げる要因になることはありません。docs/architecture/ が存在しない場合は、このステップを省略し、何も追加しません。完了条件：不変条件の判定、または明示的な「アーキテクチャ情報なし」が揃っていること。

4. 両方のサブエージェントを並行してディスパッチする

両方のディスパッチを含むメッセージを1つ送信し、並行して実行されるようにします。互いのコンテキストを汚染しないようにしてください。どちらも読み取り専用です。作業ツリー、インデックス、HEAD、ブランチの状態を変更してはいけません。別のリビジョンを調べる場合は、一時的なワークツリー（git worktree add <tmpdir> <sha>）を使用し、HEAD を移動させないでください。各ブリーフは400語未満にしてください。ディスパッチで調査結果を先回りして判断してはいけません。「指摘しないで」や、あらかじめ重大度を評価する記述は禁止です。

Standards サブエージェントに渡すもの：diff コマンドとコミット一覧、標準ドキュメントのパス、standards-baseline.md のパス。このファイルを必ず最初に読み、12項目のスメルを1つずつ diff と照合させてください。また、信頼境界（信頼できない入力、シークレットの扱い、特権アクション）を越えるハンクがあれば、Security セクションも確認させます。ブリーフでは、次を報告させてください。（a）diff が文書化された標準に違反している箇所すべて。該当する文書とルールを明記する。（b）ベースラインの12項目のスメルそれぞれについて、見つかった該当箇所すべて。スメルの名称と該当ハンクを引用する。（c）diff が引き起こす Security セクションのセキュリティ上の懸念すべて。項目名と、越えている信頼境界を明記する。文書化された違反は重大な指摘となる場合がありますが、ベースラインのスメルとセキュリティ項目は常に判断を要するものです。リポジトリのドキュメントはベースラインに優先します。ツールで強制される項目は除外してください。CONTEXT.md の用語のずれも含めてください（用語集の概念を別の名前にしたり、別の用語に置き換えたりする diff は指摘対象です）。

Spec サブエージェントに渡すもの：diff コマンドとコミット一覧、requirements.md のパス。ブリーフでは、要件を確認し、次を報告させてください。（a）不足している ID、または一部しか実装されていない ID。（b）要件で求められていない diff 内の動作（スコープの逸脱）。（c）実装済みに見えるものの、誤っている ID。すべての指摘に要件 ID を引用させてください。また、docs/agents/project.md の規約に従い、対象となる各 ID にタグ付きテストがあることを確認させ、タグのないテストも指摘させてください。ステップ3aで機能の重複が見つかった場合は、Spec サブエージェントにも該当する近隣カード（所有パスと Out-of-Scope）をコンテキストとして渡し、共有サーフェスを持つ近隣機能がすでに所有している動作を diff が再実装している箇所を、その近隣機能コードを引用した 再利用漏れ の指摘として報告するよう指示してください。

完了条件：両方の報告がそろっていること。

5. 集約

報告を ## Standards と ## Spec の見出しの下に提示します。必要最小限の体裁調整にとどめてください。評価軸をまたいで指摘を統合・重複排除したり、一方の評価軸の指摘を他方と比較して順位付けしたりしてはいけません。軸を分離する目的は、まさにそのような順位付けを防ぐことです。ステップ3bで不変条件の判定が出た場合は、独立した第3の枠として、## Invariants (advisory) の下に提示してください。Standards／Spec と統合したり、これらと比較して順位付けしたりしてはいけません。

各指摘には、重大度（Critical / Important / Minor）、ファイルと行番号、重要である理由、明らかでない場合は修正案を含めてください。

最後に、判定を記載します。

Ready to merge? Yes | No | With fixes
[1–2 sentences of technical reasoning]

完了条件：両方の評価軸のセクションと判定が提示されていること。

インラインでの代替手順（サブエージェント機能がない場合）

この実行環境にサブエージェント機能がない場合は、2つの評価軸を自分で順番に確認し、1つのコンテキスト内で実施します。まず Standards を確認します。standards-baseline.md を読み、diff を12項目のスメルそれぞれと Security セクションに照らして確認してください。続いて Spec を確認し、要件 ID を1つずつ確認します。次の評価軸に進む前に、1つの評価軸の確認と記録を完全に終えてください。順位付けせずに、引き続き ## Standards と ## Spec の別々の見出しの下に提示します。2つのサブエージェントが提供するコンテキスト分離はできません。そのため、一方の評価軸を完了させてから次に取りかかることが、両者を混同しないための要点です。