レビューループ判断ロジック(共通正本)

codex-review-loop・fable-review-loop・opus-review-loop など、反復レビュー・ループを実装する 各スキルが共有する判断ロジックの正本。レビュアーの正体(Codex・Fable・Opus等)に依存しない 判断ロジックのみを定める。レビュアーの起動契約(呼び出し方・記号規約・タイムアウト制御・ 失敗時のリトライ等)は codex-review-loop・fable-review-loop・opus-review-loop それぞれが持つ(後二者は共通部分を review-loop-subagent に置く)。

呼び出し元スキルは、レビュー実行(各スキルが自分で定めるレビュー実行の段)の前後でこのスキルを起動し、 以下の手順・大前提に従う。以下「レビュアー」は起動したレビュー担当(Codex・Fable・Opus等)を指す。

終了条件(いずれかで停止)

1. 収束: 未解決の指摘がゼロ(修正済み・反証・レビュアーが認めた受容 は解決済みに数える)
2. 千日手: 反証済みの指摘や レビュアーが認めない受容 をレビュアーが同じ理由で再掲し続ける、 または数ラウンド連続で新規の解消がない(指摘集合が縮まらない)
3. 要ユーザー判断: 修正/反証/受容/保留の判断が設計・プロダクト判断でClaudeが一存できない項目が出た

手順0: 起動可否ゲート・対象確認

起動可否ゲート: このループ(codex-review-loop/fable-review-loop/opus-review-loop)を起動してよいのは、次の いずれかを満たすときに限る。

• (a) ユーザーが明示的な指示で起動した autonomous-dev のマイクロループ(各フェーズのレビュー ゲート)からの呼び出しである(ユーザーの指示なしに autonomous-dev を自発起動して、その内部 手順を根拠にこのゲートを通ることはできない)。
• (b) このラウンドを開始する直前に、ユーザーからレビュー実行の明示的な指示があった(いまの 会話でまだ有効なもの。「はい」等の一般的な承認や、別件の選択肢回答をレビュー起動の許可と 解釈しない。修正・実装の指示だけではレビュー起動の指示にならない)。

どちらも満たさない場合は、レビュアーを起動せず、対象(差分)と起動したい理由を示してユーザーに 確認する。確認を待たずに起動しない。

(b)の指示は、このループを新規に起動する対象となった変更にのみ適用される一回限りの許可である。 このループが起動され、収束・千日手・要ユーザー判断のいずれかで終了した後、別の新しい変更(新しい 修正・追加修正)を行った場合、その新しい変更に対してこのループを起動するには改めて(b)を満たす新しい 明示指示が要る(過去に同種の手順の並びが何度繰り返されていても、それを理由に以後の別の変更にまで 同じ許可が及ぶわけではない)。このゲートはループの新規起動時にのみ適用され、一度起動したループの 内部で指摘対応(手順2)を経てレビュー実行へ戻ること自体はこのゲートの対象ではない(手順2・手順3の 反復は同じ起動の続きであり、新規の起動には当たらない)。

(a)(b)を満たしていても、この変更が視聴・視認等ユーザー自身の確認を受入条件とする種類のとき (MMD視聴確認が要るチューニング等)は、その確認が済むまでこのループを起動しない。

ゲートを通過したら対象確認を行う: git status --short --untracked-files=all と差分で対象を 把握する。レビュー対象がなければその旨を伝えて終了する。

レビュー依頼に含めるべき内容(レビュアーに依らない共通要件)

各スキルはレビュー実行でレビュアーを起動する際、以下を必ずレビュー指示文に含める(起動作法・記号規約等の レビュアー固有の契約は codex-review-loop・fable-review-loop・opus-review-loop それぞれに別途ある(後二者は共通部分を review-loop-subagent に置く)):

