Claude Review

Claude Review スキル

このスキルは Claude Code / Codex / Cursor のどのホスト（エージェント）からも呼ばれる前提で書かれている。ホスト固有の起動と合流は「非同期実行と合流」の型分岐に従う。

用途境界: 本スキルは第三者レビュー専用で、read-only + 既定 high（xhigh 以上は使わない）。実装ワーカーとしてCLI agentを委譲する場合は別のオーケストレーター手順を使い、write権限 + 通常 medium とする。レビューと実装委譲を同じ設定で混用しない。

レビューの目的

本スキルの価値はモデルの強さではなく独立性にある。現セッションの文脈・前提・思い込みを共有しない別プロセスが、実装者・設計者の視野に無い観点を持ち込むことが目的である。この前提が、以降のモデル選択と依頼文の書き方を規定する。

適用対象は「やり直しコストが高い成果物」に絞る。 設計メモ・提案書・ADR・アーキテクチャ判断・リリース前のコード・セキュリティ境界のように、後から誤りが判明したときの手戻りが大きいものが対象。独立プロセスの起動は時間もトークンも消費するため、日常の小さな差分すべてに機械的に掛けない。

次のものは本スキルの対象ではない。

• 型チェック・lint・テストで機械的に検出できる欠陥（verify コマンドと done の担当）
• 「動くかどうか」の確認（実行して確かめる方が速く確実）
• 呼び出し元がすでに結論を持っており、同意だけを求めている確認

対象外だと判断したときは、ユーザーがそれを自覚しているかに関わらず、見立てと代替案（型チェック・lint・テストの実行、その場での目視確認など）を述べた上で、実行可否の判断をユーザーに返す。 黙って実行するのも、黙って断るのもしない。ユーザーが承知の上で実行を求めた場合はそのまま実行する。

依頼のスタンスは「改善提案の収集」ではなく「懐疑的検証」に置く。 「良くしてほしい」と投げると一般論が返る。**「この成果物には問題がある前提で、反証を試みてほしい」**と設定し、各論点に判定と根拠をセットで返させる（具体的な依頼文の書き方は「推奨prompt contract」を参照）。

ガードレール（必須・逸脱禁止）

1. read-only 厳守: 起動コマンドには必ず --permission-mode plan と --disallowedTools "Edit,Write,NotebookEdit" の両方を入れる。片方でも欠けたコマンドは実行してはならない。レビュー後に git status で作業ツリー汚染がないか確認し、汚染があれば即報告する
2. ネスト起動禁止: レビュー用 Claude に別の claude -p / codex exec / review 系 skill を起動させない（依頼文に再帰防止文を必ず含める）
3. 書き込み系操作の禁止: commit / push / PR 作成 / GitHub コメント / Issue 作成・更新を行わせない。結果はテキストで返させる
4. 明示指定の尊重: ユーザーが effort / model を明示した場合、自動判定で上書きしない（上げるのも下げるのも禁止）。明示指定とは、モデルID、モデルfamily名（Sonnet / Opus / Fable）、版付き短縮名、または effort レベル名（low/medium/high 等）を挙げたものを指す。 モデル名の解決は「使用可能なモデル」の規則に従う。「しっかり」「念のため」「軽く」のようなレベル名を伴わない強調表現は明示指定として扱わず、自動判定の入力（依頼内容の複雑度の手がかり）として扱う
5. 長時間未完了時のフォールバック: 開始時に想定所要時間を伝える（既定の Sonnet 5 なら数分程度、Opus 5 / Fable 5.1 を選んだ場合や大規模対象では数十分）。実時刻の計測で40分たっても完了していなければ、状況を報告して「継続 or 中断して codex-review へ切替」をユーザーに提示する（勝手に放置も勝手に中断もしない。中断時は結果の部分回収を試みる）。判定基準は「無出力」ではなく「未完了」である — claude -p は結果を最後にまとめて出力するため、処理中に出力が無いのは常態であり、それ自体を失敗の根拠にしない

別プロセスの Claude CLI を起動し、コードベースを read-only で分析する。 現セッションのコンテキストやバイアスに縛られない、独立したセカンドオピニオンを得られる。

