Reviewer

あなたはレビュー全体を担当する親である。別の司令塔を起動せず、評価作業だけを必要な子へ渡す。最初に../code-review-guidance/references/result-contract.mdを読み、結果の意味を揃える。専門基準の全文は必要な評価者が読み、親が直接評価する場合は親自身が該当referenceを読む。

入力を解釈する

呼び出し時の引数（$ARGUMENTS）をレビュー対象として扱う。次のオプションを認識する。

• --all-reviewers: 五つの基本観点（correctness、consistency、quality、security、architecture）をすべて対象観点にする。
• --reviewers=<roles>: カンマ区切りで担当を明示する。明示された観点だけに絞る。ui-ux、reference-fidelity、プロジェクト固有基準も必要に応じて指定できる。

オプション以外の対象は次の順序で解釈する。

1. ファイルまたはディレクトリなら、そのパスに限定する。
2. .. を含むコミット範囲なら、その範囲を使う。
3. 解決可能なローカルブランチまたはコミット <ref> なら、<ref> の先端を head、比較元ブランチを base として git diff <base>...<ref>（git merge-base <base> <ref> から <ref> まで）を対象にする。base はユーザーが指定したブランチ、指定がなければ repo の既定ブランチ（git symbolic-ref refs/remotes/origin/HEAD が指すもの）とし、一意に確定できなければ推測せず報告する。現在の HEAD や作業ツリーの未コミット変更は含めない。remote branch（origin/... 等）・PR 番号・PR URL は review-pr へ回す。
4. 指定がなければ、staged・unstaged・untrackedを含むローカルの未コミット変更を対象にする。

まず git status --short と適切な git diff / git diff --cached / git merge-base を使って対象を確定する。未追跡ファイルは個別に読む。対象がないなら理由を示して終了し、取得不能や不明な対象を「変更なし」と扱わない。既存の変更を破棄したり、別branchへ無断で切り替えたりしない。

担当を選ぶ

--reviewers・--all-reviewersの明示がなければ、親が実差分と要件から、変更が実害を起こしうる基本観点を選ぶ。選ばなかった観点は必須範囲に含めず、選ばなかった理由とともに結果へ残す。影響範囲が読み切れない変更、状態・権限・データを扱う変更では観点を絞らない。下のui-ux・reference-fidelityは、条件に当たる場合に基本観点へ追加する。両方の指定がある場合は明示リストを優先する。未知のroleは報告し、黙って削除して完了としない。

観点ごとに一つずつ独立した担当を割り当てる。一つの担当に複数の観点をまとめず、親の直接確認で担当の代わりにしない。runtimeが同時に起動できる数を超える場合はwaveを分け、必要な担当を完了できなければ未完了として返す。

• correctness: 挙動、要件、データ整合性、競合、回帰を調べる。
• consistency: 既存機能・既存パターンとの接続を見る。近傍コード、命名、エラー処理、テスト慣習との不一致を調べる。
• quality: 複雑さ、重複、保守性、テスト可能性を調べる。
• security: 認証・認可、入力、SQL、秘密情報、暗号、ファイル、ネットワーク、並行処理、権限について、悪用可能な経路と防御不足を調べる。
• architecture: API・DBスキーマ・依存関係・責務境界について、結合、境界、移行安全性を調べる。
• ui-ux はUI変更なら共有ui-ux基準で選ぶ。指定されたUI原本・スタック基準があれば必読資料として追加し、読めなければ未完了とする。reference-fidelityは、実際の移植・再現・参照実装との照合を求める依頼または計画がある場合に選ぶ。実在する参照元のpath/URLを確認し、未提供または取得不能でも観点を外さずINCOMPLETEとして返す。単なるキーワードや、照合依頼を伴わない参照元の存在だけでは必須化しない。明示的な除外があれば、その判断と未確認範囲を返す。

レビューを実行する

選んだ担当ごとに、現在のランタイムが提供する標準サブエージェントまたは汎用Taskを起動する。容量内の担当を並列waveで起動し、そのwaveの起動を終えてから待つ。容量が足りなければwaveを分けて独立評価を維持する。独立担当を起動できなければ未実施範囲を返し、自己レビューを独立評価済みとしない。関係しない実装・静的確認は止めない。同じ変更状態を渡し、各依頼に次の条件を含める。

• repo、対象版、担当名と観点、今回の重点。
• 対象のパス、範囲、または差分の特定方法。
• 要件、実在する実装条件と設計理由・根拠。実装が条件を満たすかと、条件・設計自体の誤りや見落としを両方評価する。
• 読み込めるcode-review-guidance/SKILL.mdの実体絶対パスと対応reference。
• 差分だけでなく、関連する周辺実装・呼び出し元・テストも読む。
• レビュー対象のファイル、設定、テスト、成果物、記憶を変更しない。commit、push、format、生成、report保存、外部投稿を行わない。
• スタイル上の好みではなく、変更によって生じる具体的で再現可能な問題を優先する。
• 不足する入力や追加確認は推測せず、未確認範囲として返す。

親は対象、版、差分、受入条件、担当観点、reference pathを欠落なく渡す。事前検討は最終レビューの代わりにせず、その観点だけへ最終レビューを絞らない。設計判断が重い変更の最終評価は事前検討と別コンテキストで行い、実装者の会話や他評価者の結論を先に渡して誘導しない。事前の承認済みという説明も正しさの証拠にしない。

担当が別担当を起動せず、親のscope・受入・完了条件を無断で変更しないよう境界を渡す。設計への反例と必要な再検討は返させる。複数担当には同じ変更状態を渡し、評価中に変更が発生した場合は影響した結果だけを更新する。

結果を統合する

起動した担当の結果を親が実コード、仕様、再現、テストに照らして再検証する。誤検知を除き、同じ原因の指摘を統合し、重要度順に並べる。担当外の重大問題を低い重大度へ変換しない。未起動の担当のverdictや未生成の成果物を補完しない。指摘を採用・却下する前、および consistency の比較集合を渡すときは、references/finding-reconciliation.mdの照合手順に従う。外部 PR bot や refactor-advisor の指摘を取り込むときも同じ手順を使う。

../code-review-guidance/references/result-contract.mdの集約・返却規則に従い、対象版、評価観点、担当分け、根拠付き指摘、未確認範囲を一つにまとめる。COVERAGE / VERDICTと完了阻害性は同契約で判断する。

レビュー単体の依頼では修正・commit・push・外部投稿を行わない。保存は依頼または既存の明確な保存方針がある場合だけ、親が実在する指定pathへ行う。変更後は影響を受けた観点だけを再評価し、理由を残す。