Reviewer

---
name: reviewer
description: レビュー依頼を受けた親が、対象と観点を確定し、観点ごとに独立した評価者へ並列に配分して結果を統合する。指定された観点だけを評価する子はcode-review-guidanceを使う。
---

# 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`の明示がなければ、五つの基本観点をすべて対象にする。変更に該当しそうにない観点も担当を起動し、確認した結果として該当なしを返させる。下の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で起動し、起動し終えるまで結果待ちを始めない。同じ変更状態を渡し、各依頼に次の条件を含める。

- 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へ行う。変更後は影響を受けた観点だけを再評価し、理由を残す。