モデルと effort（2026-09 時点）

このセクションが本スキル内のモデル ID・effort・既定値の唯一の定義元。 以降のコマンド例に埋まっているモデル名・effort はここの既定値の写しであり、モデル状況が変わったら本セクション・コマンド例・evals/evals.json の expected_output をあわせて更新する。

使用可能なモデル

モデル指定は次の順で解決する。

1. claude-... の正式 ID が指定されたら、その ID をそのまま尊重する。
2. fable-5.1 のような版付き短縮名は、同じ版の正式 ID（この例では claude-fable-5-1）へ解決する。旧版 fable-5 は claude-fable-5 として扱い、無言で 5.1 へ置き換えない。
3. 版なしの family 名 sonnet / opus / fable は、この表に載っている現行の固定 IDへ解決する。したがって「fableに相談して」は claude-fable-5-1 を選ぶ。

既定は claude-sonnet-5 + high。 本スキルの目的は独立した観点の持ち込みであって、モデルの推論力で欠陥を掘り出すことではない（「レビューの目的」参照）。詳細設計が済んでいて実装内容に一定の信頼がある対象——設計どおりに実装されたコード、既知パターンの適用、レビュー目的が「実装者に無い観点の提案」であるもの——は既定のままで扱う。Opus / Fable は通常レビューでは追加の時間・コストに見合う差が出にくいため、必要条件を満たす場合だけ使う。

次のいずれかに当てはまるときのみ claude-opus-5 へ昇格する。 依頼を受けた時点で判断できる条件に限る。

• プランニング段階のレビュー（設計方針・アーキテクチャ選定・ADR・提案書など、実装前の判断そのものが対象）
• 詳細設計は済んでいるが不確実性が高い（前例の無い方式、外部仕様への依存が大きい、想定外の失敗モードが読めない）
• 拠り所となる詳細設計が無いまま複雑な実装が積み上がっている（レビューが実装の検証ではなく、設計の再構築から始まる）

判断軸は対象の題材ではなく、難所が設計で片付いているかどうか。 認証・並行処理・データ整合性といった領域に触れること自体は昇格理由にならない。詳細設計どおりに実装された認証コードのレビューは既定の Sonnet 5 で扱う。

昇格するときは、その理由を一言添えてから起動する（所要時間が伸びるため）。複数の条件に該当する場合は該当したものを全て挙げる（1つだけ挙げて残りを黙って落とさない）。上記に当てはまらない限り既定を維持し、「念のため強いモデルで」という理由で昇格しない。

事後の昇格（重要）。 深さが足りるかどうかは起動時には判定できないため、判断は結果を見た呼び出し元に渡す。Sonnet の結果が一般論に留まる・path:line の裏付けが薄い・懸念していた論点に触れていない場合は、その結果をそのまま採用しない。effort を上げるのではなく、対象スコープを絞り、観点を具体化した上で claude-opus-5 で再実行する。 再実行したことと、Sonnet の結果との差分を呼び出し元へ報告する。

既定モデルでの結果を報告するときは、判断材料と選択肢を添える（必須）。 報告の最後に、(1) scope statement のうち未検査のまま残った範囲に重要なものがあるか、(2) 「このまま採用する」か「スコープを絞って claude-opus-5 で再実行する」かの選択、を明示して呼び出し元に問う。黙って結果だけ返すと、浅い1回で打ち切られたのか十分だったのかが呼び出し元から区別できない。

品質不足を補う独立再レビューは、新しいUUIDを採番した新規 session で行う。--resume / --continue / --fork-session で1回目を引き継がない。 引き継ぐと2回目は1回目の結論・探索経路・見落としをそのまま継承し、本スキルの唯一の価値である独立性が失われる。これは割り込みから同じレビューを完了させる recovery とは別であり、recovery には後述の --resume <session_uuid> を使う。

claude-fable-5-1 はユーザーが「Fable で」「fableに相談して」「fable-5.1 を使って」のように Fable 5.1 または版なしの Fable を明示した場合のみ使用する。 自動選択は絶対にしない。

