---
name: rere
description: リポジトリまたは指定スコープのコード・設定・テストを、12のソフトウェア品質観点（外部情報整合を含む）と横断の最適解観点、証拠検証・反論検証の2段階で厳密にレビューし、false positiveを除いた技術的指摘（不具合と最適解逸脱）を根拠付きで報告する。Use when the user invokes /rere, or explicitly asks for a whole-codebase, comprehensive, multi-perspective, twelve-perspective, or rigorous software-quality review rather than a diff. Do not use for performance-only optimization, ordinary PR review, or product strategy.
---

# 12観点＋2検証役で総合レビューする 🔬🛡️

レビューはユーザーが所有・管理する、または解析を明示的に許可されたコード・設定・テストの読み取り専用を既定とし、発見量より検証済みの正しさを優先する。候補の形式、重要度、安全検証、Phase 2 の判定、統合は[指摘プロトコル](references/finding-protocol.md)を正本とする。外部環境、実秘密、無関係なプロセスへ能動的な操作を行わない。最終報告は対象リポジトリとユーザーの言語・文体指定に従う。

## 0. 起動時にタスク履歴を判定する 🧯

開始前に、現在のCodexタスクで過去の `rere` が未完了のままCyber安全判定またはシステムエラーにより停止していないか確認する。

該当する場合、同じタスクではレビューを再開しない。過去の候補指摘、途中成果、サブエージェント出力を再読・要約・再利用せず、「このタスクには停止前の文脈が保持されているため、同じリポジトリを対象に新しいCodexタスクを作成し、そこで `/rere` を実行してください」とだけ案内して終了する。ユーザーが同じタスクでの再開を指示した場合も、新しいタスクを安全な実行単位として案内する。

通常の利用者中断、ツールの一時失敗、並列枠不足はこのガードの対象外とし、既定のフォールバック契約で継続する。

上の停止履歴に該当しない場合、`/rere` の呼び出し自体を、読み取り専用の14役レビューに対する明示指示として扱う。開始時に14役の構成、モデル、利用可能な並列枠から見積もった想定時間、停止条件を1行で通知し、スコープ把握とカナリア起動へ直ちに進む。開始してよいか、長時間でもよいか、サブエージェントを起動してよいかは確認しない。確認は利用者向け仕様を変える設計判断、外部書き込み、破壊的操作、新規課金、または権限範囲の拡大が必要になった時点で行う。

## 1. スコープを把握する 🔍

差分だけ、PRだけ、または軽いレビューが明示された場合は14役の全体レビューを起動しない。`/rere` と併記されていても用途の不一致を短く伝え、明確な依頼なら通常の読み取り専用差分レビューとして扱い、全体レビューが必要か不明な場合だけ確認する。

1. 指定範囲、適用指示、現在の差分を確認する。指定がなければ生成物と依存物を除くGitルート全体を対象にする。
2. manifest、エントリーポイント、主要境界、設定、CI、テストを短く把握する。
3. 利用可能なシンボル参照ツールやコード検索（`rg` 等）を使い、主要なデータフローと公開境界を確認する。

## 2. Phase 1で12観点を調査する 🔥👥

[レビュー役](references/reviewer-roles.md)と[指摘プロトコル](references/finding-protocol.md)を読む。

### 観点の割り当て

- A1 アクセス境界・状態管理
- A2 入力・機密データ・依存整合
- B1 設計境界・エラー・並行性
- B2 保守性・テスト・文書整合
- C1 計算量・データ構造
- C2 I/O・メモリ・起動
- F 可観測性・運用
- G 後方互換・移行・永続データ
- E1 UI実装整合・アクセシビリティ
- E2 国際化・地域化・時刻
- H 外部情報整合
- D 設計前提の反証

12観点はすべて別の役として起動する。G、E1、E2、H は対象が持つ場合だけ意味を持つ観点なので、スコープ把握で該当物（永続データ・配布物 / 画面 / 多言語・時刻処理 / 外部依存・外部プラットフォーム規約）が確認できなければ、その役は該当性だけを最小確認して `非該当` を返す。H は調査対象インベントリが空なら Web 検索を行わず終了する。