• 【最優先】この変更の要件と目的(品質基準)を冒頭に明記する: 何を達成するための変更か、 満たすべき品質基準は何かを先に伝え、レビュアーに目的に照らして評価させる。手段(差分の表層)だけを 見せて文法的な正否を問う形にしない。目的が伝わらないとレビューは表層チェックに堕し、設計が目的を 満たしているかの検証にならない。呼び出し側は、レビューを回す前にまず修正の要件・目的を自分で 言語化してからプロンプトに載せる(これは下記の手順2で対応する側が短絡修正を避ける大前提とも一体)。 目的の記載が実質的に無ければレビュアーは差し戻す: 要件・目的(品質基準)の記載が無い、または 一言だけで何を達成するための変更かが実質的に読み取れないレビュー依頼を受け取ったら、レビュアーは 本レビューを進めず、目的の記載が無い旨を明示して差し戻す。差し戻し(本項に限らず、各スキル固有の 起動契約やレビュアー自身の定義が定める差し戻し——禁止記号違反・読み方の指定など——も含む)を 受け取った呼び出し側は、次のラウンドで同じ内容のまま再依頼せず、指摘された不備を修正してから 再依頼する
• 作業ディレクトリ(リポジトリルート絶対パス)、レビュー対象範囲、差分の比較の基点(レビュアーは 差分を自分で取得するので、何との差分を見るかは呼び出し側が指定する)
• レビュアーが読める範囲を狭めるな(読む量・読み方も指定するな): 変更箇所(対象範囲)は伝えるが、 レビュアーはリポジトリの任意ファイルを読める前提で、関連ソース(フック・呼び出し元・ 仕様書など)を必要なだけ読んで主張を検証してよいと明示する。読める範囲を差分に閉じると、 周辺との整合や実装の実挙動を「確認不能」として保留し、収束を妨げる。プロンプトは「差分を レビュー」でなく「この変更を、関連ファイルを読んで検証してレビュー」と書く。どこまでどう読むかは レビュアーの判断に委ね、読む量・読み方を指定しない——「該当ファイルの全文を読め」と課す向きも、 「全文は読まず関係する節だけを絞って読め」と削る向きも等しく禁止。参照先の節を挙げること自体 (常設観点が求める規約の該当節など)は所在の情報であって指定ではない。所在の情報と削る指定の 分かれ目は、読む先の所在を足しているか、レビュアーが読むはずだった範囲を減らすよう求めているか (レビュー依頼に含めてはならない内容参照)
• 呼び出し側が『自分は対応済み・転記済みと思っている項目』だけに検証対象を絞るな: 原本との 突き合わせ・網羅性確認など「対象全体のうち抜け・誤りがないか」を問う場面で、呼び出し側 (メインの Claude)が「ここは大丈夫なはず」と自分で信じた一部の項目だけを挙げてレビュアーに 確認させてはならない。呼び出し側の思い込みが誤っている箇所こそ見逃される。プロンプトには 対象の全体(原本・全項目一覧・変更差分の全体)そのものの所在を示し、「そこに含まれる全項目を 一つずつ突き合わせ、抜け・改変・不整合がないか全項目について報告せよ」のようにレビュアー自身に 全項目を列挙・照合させる。呼び出し側が独自に絞った部分集合をチェックリストとして渡すな。 万一プロンプトの他の部分に対象を絞る記述が紛れ込んでいた場合、レビュアー側は本条項を優先し 対象全体を検証する(絞り込み側の指示より本条項が上位)。 ただし本条項は、網羅性そのものが問いで、かつ機械的検査でも呼び出し側のスキャンでも 確定できない場合にのみ適用する: 機械や自前スキャンで網羅を確定できる項目は レビュー依頼に含めてはならない内容のとおり呼び出し側が確定させ、レビュー対象から外す (本条項が禁じるのは呼び出し側の思い込みによる絞り込みであって、実行済みの機械的検査・ スキャンの結果による除外ではない)。除外を主張できるのは、何を母集団としたかと、どの手順で 判定したかを依頼文に明示でき、その手順自体が網羅を確定させる場合に限る。手順を示せない場合や、 候補を拾うだけで網羅を確定させない抽出は除外の根拠にならず、本条項がそのまま適用される
• 「レビューのみ。ファイルを編集するな(修正は呼び出し側が行う)。テスト・静的検査・ リンク検査などの検証ツールも実行するな(指摘の検証はコードの読解と読み取り専用コマンドの確認 だけで行う。検証はレビューループの外で別途担保する)」
• 【常設観点】次の観点を毎ラウンド確認させ、該当があれば指摘(=収束を妨げる)とする。大半は 規約の正本が docs/conventions/ 配下にあり、レビュアーに該当ファイルを読ませて照合させる (日本語表現の自然さのみ、正本ファイルとの突き合わせでなくレビュアー自身の言語判断で確認させる)。 観点ごとに、候補の抽出を呼び出し側が担うか列挙ごとレビュアーに渡すかは レビュー依頼に含めてはならない内容の3分割に従う。 以下の7点は現時点で頻繁に該当する規約を具体的な参照先として固定するが、docs/conventions/ 配下は 追加・改編されうるため、これらに加えて「docs/conventions/ 配下を確認し、この変更に関係する 規約があれば読んで照合せよ」ともディレクトリ単位で伝え**、以下の固定列挙に無い新規の規約が 突合せから機械的に漏れ続けることを防ぐ。最初の4点は対象の種類(コード・コメント・docstring・ テスト・仕様・コミットメッセージ)に依らず確認させ、残りの3点はそれぞれ対象が該当するとき—— 恒久仕様書、CLI ツール(tools/ 配下)、実装計画書——のみ確認させる:
  • 成果物衛生の規約適合(対象の種類に依らず確認): この変更が docs/conventions/artifact-hygiene.md (作業過程参照・個人情報・環境固有情報・秘密情報・自明な内容やコードの逐語的な書き写しの混入禁止の 正本)に適合するかを確認させる。変更がこれらに無関係なら触れなくてよい。
  • 用語規約表との整合(対象の種類に依らず確認): この変更が 禁止・注意表記 (禁止・注意表記とその正しい表記の正本)の表に適合するかを確認させる。判定は表そのものとの 突き合わせで行い、「他の文書にも同じ表記がある」ことを適合の根拠にしない(転記元も表に反する 誤りを持つ場合があり、他文書との一致は正しさの証明にならない)。変更がこの表に無関係なら 触れなくてよい。
  • 日本語表現の自然さ(対象の種類に依らず確認。正本ファイルとの突き合わせでなくレビュアー自身の 言語判断で確認させる): この変更が新たに導入する日本語の語(工程名・ラベル・メッセージ文言・ 識別子の日本語表記等)をまず列挙させ、各語について一般的に使われていない造語や不自然な 言い回しが無いかを判定させる(新規に導入する語が無ければその旨を述べさせる。列挙という 検証可能な中間成果を伴わない「問題なし」は、実際に語を拾ったのか素通りしたのか呼び出し側が 区別できないため認めない)。用語規約表・各モジュール/ツールの仕様書等の正本に既に定義済みの 術語(用語規約表が意図的に「正」と定める語を含む)は対象外とし、どの正本にも定義の無い新出語 だけを判定対象とする(意図的な専門語を毎回誤検出しないため)。用語規約表(直前の観点)は 既知の禁止語との機械的突き合わせに留まるため、表に無い新規の不自然な表現はこの観点で別途拾う。 該当すれば具体的な語を挙げて指摘とし(=収束を妨げる)、単純な言葉の好みでなく「一般的に 使われているか」で判断させる。
  • 層タクソノミー・依存方向の規約適合: この変更が docs/conventions/layering.md(層の責務・物理配置・ 依存方向・参照依存・フォーマット層設計原則の正本)に適合するかを確認させる。どの観点が 関わるか——コード変更なら層の責務分離と層間の依存、ドキュメント変更なら文書間の参照依存——だけを 示し、適合判定の規準はlayering.md の各節(層タクソノミー・物理配置・フォーマット層共通の設計原則・依存方向と循環依存の禁止)に委ねる。変更がこれらに無関係なら触れなくてよい。
  • 恒久仕様書の記述範囲(対象が恒久仕様書——定義は docs/conventions/document-authoring.md §1——の ときのみ確認させる。一時ドキュメントは触れなくてよい): この変更が恒久仕様書の記述範囲(恒久仕様書は到達状態 のみを規定し、導入の時系列・ロールアウト過程を書かないこと、スキル文書は実行するエージェント向けの 指示に限り編集者向けの構造説明を書かないことの正本)に適合するかを確認させる。変更が恒久仕様書で ないなら触れなくてよい。
  • CLI インターフェース規約適合(対象が tools/ 配下の CLI ツールのときのみ確認させる。他の対象では 触れなくてよい): この変更が docs/conventions/cli-interface.md(機械利用の起動・出力チャネル・ イベントストリーム・終了コード・自己記述/入力検査・横断統一名・キャンセル/出力原子性の正本)に 適合するかを確認させる。各ツールが提供する適合の具体は自分の仕様書が定めるため、未導入の項目を 違反としない。変更が CLI 契約に無関係なら触れなくてよい。
  • 実装計画書の粒度と根拠(対象が実装計画書のときのみ確認させる。他の対象では触れなくてよい): この変更が 実装計画書の粒度(実装計画書は判断を先送りせず具体値まで確定し、かつ 実装コードの丸写しにしないことの正本)と 実装計画書が示す根拠(仕様書の引用だけでは 計画の根拠にならず、前提ごとにコードで確かめた結果を示すことの正本)に適合するかを確認させる。 後者では、計画が依拠する前提ごとに書かれた確認結果が実体を伴うか——出典の言い換えに留まっていて コードで確かめた事実になっていない前提が残っていないかを判断させる。変更が実装計画書でないなら 触れなくてよい。