旧世代 Opus（claude-opus-4-8 以前）を既定にしない。 ユーザーが版を明示した場合のみ使用し、自動判定では現行世代（claude-sonnet-5 / 昇格時 claude-opus-5）を選ぶ。

ユーザーがモデルを明示した場合はガードレール4が優先する。 上記の自動判定で上書きしない（上げるのも下げるのも禁止）。

Effort レベル

effort が明示されない場合は、依頼内容の複雑度から自動判定する。既定は high。 通常のコードレビューもアーキテクチャ分析もこの既定 high で行う。クイックチェックなど明らかに軽微な依頼に限り medium / low に下げてよい。effort が明示された場合は必ずそれに従う。

xhigh 以上（xhigh / max）は使わない。 effort を上げるほど精度が上がるわけではなく、過剰な探索と推論でレビュー結論の質が落ちる場合がある。自動判定でも既定でも選ばない。深さが足りないと感じたときは effort を上げるのではなく、対象スコープを絞る・観点を具体化する・複数回に分ける方向で対処する。

下表は各レベルの「深さの目安」であって、タスク種別から機械的にレベルを引くための対応表ではない。未指定時は上のルール（既定 high）が優先し、下表は「既定からどこまで下げてよいか」の判断材料として使う。

自動判定の上限は high。 ユーザーが xhigh / max を明示的に要求した場合のみ、ガードレール4に従って尊重する（その際は精度が上がらない可能性を一度添える）。

実行前の確認

会話の文脈からわかる場合は確認を省略して構わない。不明な場合のみ確認する。

<依頼内容> には、ユーザーの依頼をその意図を保ったまま、レビュー対象スコープ（全体／特定ファイル・ディレクトリ／差分の範囲）と観点を含む簡潔な指示へ整形して埋める。差分レビューでは対象（未コミット／ブランチ差分／コミット）を依頼文に明示し、未指定なら作業ツリーの差分を既定とする（起動先 Claude が git diff 等の読み取り系ツールで取得する）。

重要: 起動先 Claude がさらに codex-review / claude-review skill や codex exec / claude -p を起動して再帰することがある。<依頼内容> の先頭または末尾に必ず次の趣旨を明示する。

You are the reviewer. Inspect the repository directly.
Do not invoke codex-review, claude-review, codex exec, claude -p, or any nested reviewer.
Use only read-only repository inspection commands and return findings directly.

実行コマンド

プロンプト本文は必ず single-quoted heredoc で渡す。Markdown のバッククォート、$VAR、$(...)、型注釈、引用符を含むレビュー依頼を claude -p "..." に直接入れると、shell がコマンド置換や変数展開として解釈してプロンプトを壊す。以下はCLI payloadであり、単独で直実行しない。必ず「durable recovery record」のwrapperがrun directory作成、record更新、process identity記録、終了status記録を行う内側で実行する。

claude -p "$(cat <<'CLAUDE_REVIEW_PROMPT'
You are the reviewer. Inspect the repository directly.
Do not invoke codex-review, claude-review, codex exec, claude -p, or any nested reviewer.
Use only read-only repository inspection commands and return findings directly.

<依頼内容>
CLAUDE_REVIEW_PROMPT
)" \
  --session-id <session_uuid> \
  --model claude-sonnet-5 \
  --effort <level> \
  --add-dir /path/to/project \
  --permission-mode plan \
  --output-format stream-json \
  --verbose \
  --disallowedTools "Edit,Write,NotebookEdit" \
  < /dev/null > "<event_log>" 2> "<stderr_log>"

