code-review

コードレビュー

ユーザーが指定した固定点を基準に、差分を次の観点からレビューします。

• 標準 — 承認済みのエンジニアリング／アーキテクチャのガイダンスと、リポジトリの標準。
• 仕様 — エピックの文脈における、選択されたバックログ項目の意図された変更と受け入れ基準。

デフォルトでは、両方をまとめてレビューするレビュー担当者を使用します。セキュリティ／認証、破壊的な移行、または現実的なデータ損失のリスク、公開 API との互換性に該当する場合に限り、標準と仕様をそれぞれ独立して並行レビューします。wiki は承認済みの現状であり、バックログは目指す変更です。

分割レビューが適用される場合は、読み取り専用の判断ユニットを 2 つ用意して $parallel-execution を呼び出します。このコンテキストは、権限の解決、結果の統合、指摘事項、引き継ぎを担います。統合レビューでは、共有スケジューラを読み込まず、レビュー担当者 1 人を使用します。

深さ 1 の暫定ワーカーの下では、新たなワーカーを起動しないでください。選択されたブリーフを 1 つまたは複数、ローカルで実行し、分割レビューの軸を順に処理して、並行処理能力が不足していることを報告します。

手順

1. 固定点を確定する

ユーザーが指定したもの（SHA、ブランチ、タグ、main、HEAD~5 など）を使用します。指定がない場合は確認します。権限の確認に進む前に、git rev-parse --verify <fixed-point>^{commit} と git merge-base <fixed-point> HEAD で解決します。どちらかが失敗した場合は、実行可能な対処法を示して停止します。次の内容を一度だけ取得します。

• 差分：git diff <fixed-point>...HEAD（マージベースに対する三点リーダー形式）
• コミット：git log <fixed-point>..HEAD --oneline
• 変更されたパス：git diff --name-only <fixed-point>...HEAD

差分が空の場合は、その旨を報告して停止します。無効な参照と空の差分はここで処理し、並行レビューの中では処理しません。

2. プロジェクトのガバナンスを確認する

リポジトリのルートを特定し、該当するすべての AGENTS.md、CLAUDE.md、およびネストされた指示を読みます。setup-project のスキャフォールドが存在する場合は、docs/wiki/index.md、docs/wiki/maintenance.md、docs/backlog/index.md、docs/backlog/maintenance.md、および関連性が最も高い wiki とバックログのインデックスも読みます。プロジェクト固有の保守ルールがより厳しい場合は、そのルールを適用します。レビュー中に wiki、バックログ、クレーム、ステータスを変更しないでください。

3. バックログの作業項目を選択する

呼び出し元がエピックスコープのレビューを依頼した場合、エピックを仕様の主要な権威とし、すべての子項目を文脈として扱います。これは通常の包括的なレビュー範囲です。

それ以外の場合は、WORK-NNN を 1 つ選択します。

1. 指定された ID、パス、または完全なレコードを優先します。アクティブなエピックの受け入れ単位に属する暫定的な子項目が指定された場合は無効として呼び出し元に差し戻し、エピック全体をまとめてレビューします。独立した受け入れ単位として呼び出された WORK-NNN は、単独でレビューします。
2. それ以外の場合は、アクティブなレコードから、有効なクレームまたはブランチ／コミットへの完全一致リンクが 1 つだけあるかを確認します。終了済みのレコードと期限切れのクレームは無視します。該当するものがない場合、または複数ある場合は確認します。
3. 単独の項目は、それ自体が包括的なレビュー範囲です。エピックの子項目は暫定のままであり、このレビューによって受け入れ済みになることはありません。

バックログ項目がない場合は、仕様が存在しないことについて明示的な確認を求めてから、標準のみをレビューします。

4. 権威パケットを構成する

呼び出し元のワークフローから解決済みのパケットパスと役割が渡された場合、それらをパケットとして受け入れ、ディレクトリーインデックスから権威ある情報源を再探索しないでください。また、この呼び出しチェーンの今回の実行ですでに呼び出し元が読み取り、新鮮性ルールを適用したコンテンツについては、そのパスを再読み込みしないでください。渡されなかったものだけを探索して読み取ります。

どちらかのサブエージェントを開始する前に、呼び出し元またはここで、以下の権威ある情報源をすべて読み取ってください。

• 選択した作業項目：成果／差分、受け入れ基準、関連性、wiki 参照、調査、決定事項、実行、サブタスク
• parent が none でない場合、その完全な親 Epic：成果、基準、スコープ、除外事項、制約、wiki 参照、調査、実行コンテキスト
• Epic スコープのレビューでは、Epic とすべての子レコード：各差分と基準を子コンテキストとして明示
• 変更に関係する、リンクされた現在の状態の wiki コンセプトすべて（wiki_refs または Epic 経由）、および所有権の確認に必要な最も近いインデックス
• 項目または Epic にある提案固有の調査と、直接リンクされたローカルの根拠資料
• docs/wiki/engineering/ および docs/wiki/architecture/ 配下の承認済みガイダンスと、リポジトリの標準情報源（指示、CONTRIBUTING.md、CODING_STANDARDS.md）
• docs/wiki/engineering/technologies/ および docs/wiki/engineering/standards/ 配下にある、適用可能なガイダンスページすべて。変更差分が影響する技術ごと、および横断的な標準ごとに 1 ページを、これらのディレクトリーインデックスと変更パスから解決します。