H は外部の現在値を調べる役なので、`agent_type` に `researcher` を指定する。H 役自体の起動は本節を優先し、メインは共通仕様 `references/external-intel.md` 第2節の調査対象インベントリを委任文へ渡す。外部調査を行う条件、ソースの選択、証拠の階層、検索上限は同仕様に従う。

### 共有基礎検証と候補台帳

メインはスコープ把握時に、リポジトリ全体の基礎検証として使う既存の test / build / lint / typecheck コマンドを決める。カナリア通過後に利用可能な並列枠を埋め、その役の調査と並行して、必要十分な基礎検証をメインが1回だけ実行する。コマンド、終了状態、所要時間、主要な失敗だけを実行台帳へ記録し、以後の役と Phase 2 へ短い要約を共有する。

各役は同じ全体テスト、全体coverage、build、lint、typecheckを再実行しない。担当候補の成立判定に必要な既存テスト、pure-canary、mock / fixture に絞り、対象と時間上限を明示して局所検証する。基礎検証をメインが実行できない事情がある場合だけ1役を実行担当に指定し、他役へ結果を共有する。

メインは `役ID / thread / 要求プロファイル / 実効プロファイル / 状態 / 候補ID / 照会` の実行台帳と、指摘プロトコルの項目を持つ候補台帳を管理する。役の最終返却を受けるたびに参照を正規化し、同じroot causeを逐次統合する。サブエージェントの生の長文やコマンドログを進捗へ複製せず、Phase 2 には重複除去済みの候補台帳だけを渡す。

### サブエージェント起動契約

`references/agent-coordination.md` の「サブエージェントと Codex タスク」を読み、起動形、プロファイル、実行台帳、ユーザー報告をその正本へ統一する。ユーザーまたは上位指示が別のエージェントを明示した場合だけ、その指定に従う。

Phase 1 の12役と Phase 2 の2役は、それぞれ新鮮な文脈を持つ独立スレッドへ割り当てる。メインが対象パス、適用指示、担当観点、確認する境界、基礎検証の担当、返却形式を短い自己完結した依頼にまとめる。会話自体が証拠の場合だけ、必要な直近の内容に限って要約して渡す。各役は担当外へ広げず、1回の調査と自己反証で返す。