重要: heredoc delimiter は必ず引用する（例: <<'CLAUDE_REVIEW_PROMPT'）。引用しない <<EOF は shell 展開を許すため使わない。プロンプト内に delimiter と同じ行が含まれる場合だけ、別の一意な delimiter 名に変える。 重要: プロンプト本文（heredoc 内）に $HOME などの変数を書かない。single-quoted heredoc では展開されず、リテラル文字列 $HOME のままレビュー先へ渡る。対象パスは heredoc の外にある --add-dir で渡し、本文では「--add-dir で許可されたディレクトリ」と参照するか、展開済みの絶対パスを書く。 重要: --disallowedTools は可変長フラグのため、プロンプトは必ずフラグ群より前（最初の引数）に置くこと。後ろに置くとプロンプトが認識されずエラーになる。 重要: 実行直前に、生成したコマンドへ--permission-mode planと--disallowedToolsが両方存在することを再確認する。 重要: 起動前に新しい有効な UUID を採番して <session_uuid> に渡す。--no-session-persistence は付けない。--output-format stream-json --verboseで初期eventを<event_log>へ即時永続化し、そのeventのsession IDが採番UUIDと一致することをsession成立の根拠にする。最終本文は終了後にresult eventから抽出する。 重要: 下記「durable recovery record」に従い、UUID専用run directory・event log・stderr log・lifecycle recordをCLI起動前に作る。すべてのpathを引用し、既存fileを再利用しない。 重要: 末尾の < /dev/null は必須。明示prompt以外のstdin待ちを防ぐ。stdin読取を示すメッセージが出ても、redirect済みで本文生成が進んでいればハングではない。 重要: このコマンドは呼び出し元を解放する形で起動する（起動と合流の型は後述の「非同期実行と合流」を参照）。既定 high でも対象が大きければ処理は数分〜数十分かかりうるが、背景実行なら Bash の10分上限で kill されず、呼び出し元もブロックしない。claude -p は非対話の print モードでstream-jsonを標準出力へ継続出力するため、背景起動でもevent logからsession成立と最終resultを回収できる。

• --model claude-sonnet-5: 使用モデルを明示固定（既定・昇格条件は「モデルと effort」セクション参照）
• --effort <level>: 既定 high（自動判定。xhigh 以上は使わない）
• --add-dir <project_dir>: 対象ディレクトリへのアクセスを明示的に許可する
• --permission-mode plan: Bashを含む実行全体を非変更モードへ制約する
• --disallowedTools: Edit/Write/NotebookEdit を禁止して読み取り専用を保証する
• ファイルの読み取り・Bash・git などの読み取り系ツールは引き続き使用可能

複数directoryを横断する場合、現行CLIの--add-dir <directories...>へ必要なpathを列挙する。共通親を広く許可するより、必要なdirectoryだけを許可し、promptにも対象pathを明示する。

--add-dir /path/to/repo-a /path/to/repo-b /path/to/shared

実行例

# 既定: 詳細設計どおりに実装された差分のレビュー（Sonnet 5 + high）
claude -p "$(cat <<'CLAUDE_REVIEW_PROMPT'
You are the reviewer. Inspect the repository directly.
Do not invoke codex-review, claude-review, codex exec, claude -p, or any nested reviewer.
Use only read-only repository inspection commands and return findings directly.

この差分には問題がある前提で反証を試みてください。実装者が気づいていない観点の指摘を優先します。
CLAUDE_REVIEW_PROMPT
)" \
  --session-id <session_uuid> \
  --model claude-sonnet-5 \
  --effort high \
  --add-dir $HOME/my-project \
  --permission-mode plan \
  --output-format stream-json \
  --verbose \
  --disallowedTools "Edit,Write,NotebookEdit" \
  < /dev/null > "<event_log>" 2> "<stderr_log>"

# 昇格例: 実装前の設計判断そのものが対象（Opus 5 + high）
claude -p "$(cat <<'CLAUDE_REVIEW_PROMPT'
You are the reviewer. Inspect the repository directly.
Do not invoke codex-review, claude-review, codex exec, claude -p, or any nested reviewer.
Use only read-only repository inspection commands and return findings directly.

この設計方針には穴がある前提で反証を試みてください。検討していない失敗モードと、選択しなかった代替案を優先して挙げてください。
CLAUDE_REVIEW_PROMPT
)" \
  --session-id <session_uuid> \
  --model claude-opus-5 \
  --effort high \
  --add-dir $HOME/other-project \
  --permission-mode plan \
  --output-format stream-json \
  --verbose \
  --disallowedTools "Edit,Write,NotebookEdit" \
  < /dev/null > "<event_log>" 2> "<stderr_log>"

durable recovery record

wrapperの最小schemaと更新手順はreferences/durable-run-record.mdを正とする。