各情報源のパスと役割を記録してください。現在の状態を示す wiki の事実はベースラインと制約を記述するものであり、欠けている望ましい差分を補ったり、打ち消したりすることはできません。子項目の差分、基準、除外事項が主要な仕様の権威であり、Epic コンテキストが子スコープを拡張したり置き換えたりすることはありません。Epic スコープのレビューでは、Epic 自体の成果と基準が主要な仕様の権威であり、子スコープはコンテキストです。子のスコープが Epic を拡張することはありません。バックログのスコープによって、リポジトリの標準または承認済み wiki 標準が免除されることはありません。

5. レビューモードを選択する

レビュー対象の差分に、セキュリティ／認証、破壊的な移行または現実的なデータ損失リスク、あるいはパブリック API との互換性が関わる場合に限り、2 人のレビュアーを並行して使用してください。互換性の問題に該当するのは、既存の契約が変更または削除される場合、あるいは別の妥当な利用側への破壊が起こり得る場合です。追加のみのエクスポートでは該当しません。プライバシーに関する文言、通常の永続化、並行処理、ビルド／リリースインフラストラクチャ、ADR の重要性だけでは、レビューを分割する理由になりません。それ以外の場合は、単独のレビュアーが統合レビューを行います。具体的なトリガー、または combined default を記録してください。

6. 規格の権威を確認する

手順 4 で確認した、該当するすべての承認済みエンジニアリング／アーキテクチャ Wiki のガイダンスとリポジトリ標準を適用してください。製品の現状に関する概念とバックログ要件はコンテキストであり、規格のルールではありません。

該当するガイダンスページは、docs/wiki/maintenance.md § Adopted guidance に従って各ルールが持つ強さで、厳格な規格の権威となります。Requirements ルールへの違反は、ページパスとルールを引用する、文書化された標準への違反です。Recommendations からの逸脱は判断事項です。Conventions は文書化された慣行として適用されます。記録済みの Deviations エントリは、そこから逸脱する上流ガイダンスに優先します。Known gaps の領域内で書かれた新しいコードも、引き続きルールに違反します。記録されたインストール済みバージョンがマニフェストと一致しないページは信頼できません。その場合は、バージョン固有のルールを適用せず、古くなっていることを指摘事項として報告してください。

規格には、Wiki が重要性の判定基準を定義している場合、ADR の確認も含まれます。docs/wiki/architecture/decisions/index.md の ADR インデックス、docs/wiki/maintenance.md の重要性の判定基準、および作業項目の decisions フィールドと ## Decisions セクションを確認してください。変更対象パスまたは作成中の決定に関連する場合に限り、適用中の個別 ADR を開いてください。差分によって判定基準を満たす決定がなされているにもかかわらず、それを扱う草案 ADR も、該当する ADR がない理由を説明する none の記録もない場合は、指摘事項として報告してください。また、差分が適用中の ADR と矛盾しているのに、その ADR の supersession が草案として示されていない場合も報告してください。重要性の判定基準は判断事項です。その旨を明記し、ADR の欠落をコードの欠陥として扱ってはいけません。

文書化されたルールに加え、規格にはリファレンス／smell-baseline.md の スメルの基準が含まれます。レビュー担当者は手順 7 でこれを読みます。親は読みません。

7. レビュー担当者を起動する

リファレンス／sub-agent-briefs.mdを読んでください。デフォルトでは、規格と仕様をまとめてレビューする担当者を 1 人起動します。リスクが高く範囲が狭い場合は、包括的なレビューとして、$parallel-execution に規格と仕様の各ユニットを 1 つずつ割り当てます。仕様がない場合は、規格のみを実行します。該当する場合は、エピック向けの追加項目を含めてください。

8. 集約する

Review mode: とその理由を記載してください。## Standards と ## Spec を提示し、各軸の指摘件数と、引用を添えた対応可能な指摘事項を記載してください。エージェントの報告をそのまま転載してはいけません。軸ラベルと件数はそれぞれ独立して記載してください。レビュー担当者が 1 人でも、両方の軸を個別に報告します。

Next step: を追加してください。対応可能な指摘事項がある場合は、一度修正し、修正内容を直接確認して、影響を受けたチェックだけを再実行してから、再レビューを行わずに受け入れユニットの代表スイートのゲートへ進みます。$implement 内で合格した場合は、そのゲートへ進みます。エピックが合格した場合は、アトミックなクローズへ進みます。単独項目が合格した場合は、単一項目の受け入れへ進みます。