各委任文は自己完結させる。メインは[指摘プロトコルの委任本文](references/finding-protocol.md#委任文へ転記する本文)を意味を変えずに転記し、Phase 1 では同プロトコルの返却契約、Phase 2 では該当する V1 / V2 判定契約も転記する。セキュリティ境界を扱う役には、同プロトコルの該当する境界別検証パターンも含める。要約を別の契約として作らない。

最初の実担当 A1 をカナリアとして先に起動する。A1 の最初の行動を「対象内のソースまたは設定を1件読み、起動成功と観測できる実効プロファイルを1行で返してから、そのまま担当レビューを続ける」と指定する。カナリア成功は起動受理とこの短い読み取り確認で判定し、A1 の最終報告を待たない。起動が受理され、実行状態まで確認できた場合は、ready通知が遅くてもレビュー完了を待たずに利用可能な並列枠へ残りを波状展開する。

カナリア通過後は実行中のサブエージェント枠を空けず、H を最初の波へ入れて外部調査の待ち時間を前倒しし、続いて A2、B1、B2、C1、C2、F、G、E1、E2、D を未起動順に補充する。固定の同時数を仮定せず、他タスクのエージェントを中断しない。メイン側に統合、基礎検証、P0/P1再確認などの作業がある間はそれを進め、待機だけが残った場合は現在のツールと上位指示が許す最長のイベント待機を使う。状態が変わらないタイムアウトのたびに長い進捗を再生成しない。

`agent thread limit reached` が出た場合は、同じ条件で繰り返し起動せず、`agents.max_concurrent_threads_per_session = 14` が新しいCodexプロセスまたはタスクで読み込まれているかを確認する。14個の新しい役スレッドを確保できない実行基盤では、別役へのスレッド再利用やメインによる代役で役数を減らさず、実行基盤不一致として停止理由を報告する。ユーザーへ「役を減らして続けるか」は質問しない。

Phase 1 は H を除く各観点に `analyst`、H に `researcher` を使う。

各役は担当観点だけを読み取り専用で調査し、実コードを再読してから指摘を返す。対象に存在しない観点は根拠付きで非該当とし、無理に指摘を作らない。推測、表層lint、製品方針、ブランド、価格、機能の存廃は対象外にする。

全役は担当観点の中で、[最適解観点](references/reviewer-roles.md#最適解観点最適解逸脱)にも従う。判定条件と不採用時の扱いは同節を正本とし、ここでは再掲しない。

## 3. 未解決を Web 調査で埋める 🚪

Phase 1、Phase 2、メインから出た照会は共通仕様 `references/external-intel.md` の第7節で集約・選別・調査する。`rere` では起動済みの H へ同じ役の追加ラウンドとして渡し、対象を問いに限定する。H を再開できない場合はメイン自身が同仕様の手段と上限に従う。答えは対象コードの `file_path:line_number` へ接続して判定をやり直し、決着しなかった問いは `確認できず` として報告する。照会が無い場合もその旨を1行残す。

## 4. Phase 2で反証する 🔍

Phase 1完了後、Phase 1とは別の新しい検証担当を2体、利用可能な並列枠で同時に起動する。V1は `agent_type: "analyst"`、V2は `agent_type: "general-purpose"` を指定する。V1には重複除去済み候補台帳と検証対象、V2には同じ候補台帳と反論条件だけを渡す。Phase 1各役の生の返却や会話履歴は渡さない。

V1 / V2 の担当範囲は[レビュー役の Phase 2](references/reviewer-roles.md#phase-2)、判定語彙、外部出典の扱い、削除・照会条件は[指摘プロトコルの Phase 2](references/finding-protocol.md#phase-2-独立検証する)を正本とする。最終的な採否判断はメインのCodexが行う。

## 5. 統合する 🧩👑

メインは[指摘プロトコルの統合契約](references/finding-protocol.md#統合する)に従い、候補を採否・統合する。

## 6. 報告または修正する 📋

結論、Phase成功数、生指摘と採用数、P0/P1詳細、P2/P3要約、問題なしの観点、推奨順序を日本語で報告する。セキュリティ関連の報告形式は[指摘プロトコルの共通安全契約](references/finding-protocol.md#共通安全契約)に従う。`suboptimal` 指摘は不具合指摘と節を分け、[同プロトコルの追加項目](references/finding-protocol.md#suboptimal-の追加項目)を記載順の正本とする。H を起動した場合、または照会を Web 調査へ回した場合は、外部出典を伴う指摘に URL と日付を併記し、裏取りできず `確認できず` に終わった照会も `問い → 当たったソース → 次に見るべき場所` の形で1行ずつ残す。実行台帳は上の起動契約どおり、要求した役割・モデルと実効値を分離して記録する。取得できない値は推定せず `取得不能` とする。

レビューだけの依頼なら第7節の選択までは変更しない。修正も明示されている場合は、確定指摘のうち既存契約を保つものを依存順に修正・検証する。設計判断が必要なものは選択肢と影響を示して確認する。

## 7. 次の操作を選んでもらう 🗳️

レビューだけの依頼で採用指摘が1件以上あり、現在のセッションで選択式のユーザー入力ツールを利用できるなら、レビュー報告を提示した直後かつ最終終了前に1問だけ表示する（テキストで選択肢を並べず、同一応答の締めくくりをツール呼び出しにする）。選択肢は次の3つとし、自由入力の `Other` はクライアントが自動付与するので自前で追加しない。

- `全件修正 (Recommended)`: 確定指摘のうち既存契約を保つものを依存順に修正・検証する。
- `修正計画だけ`: 変更せず、対象ファイル、依存順、検証方法を整理する。
- `レビューで終了`: 変更せずレビュー結果を最終回答にする。

このダイアログは1実行につき1回だけにし、選択した修正または計画作成の完了後は再質問しない。`Other` で指摘IDや範囲が指定された場合は、その範囲だけを修正対象にする。選択はローカル修正または計画作成の明示依頼として扱うが、Git操作、version変更、外部変更の権限は広げない。修正まで依頼済み、採用指摘なし、または選択式のユーザー入力ツールが利用できない場合はダイアログを出さず、通常の完了報告で終了する。