• レビュー対象がプロダクトコード・ツールの挙動に関わる場合、関連する仕様書(該当モジュール/ツール 直下の仕様書、および必要なら docs/specs/ 配下)を読んで整合を確認せよと伝える。呼び出し側が 特定の仕様書ファイル名を固定で列挙しない(モジュール構成は変わりうるため。所在は各モジュール/ ツール直下という規約自体をレビュアーに伝えれば足りる)。
• 出力契約: 「指摘があれば file:line＋内容＋根拠で列挙する。指摘が一つも無い場合は、各観点について 何を検査しどの実装/仕様と照合して問題なしと判断したかを観点ごとに具体的に述べ、その確認結果を 伴わせた上で指摘が無い旨を結論する(観点ごとの確認結果の実体を必ず伴わせる——確認内容の無い 『問題なし』『指摘なし』の一言だけの応答は不可。実体があればゲートで検証でき監査証跡になる)」
• 2ラウンド目以降は前ラウンドの文脈:「前回これを修正した(要約)」「これは誤検出として理由Xで 却下=反証した(再掲不要)」「これは実在するが軽微なのでトレードオフ理由Yで受容したい(認否を求む)」 「これは指示の範囲外(スコープ外)として却下した(理由Z)」を明記し、解消済み/反証済みを蒸し返さない よう伝える。受容はレビュアーの認否を得るため必ず提示する。スコープ外を理由にした却下についても、 レビュアーにその主張を無批判に受け入れさせず、対象に含める合理性(指示の具体例・目的が実際にそれを 要求しているか)があると判断すれば理由とともに再指摘せよ、とレビュー依頼に明記する。 あわせて、既存箇所であることを理由にした却下は指示が既存箇所を名指ししていなくても再指摘の 対象だ、ともレビュー依頼に明記する(却下ゲートが、既存箇所であることを理由にした却下を 禁じているため。この一点だけは「指示の具体例が要求するか」の物差しで判定させない)