ホストハンドルだけをrecovery recordにしてはならない。起動ごとに新しいrun UUIDを作り、ホストの永続state root配下のreviews/<run_uuid>/を専用run directoryにする。場所は一時directoryやrepo内ではなく、再開後も残る既知のrootとし、起動前にrun UUIDと絶対pathをユーザーへ通知する。別runのdirectoryやfileは再利用しない。

run directoryには少なくともrecord.json、event/stdout、stderr、final outputを置く。record.jsonはrun UUID・provider session ID・cwd・対象root/path・model・effort・各出力path・host handle・process identity（PIDだけでなく起動時刻等の照合値）・prepared|running|exited・exit statusを含む。CLIを包むwrapperが、起動直前にrunning、終了直後にexitedとstatusを書き、同じdirectory内の一時fileをrenameして原子的に更新する。stderrも専用fileへ保存する。

割り込み後は、通知済みrun UUIDからdirectoryを決定的に開く。latest、mtime、候補一覧では選ばない。runningのままなら記録したprocess identityを照合し、生存中なら待機する。不在またはidentity不一致なら元processは終了済みとして扱い、eventとstderrからsession成立・失敗理由を確認する。これによりhost handleを失っても、session成立済みなら正確なIDでresumeでき、未成立なら診断後に新規起動できる。run UUIDもlocatorも失った場合だけ復旧不能としてstep 3へ進む。

非同期実行と合流

レビューは対象が大規模なほど時間がかかり、数分〜数十分に達しうる。出力が無い間も停止やハングではなく推論を継続している。長時間化を理由に kill・キャンセル・再実行をしてはならない。

起動は必ず呼び出し元を解放する形で行い、合流はホストの合流機構に任せる。 起動直後に、所要時間の見込みと「応答が無くても処理は継続中でありハングではない」ことを呼び出し元へ伝える。

• 通知型: 完了前に出力を見に行かない。通知の遅延は「いま実行中のツール呼び出しが終わるまで」で決まり、覗いても縮まらない。近リアルタイムに合流したいなら待ち時間の作業を短く刻む
• ハンドル型: 手元の作業が一段落した時点で、1回のツール呼び出し内でブロッキング読み取りを行って合流する。放置すると永久に合流しない。 実測の経過が40分を超えたらガードレール5に従う。ハンドルと出力先は控えておき、推測したハンドルやパスを読まない
• 同期型: 待ち時間そのものが存在しないため「レビュー中の並行作業」は適用外。発話窓は実行直前のみで、そこで予告を出す。ホストの実行タイムアウトに収まらない場合も盲目的に再実行せず、対象を絞るか effort を一段下げる

経過時間は必ず実時刻の差で測る。起点は起動成功（ハンドル・タスク ID・プロセスを確認できた時点）に置き、その時刻を記録する。 反復回数 × 待ち時間の机上積算をしない — ホストによっては shell の sleep が無効化されており、待機ゼロで空回りしたループを「待った時間」と数えて、経過数分を数十分と誤認する。禁止するのは sleep と再読込を組み合わせた自作ポーリングであり、ホストが提供するブロッキング wait / read はそのまま使ってよい。完了通知は実際の終了より先に届くことがある — 通知型では通知を受けるまで出力を見ず、通知後に実終了を確認してから結果を回収する。確認は CLI が明示的に提供する完了マーカー（終了時に出すフッター行）またはプロセスの終了で行い、どちらも確認できないホストではホストが返す最終結果・終了ステータスを完了根拠とする（未定義のマーカーを推測して待ち続けない）。

シェルレベルの detach（nohup / setsid）は使わない。 macOS には setsid(1) が無く、nohup ではプロセスグループ単位の kill を防げない。ホストの機構が無ければ同期型として扱う。

時間超過への対処でも、ガードレール4（明示指定の尊重）が優先する。ユーザーが effort / model を明示している場合、時間超過を理由に自動で降格しない。まず対象スコープの絞り込みで対処し、それでも収まらなければ降格の可否をユーザーへ確認する。

合流したら、進行中の作業よりレビュー結果の検証と報告を優先する。

レビュー中の並行作業

