reviewer

Reviewer

ローカルのコード変更を複数観点で読み取り専用レビューし、検証済みの指摘を1つの結果に統合する。

入力を解釈する

$reviewer に続くテキストをレビュー対象として扱う。次のオプションを認識する。

• --all-reviewers: 5つの担当をすべて使う。
• --reviewers=<roles>: カンマ区切りで担当を明示する。使用可能な値は correctness, consistency, quality, security, architecture。

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

1. ファイルまたはディレクトリなら、そのパスに限定する。
2. .. を含むコミット範囲なら、その範囲を使う。
3. 解決可能なブランチまたはコミットなら、マージベースから HEAD までを対象にする。
4. 指定がなければ、追跡済み・未追跡を含むローカルの未コミット変更を対象にする。

まず git status --short と適切な git diff / git diff --cached / git merge-base を使って対象を確定する。未追跡ファイルは個別に読む。変更がなければ、その旨を伝えて終了する。

担当を選ぶ

明示指定があればその担当を使う。明示指定がなければ、変更内容から次を選ぶ。判断が曖昧なら多めに選ぶ。

• correctness は常に選ぶ。仕様違反、境界値、失敗経路、データ整合性、競合、回帰を調べる。
• consistency は既存機能の拡張や既存パターンへの追加で選ぶ。近傍コード、命名、エラー処理、テスト慣習との不一致を調べる。
• quality は新しい関数・型・分岐、または意味のあるロジック変更で選ぶ。複雑さ、重複、保守性、テスト可能性を調べる。
• security は認証・認可、入力、SQL、秘密情報、暗号、ファイル、ネットワーク、並行処理、権限に触れる変更で選ぶ。悪用可能な経路と防御不足を調べる。
• architecture は新規ファイル、複数レイヤー、API・DBスキーマ・依存関係・責務境界に触れる変更で選ぶ。結合、境界、移行安全性を調べる。

並列レビューを実行する

サブエージェントを起動する直前に、次をユーザーへ短く宣言する。

Fan-Out Gate: <N> reviewers — <role list>. Starting in one parallel wave.

その後、選んだ担当ごとに独立したサブエージェントを起動する。すべてを起動し終えるまで結果待ちを始めない。同じ差分を渡し、各プロンプトに次の条件を含める。

• 担当名と上記の担当固有観点。
• 対象のパス、範囲、または差分の特定方法。
• 差分だけでなく、関連する周辺実装・呼び出し元・テストも読む。
• レビュー対象のファイルを変更しない。コミット、フォーマット、生成処理も行わない。
• スタイル上の好みではなく、変更によって生じる具体的で再現可能な問題を優先する。
• 各指摘を P0〜P3、タイトル、根拠、影響、絶対パスと行番号、短い修正方針で返す。
• 問題がなければ No findings と明記する。

利用可能な並列エージェント機能を使う。モデルは原則として親から継承し、ユーザーが指定した場合だけ上書きする。

結果を統合する

全担当が完了してから、主エージェントが各指摘を実コードに照らして再検証する。誤検知を除き、同じ原因の指摘を統合し、重要度順に並べる。

重大度は次の基準を使う。

• P0: 広範な停止、不可逆なデータ損失、重大な侵害など、直ちに対応が必要。
• P1: 通常利用で起き得る重大な誤動作、セキュリティ問題、移行事故。
• P2: 条件付きの不具合、限定的な回帰、保守上の実害。
• P3: 小さな不具合または低リスクの改善。

最終回答は次の順序にする。

1. VERDICT: FAIL（検証済みの P0 または P1 がある場合）または VERDICT: PASS。
2. Findings。各指摘は重要度、簡潔な見出し、根拠、影響、クリック可能な絶対ファイルリンクを含める。
3. Reviewer coverage。実行した担当と、問題なしだった担当を簡潔に示す。
4. 必要な場合だけ、前提や未検証事項を示す。

指摘がなければ No findings. と明記する。レビュー依頼だけではファイルへレポートを書き込まない。ユーザーが保存を明示した場合に限り、指定先または docs/reviews/ に保存する。