レビュー依頼に含めてはならない内容(レビュアーに検査作業をさせない)

レビュアーに割り当ててよいのは判断のいる論点だけである。検査——網羅列挙・総当たりの 突き合わせ・実在確認・書式照合など、決まった手順をなぞれば答えが出る作業——を割り当ててはならない。 検査は実装者(呼び出し側)と機械の仕事であり、レビュアーに渡すと1ラウンドの所要が数倍に膨れる。 とくにこのループはレビュアーに検証ツールの実行を禁じているため、機械が確定できる項目を依頼に残すと ツールを使えないまま読解で代行させる二重の浪費になる。

レビュー依頼を組み立てる前に、確認したい項目を次の3つに仕分け、(3)だけをレビュアーに渡す:

1. 機械が確定できる項目(リンク先・アンカーの実在、テストの成否、静的検査、書式・命名の機械照合 など) → 呼び出し側が docs/conventions/verification.md の該当検査を レビュー起動前に実行して確定させ、依頼文には結果だけを「検査済み・レビュー対象外」と明示して 伝える。品質基準にも観点にも入れない。
2. 網羅列挙・総当たりの突き合わせ(全変更ファイルを規約の各要点へ一つずつ当てる等) → 呼び出し側が読み取り専用コマンドや .scratch/ の使い捨てスキャンで済ませ、母集団(何を全体と したか)・判定手順・違反候補の一覧をそろえて依頼文に載せる。レビュアーには再列挙でなく、挙がった 候補の判断を求める。手順が網羅を確定させない(候補を拾うだけの)ときは母集団の所在も渡し、 『検証対象を絞るな』条項のとおり列挙自体をレビュアーに任せる。
3. 判断のいる論点(この設計は目的に対して妥当か、この構造変更で意味・所属関係が壊れていないか、 この線引きは規約の趣旨に合うか、この日本語は自然か 等) → レビュアーに問う。対象範囲は差分の 該当箇所に絞って示す(そこから先、周辺のどこまでを読んで裏取りするかはレビュアーの判断)。 上記の常設観点も観点ごとにこの3分割を適用する: 機械やスキャンで候補を確定できる部分 (用語規約表との突き合わせ等)は上記1・2へ回して候補一覧を渡し、レビュアーには候補の判断を求める。 ただし列挙そのものが語義の判断である観点(日本語表現の自然さの新出語列挙)は、列挙ごとレビュアーに 残す——呼び出し側が候補を絞ると、自分が不自然だと気づけなかった語が構造的に落ち、その観点の 目的が失われる。