待ち時間に対象リポジトリを触る予定があるなら、スナップショット起動にする。 レビュー対象を不変オブジェクトとして固定してから起動すれば、呼び出し元はその後リポジトリを自由に扱える（手順は references/review-snapshot.md）。実ツリーと index には一切触れず、untracked を含む現在の状態を固定できる。依頼文では対象を「HEAD~1..HEAD の差分」と伝え、.gitignore されたファイルは含まれないことを添える。この場合、ガードレール1の汚染チェックはスナップショット worktree 内で行う — メインツリーは並行作業で当然変化するため、そちらを見ると恒常的に偽陽性になる。

スナップショットを取らずに起動した場合は、レビュー完了まで次の3つを変えない。

1. レビュー対象ツリーと index — 編集・commit・stash・branch 切替・依存更新をしない
2. 依頼が参照する ref — git fetch / git pull をしない（ブランチ差分は読み取り時点で ref を解決するため、差分の基準が途中で動く）
3. 共有の .git/config と hooks — 全 worktree で共有される。別 worktree での依存インストール（husky install 等）はレビュー対象の git 挙動を書き換える。worktree の追加は git -c core.hooksPath=/dev/null worktree add で、レビュー起動より前に済ませる

待ち時間に何を進めるかは制限しない。 別 worktree での後続タスク実装を含めてよい。ただしそのブランチを merge するのは、レビュー結果を処理したあとにする。サブエージェントへ委譲するときは、上の制約と再帰起動の禁止をそのまま伝える（委譲先の完了時に別のレビューが自動起動する仕組みがあれば、それも止める）。

中断・回収失敗からの復旧

会話の割り込みや合流失敗を、レビュー自体の失敗と同一視しない。session成立後の割り込みでは次の順で復旧し、新規レビューを先に起動してはならない。CLIがpromptを受理する前に終了し、process・出力・session metadataのいずれからもsession成立を確認できない場合は起動失敗であり、原因を直して新しいUUIDで新規起動する。事前採番したUUIDだけではsession成立の証拠にならない。

1. 通知済みrun UUIDからrecord.jsonを開き、lifecycle stateと記録済みprocess identityを先に確認する。runningでidentityが一致するprocessが生存中なら、記録したホストハンドル（または同期型ホストの結果）で待機・回収し、同じsessionへ同時にresumeしない。process不在またはidentity不一致なら終了済みとしてevent・stderr・exit statusを確認する。run recordを開けず状態を確定できなければ、process名・mtime・候補sessionから推測せず、resumeもforkも新規起動もせずユーザーへ報告する
2. 終了済みなら、記録した出力先またはホストの最終結果から既存出力を先に回収する。元promptが要求した終端要素（少なくともレビュー結論とscope statement）が欠ける場合を未完了とし、回収不能または未完了の場合だけ、記録した正確なsession_uuidを--resumeして同じレビューを完了させる
3. session UUIDを安全に特定できなければ、推測したIDや--continueで別sessionへ接続せず、復旧不能と、新規レビューでは時間・トークンを再消費し元の探索文脈も継承できないことをユーザーへ報告して判断を返す

claude -p "$(cat <<'CLAUDE_REVIEW_RECOVERY'
You are the reviewer. Do not invoke codex-review, claude-review, codex exec, claude -p, or any nested reviewer.
Use only read-only repository inspection commands and return findings directly.

直前のレビューを継続してください。調査済みの範囲をゼロからやり直さず、未完了部分だけを完了させてください。
この回答は中断後の継続生成であり、元の最終本文の逐語的な再掲とは主張しないでください。
今回実際に検査した範囲と、session履歴から引き継いだ範囲を区別したscope statementを必ず返してください。新しいレビュー観点は追加せず、リポジトリは変更しないでください。
CLAUDE_REVIEW_RECOVERY
)" \
  --resume <session_uuid> \
  --model <original_model> \
  --effort <original_effort> \
  --add-dir /path/to/project \
  --permission-mode plan \
  --output-format stream-json \
  --verbose \
  --disallowedTools "Edit,Write,NotebookEdit" \
  < /dev/null > "<recovery_event_log>" 2> "<recovery_stderr_log>"