具体的に禁止する書き方:

• 「該当ファイルの全文を読んで検証せよ」「全文を通読せよ」など読む量を課す指定と、 「全文は読まず関係する節だけを grep で絞って読め」など読む量・読み方を制限する指定 (任意ファイルを読める旨は伝えるが、どこまでどう読むかは委ねる)
• 「変更されたファイルを自分で列挙し、全項目を一つずつ突き合わせて全項目について報告せよ」など、 上記1・2で確定できる網羅検査の丸投げ(例外は上記『検証対象を絞るな』条項の適用条件を 満たす場合に限る)
• 検証ツールが確定させる事実(リンク先・アンカーの実在等)を品質基準・観点に入れること

問う論点とレビュー対象を絞れない依頼は、依頼の設計が誤っている(絞るのは問う論点であって、 裏取りのために読める範囲ではない)。対象が大きいときは、依頼から検査作業を外して判断のいる論点 だけにする(判断のいる論点自体は間引かない)か、対象自体をモジュール単位で分割して複数ラウンドに 分ける。分割してよいのは論点が独立していて、同じ文脈の 読み直しを各ラウンドに生まない場合に限る(分割によって、変更をまたぐ不整合がどのラウンドの 視野にも入らなくなるなら分割しない)。

1ラウンドが時間内に終わらないとき

時間切れ(stall・wall-cap 等)を理由にレビューの精度を落として所要を縮めることを禁止する: 常設観点を減らす・問う論点を間引く・対象の一部を自分の判断で「確認済み」として 外す・レビュアーが読める範囲を狭める、はいずれも禁止形。時間切れは1ラウンドで見せた量が 多すぎたサインであって、見るべき内容が減った証拠ではない。

代わりに次の順で1ラウンドを小さくする:

1. 依頼文に残った検査作業を3分割のとおり呼び出し側で確定させて外す(判断のいる論点が 減らないため精度は落ちない。外せるのは除外を主張できる条件を満たす項目に限る)。
2. 分割条件を満たすなら対象を複数ラウンドへ分ける(対象全体は分けたラウンドの どれかで必ず見る)。常設観点は各ラウンドですべて適用する(対象が小さくなっても観点は減らない)。
3. 分割できないなら一存で削らず、対象の大きさと分割できない理由をユーザーに諮る。

1ラウンドが時間内に収まらないこと自体が作業粒度の過大を示す。独立に検証・コミットできる 複数の責務を1ステップにまとめていないか見直し、以後は1ラウンドで見きれる大きさへ分割する。

手順2: 照合・仕分け

レビュアーの各指摘を該当コード(必要なら仕様書)と突き合わせて判定する:

• 【大前提1】指摘を盲目的に全反映しない。まず実コード・仕様で検証する: レビュアーの指摘は鵜呑みに せず、対処する前に実コード・仕様で確認する(再現できる種類なら実環境でも確かめる)。指摘が 前提する挙動が本当に起きるか、既存の機構で既に防げていないかを自分で確かめる(例: 「この入力が 素通りする」と言われたら、後段の別チェックが既に弾いていないか辿る)。確認した結果は下記の 四分類(修正/反証/保留/受容)で仕分ける(各分類は下記の定義に従い、ここでは別の分類を設けない)。 検証せず反射的にコードや条件・テストを足すと、冗長な小手先や肥大化を生む(例: 既存の経路で 既に弾かれる入力へ重複チェックを足すことや、対応不要の指摘にテストを増やすことは、いずれも不要)。
• 【大前提2】短絡修正をせず根本で断つ(文言・個別ケースの追いかけをやめる): 各指摘に対処する前に、 まずこの修正全体の要件と目的に立ち返る。指摘の表面(その入力で deny/ask になる等)だけを黙らせる 小手先(個別ケースの精密分岐を足し続ける等)を重ねるな——設計が肥大化し本質を見失う。目的に照らして 根本(設計・方針)で対処し、同種の指摘がまとめて解消する形を選ぶ(「判断が難しい/曖昧な形は安全側に 倒して拒否」のような単純で目的に適う方針があれば、精密判定でなくそれを採る)。とくに同系統の指摘 (ある境界条件の説明を各所で直す、ある分岐の言い回しを毎ラウンド調整する等)が複数箇所・複数ラウンドに わたって出る、または効果に不相応な細部(文言精密化など)が続くときは個別パッチを続けるサイン: まず 目的に立ち返り「この指摘群は目的(の安全・正しさ)に効くのか、文言の磨き込みか」を判定し、(a)根にある 構造原因を一手で消す(病的ケースを生む値をクランプして条件分岐と説明自体を不要にする等)か、(b)誤検出 なら反証・実在するが軽微なら受容で閉じる。毎ラウンド受け入れて直し続けるのは禁止。
• 【大前提3】重大度×発生確率で重み付けし、軽微なら『受容(直さない)』も選ぶ。指摘に単純追従しない: 各指摘を「目的(の安全・正しさ)への実害 × 現実の発生確率」で測る。検証・指摘するエッジケースは 現実的に起こりうるものに限る: 実際の呼び出し元・信頼境界から起こり得ない入力(例: スキル自身が 固定で渡す引数が非数値・巨大値になる等)は検証も指摘もしない。実害が大きい/確率が高いものを優先し、 実害も確率も小さい指摘は、修正コスト(複雑化・肥大化・ラウンド増)と実害×確率のトレードオフを 判断において考慮し、見合わなければ『受容(直さずリスクを受け入れる)』を選ぶ。修正が常に正解では ない。レビュー依頼プロンプトにも比例性を求める: レビュアーに、現実に起こり得ないエッジの精密化や 文言の好みでなく、目的(の安全・正しさ)に効く欠陥に絞るよう明記する。
• 【大前提4】判断の主体は自分(レビュアーはレビュー補助であって決定者ではない。言いなりにならない)。 これは全レビューに共通。加えて、スキル/仕様などの判断ガイド文書のレビューに限り: その文章は状況に 応じて判断するためのガイドで機械的手順書ではないので、判断に委ねる箇所の曖昧さ(「数ラウンド」 「軽微」等)は意図的に許容し、数値の厳密化・曖昧さの一律排除・全分岐の網羅を求める指摘は反証する。 この曖昧さ容認はコードのレビューには適用しない: コードはアルゴリズムなので、正しさ・境界・精度は きちんと詰める(曖昧さの容認は禁物)。
• 【大前提5】開発支援ツール(スキル・hook・watchdog 等の補助ツール)のレビューはエッジケースを 過度に追わない: スキル文書・フック・補助スクリプトなど開発を支える道具は、本来の開発 (プロダクトコード=mmd-toolbox 本体・各CLI)を進めるための手段であって目的ではない。 実害のないエッジケースの精密化や、起きても害の小さい不具合への過剰な作り込みに時間をかけて 本来の開発が滞るのは本末転倒。これらのレビューでは比例性をさらに強く効かせ、(a) 現実に起こり得ない/ 起きても無害なエッジは検証も修正もしない(反証または受容で閉じる)、(b) 直すのは実際に開発を止める・ 誤った結果を生む欠陥に限る。この比例性は【大前提4】のコード曖昧さ非容認に優先する: 補助ツールのコードであっても、無害なエッジの境界・精度を詰めることは過剰とみなす(プロダクトコードの 正しさ・境界・精度はきちんと詰める)。 **【却下ゲート(ハードルール)・補助ツール限定のスコープ基準】補助ツール(スキル・hook・watchdog 等)の レビューに限り適用する。修正を採用する前に「この修正は、指示が示した具体例・変更の目的が"実際に要求した 範囲"か」を問う。指示が示していないケース——別ツール・別フラグ・別コマンド形・エッジ変種など——への 対応は、レビュアーが指摘しても自分が思いついても、たとえ実コードで再現しても【スコープ外=却下】する (誤検出なら反証・実在するが軽微なら受容で閉じ、実在し軽微でないが範囲外の問題は保留=別件として ユーザーに諮る。ただし変更の前提そのものを崩す指摘は本ゲートの対象外で、軽微と見て受容せず 下記の【保留する】へ回す。また、指摘された不備が、この変更が持ち込んだのではない箇所(既存箇所)に あることは、本ゲートの却下理由にならない。新旧の別は対応要否の基準ではないので、既存箇所の指摘も 他と同じく仕分けて対応する。書き換えだけで済み設計判断を伴わない低コストの是正を、「既存の書き方に 倣っただけ」「指示が既存箇所まで要求していない」を理由に却下することを禁止する。例外は、対応が 別タスクの修正として切り出した方が適切な場合——対応が独立した責務・別モジュールに及び、この変更の 差分に混ぜるとレビュー対象が二重になる場合——に限り、下記の【保留する】へ回して別件としてユーザーに 諮る(黙って見送らない)。本条項が扱うのは、既にある不備をどこまで直すかであって、指摘の対象そのものを 指示が示していないケース——別ツール・別フラグ・別コマンド形・エッジ変種——へ広げる対応は本条項の 対象外であり、上記のとおり【スコープ外=却下】する)。物差しは「指示の具体例が要求するか」で あって「再現するか/丁寧か」ではない(再現性は 修正の十分条件でない。ただし直前に述べた既存箇所の不備の是正はこの物差しの例外)。指示が要求した当の対策(例: 当の許可プロンプトの抑制そのもの)はスコープ内なので 必ず実施する——「直さなくても安全側」を理由に却下しない(却下対象はあくまで指示が要求していない範囲外の 対応)。このゲートはレビュアーの指摘だけでなく自分の実装・自分の差分にも等しく適用し、1ラウンドで指示 範囲を超えて差分・対応コマンド・対応フラグが増えたら、スコープ逸脱のサインとして立ち止まる。 【行数ハードリミット】hook の修正は、その hook 固有の"コアロジック"(判定・処理の本体)の変更行が 着手時点から通算30行以上になったら無条件で却下する(過剰作り込み・スコープ逸脱・エッジ追従のサイン。 典型は、些細な事象に対しコアロジックが複数ラウンドのエッジ追従で膨れ続けること)。スケルトン(shebang・ import・標準入力/標準出力の入出力配線・main 等の定型ボイラープレート)とテストコード(selftest)は、新規 ファイル作成時も含めこの30行に数えない。プロダクトコード・無関係な変更・着手前から存在する未コミット 変更も数えない。ただしロジックを無駄に別ファイルへ切り出す等、ファイルの新規作成でこの制限を迂回する 行為は禁止する(コアロジックは1ファイルに素直に置く)。 【逸脱を諮るな・ミニファイ禁止】コアロジック30行未満(29行まで)・通常の可読体裁・正しさ(誤りゼロ)は両立必須のハード 制約であり、二者択一ではない。コードは普段どおり可読に書く——ミニファイ(複数文の1行化、import や try/except の1行化、空行・docstring・改行の削除、ワンライナー詰め込み等、可読な書き方から外れた行数稼ぎ) で30行未満に収めても"収まった"とは扱わない。コアロジックが可読体裁で30行以上になるなら、行数を稼ぐのではなく やること自体を減らす(スコープ縮小・アルゴリズム簡素化・不要ロジック削除・別手段の再検討)。リミット緩和の 許可を求める/保留として諮る/「30行と正しさ」を選択肢や質問として提示すること自体を禁止する。両立できる まで設計を見直す。 このゲートはプロダクトコード(mmd-toolbox 本体・各CLI)には適用しない: プロダクトコードは指示の 表層を超えても、正しさ・境界・精度を必要なら詰める(大前提4)。スコープ基準で削るのは補助ツールに限る。
• 修正する(妥当 = 実コードで再現する/仕様に照らし要対応。補助ツールではさらに大前提5の却下ゲート (スコープ基準)を通過すること——指示の要求範囲外の対応は再現しても修正でなく却下へ回す。 プロダクトコードはゲート対象外で、正しさ・境界・精度を必要なら詰める): 上記の前提で根本対処を適用する(必要なら回帰テストを追加する。検証 (docs/conventions/verification.md の各検査)は、レビュー ループの中では行わない——検証はレビューループの外で別途担保する)
• 反証する(誤検出 = 事実誤認・不可能・対処済み・仕様で意図的にそう決めた): 修正せず、却下理由を次ラウンドのプロンプト文脈でレビュアーに伝え、最終報告(手順4)に含める (別ファイルには記録しない)
• 保留する(要ユーザー判断 = 仕様変更・設計トレードオフ・方針判断): 仕様変更・設計トレードオフ・方針をClaudeの一存では決められないため、保留して要ユーザー判断として終了する。 指摘が、実装中の変更の前提(計画書・仕様書が根拠として述べている事実)そのものを崩す場合は、 この分類へ回す: 前提が崩れた方針を「決定済みだから」で実行し続けることは、修正/反証/受容の どれでもない。指摘の裏取りで前提の誤りが確認できたら、方針を続行せず、誤っていた前提・その方針を 実行した場合に起きること・自分が正当と考える代案を示して諮る。本項は【大前提5】の却下ゲート (スコープ基準)に優先する——前提を崩す指摘は「指示が示していない範囲」の形で届くが、指示された 当の方針の土台を問うものなので、スコープ外として却下してはならない
• 受容する(実害はあるが軽微 = 発生確率も影響も小さい): 修正コストと実害×確率のトレードオフを 判断において考慮し、『直さない(受容)』という判断を立てる(反証=誤検出 とは別。実在は認めるが 直さない判断)。勝手に受容で打ち切ってはならない。その受容の判断(とトレードオフの理由)を次ラウンドの プロンプト文脈でレビュアーに伝え、認めさせる: レビュアーが受容を認める(再掲しない/同意する)ことで 確定する。最終報告(手順4)にも含める(別ファイルには記録しない)。レビュアーが同じ理由で受容を拒み 再掲し続けるなら受容は不成立で、一存で打ち切らず千日手としてユーザーに諮る(自分の都合で軽微認定して 握り潰さないための歯止め)

手順3: 終了判定

上記終了条件のいずれかに該当すれば該当する区分(収束/千日手/要ユーザー判断)で終了する。 いずれにも該当しなければ次ラウンドへ(呼び出し元スキルのレビュー実行へ戻る。修正点・却下理由・受容理由を文脈として渡す)。

手順4: 報告(日本語)

修正した指摘・反証した指摘(理由つき)・受容した指摘(理由つき)・保留(要ユーザー判断)・ 終了理由(収束/千日手/要判断)をまとめて提示する。コミットはしない(コミットは別途ユーザーの 指示で commit スキルに委譲)。

注意

• レビュアーの指摘は実コード・仕様書で裏取りしてから残す/落とすを決める(誤検出除去が後段の役目)
• 千日手は「Claude が正しいと考える反証」をレビュアーが受け入れないケースが典型。 無限に押し問答せず、双方の主張を要約してユーザーに委ねる