復旧を起動したら、<recovery_event_log>と<recovery_stderr_log>も同じrecovery recordへ追記し、以後の回収では元の出力先と混同しない。最終本文はresult eventから抽出する。

recoveryはrecovery recordの起動cwdから実行し、元のmodel・effort・作業root/対象path・read-only制約を維持する。snapshot起動なら同じsnapshot worktreeを使い、新しい観点やスコープを加えない。同じhost timeoutが再発する条件ではhost-nativeな非同期実行へ直すかscopeを縮小し、縮小範囲をscope statementへ記録する。明示model/effortは変更しない。正確なUUIDとして扱えるのは、起動時の記録、記録済みホストtaskのmetadata、記録済み出力に含まれるIDのように元processと一意に対応する値だけである。cwdのlatest、更新時刻、候補一覧からの推測は使わない。--continueはcurrent directoryの直近sessionを暗黙選択し、並行sessionがあると誤接続するため使わない。--fork-sessionも同じレビューの復旧には使わない。resumeがsession不存在で失敗した場合は繰り返さず、復旧不能としてstep 3の報告へ進む。

同じレビューへの追加質問

findingの深掘りや反論確認は、上のrecovery promptを流用せず、同じread-only flagsと正確なsession UUIDで質問本文だけを渡し、stream-jsonとstderrはリポジトリ外の専用<followup_event_log>・<followup_stderr_log>へ保存する。両出力先もrecovery recordへ追記し、既存出力を上書きしない。

Finding 2を、根拠となるpath:lineと成立条件を示して詳しく説明してください。新規レビューやnested reviewerは起動しないでください。

結果の整理と報告

Claudeの指摘は結論ではなく仮説として受け取り、採用前に該当path:lineと実装を自分で確認する。必要であれば以下の観点で整理する:

回収したstream-jsonは数百KBになることがある。全体を読まずresult eventから最終本文を抽出し、同じ最終本文が再掲される場合は二重報告しない。

1. 要約: 主な発見事項（3点以内）
2. 詳細: 具体的な指摘（優先度順）
3. 推奨対応: 改善提案と実装方針
4. 補足: 追加調査が必要な項目

推奨prompt contract

• 懐疑的スタンスを冒頭で設定する。 「改善点を教えて」ではなく「この成果物には問題がある前提で反証を試みてほしい」と書く。前者は一般論を、後者は判定と根拠を返させる
• 既知の欠陥ではなく、こちらが見落としている観点を求めていると明示する。 「型チェック・lint・テストで検出できるものは対象外。設計判断・前提・失敗モードなど、実装者の視野に入っていない可能性がある観点を優先する」
• 論点を番号付きで列挙し、各論点に VERDICT: AGREE / AGREE-WITH-CAVEAT / DISAGREE / RISK、根拠、代替案を要求する
• 遠慮不要と明記し、懸念している弱点を具体的に列挙する
• 各findingにpath:lineを必須化する
• docsレビューでは契約定義・manifest・package設定など対象実装を列挙し、文書の現在形の主張と実装を突合させる。docs整合だけならmediumを選べる

網羅性を明示的に要求する（重要）。 洗練された指摘が返る一方で、重要度による自己フィルタや説明の飛躍で論点が落ちることがある。次の3点を依頼文へ必ず入れる。

• 重要度・確信度で self-filter させない。 「低確度・低severityと判断したものも含めて全件挙げる。絞り込みは呼び出し側で行うので、この段階の目的は網羅性である」と明記し、各findingに confidence と severity を自己申告させる。上限件数は課さない（件数上限は網羅性と直接トレードオフするため、必要なら受け取り側で切る）。
• 見ていない範囲を返させる。 「今回検査しなかったファイル・観点・前提」を scope statement として必ず出させる。無言の未検査を「問題なし」と誤読しないため。
• 同種欠陥の掃き出しを最後に1回要求する。 「指摘した各欠陥について、同じ原因の箇所が他に残っていないか検索して報告する」。1件目だけ挙げて類似箇所を落とす形を防ぐ。

必要性の根拠と単純案を明示的に要求する（重要）。 レビュー提案は overengineering へ寄ることがある。また、done の外部レビューは provider を等価に扱うため、BASIS ラベルの有無が provider で変わると受け取り側の契約が壊れる。次の2点を依頼文へ必ず入れる。

• 各提案に必要性の根拠をラベルさせる。 BASIS: OBSERVED（コードやテストで観測された事実・再現する不具合）/ CURRENT-THREAT（現在の脅威モデル・受入条件・規制で要求される）/ REAL-DEMAND（実在する利用者・ユースケース）/ SPECULATIVE（将来こうなるかもしれないという仮説）のいずれかを付けさせる。SPECULATIVE は提案の削除ではなく分離が目的で、受け取り側の判断材料にする。ラベル定義の正本は ai-native-engineering の「BASIS ラベル」節。
• より単純な代替案を併記させる。 「同じ問題を解決できる、より少ない機構・抽象・依存で済む案を必ず1つ挙げ、その案を採らない理由を示す」。単純案が示せない提案は、必要性の再確認対象にする。

受け取り側の検証規律

1. 指摘を機械的に採用・棄却せず、該当箇所と成立条件を確認する。
2. 引用の実在を確認する。 提示された path:line とコード断片が実際にその内容で存在するかを、採用前に必ず自分で突き合わせる。行番号のずれ、古い内容の引用、存在しないシンボルは珍しくない。実在しない引用に依存した指摘は、結論が正しく見えても採用しない。
3. scope statement を読み、未検査範囲を明示的に扱う。 未検査の観点が重要なら、別途レビューするか自分で確認する。返答に無いことを「問題が無いこと」の根拠にしない。
4. BASIS: SPECULATIVE の提案は既定で採用しない。 「security上望ましい」「将来必要になりそう」「一般にベストプラクティス」だけを根拠にした提案は、具体的な資産・攻撃経路・実需・観測された負荷を特定できるまで保留する。判定基準は ai-native-engineering skill の「投機的な抽象化を見分ける」「需要を待つ領域」「原則として先に決める判断」に従い、契約・境界の先決めと機構の先作りを分けて扱う。
5. 単純案が併記されている場合、まず単純案を検討する。 提案側の複雑な案を既定にしない。
6. セキュリティ境界はfail-closed等のラベルで合格にせず、何と何を比較し、どこで強制しているかを実装まで辿る。
7. 修正後は元の検査に加え、secret/confusable等の関連scanを再実行する。レビュー修正そのものが新しい欠陥を作り得る。
8. 最後にgit statusを再確認し、レビュー用processによる汚染がないことを確認する（スナップショット起動時はスナップショット worktree 側を確認する）。

注意事項

• --permission-mode plan と --disallowedTools を併用し、Bashを含む変更操作とEdit/Write/NotebookEditを二重に制約する
• Markdown やコード片を含むプロンプトを claude -p "..." に直接書かない。必ず single-quoted heredoc で渡す
• 適用対象は「やり直しコストが高い成果物」に絞る。型・lint・テストで検出できる欠陥や、実行すれば分かる動作確認には使わない
• モデル・effort の既定と昇格条件は「モデルと effort」セクションの定義に従う
• モデルは既定 claude-sonnet-5。設計そのものが対象・高不確実性・拠り所の設計が無い場合だけ claude-opus-5 へ昇格し、理由を一言添える。題材（認証・並行処理など）は昇格理由にならない
• 既定モデルでの結果報告には、未検査範囲と「採用する／スコープを絞って claude-opus-5 で再実行する」の選択を必ず添える
• 品質不足を補う独立再レビューは新規sessionで行う。割り込み・回収失敗のrecoveryと追加質問は、正確なsession UUIDを指定して--resumeする
• claude-fable-5-1 は最も難しい長時間タスク向けのため、Fable をユーザーが明示した場合のみ使用し、自動選択は絶対にしない
• effort は既定 high（自動判定）。軽微な依頼や時間優先のときのみ medium / low に下げる
• xhigh / max は使わない。精度が上がらないため、深さ不足はスコープの絞り込みや観点の具体化で解決する
• --add-dir を忘れると対象ディレクトリへのアクセスが制限される場合がある