omh-ralplan-driver

OMH Ralplan Driver — ループの進行

ループをディスパッチするオーケストレーターは、omh-ralplan とあわせてこのスキルを読み込んでください。Planner／Architect／Critic ワーカーが読み込むのは omh-ralplan です。こちらは各 delegate_task 呼び出しの中でワーカーが行うことを扱います。このスキルでは、ディスパッチャーであるあなたが行うこと、つまり準備、ディスパッチ、要点の整理、レビューについて扱います。

この2つのスキルは、想定読者も役割も異なります。統合しないでください。ワーカーのコンテキストは貴重です。ディスパッチャーの手順書を、すべてのサブエージェントに持ち込むべきではありません。

このスキルが必要な理由

厳密なオーケストレーションを伴わない Ralplan は、真実ではなく、内部整合性へと収束します。Planner／Architect／Critic の三者は相互にチェックし合いますが、何に取り組むよう指示されたかについて一貫した見解を導き出すだけです。そこには、誤った前提、古い情報源、存在しない制約、そしてユーザーがすでに決着をつけた質問も含まれます。

次のことを見渡せるのはオーケストレーターだけです。

• ディスパッチ前に原則を定めます。
• 前提の見直しを認めるコンテキストパッケージを作成します。
• サブエージェントが事実として引き継ぐ前に、実際の状況と関連する仕組みを検証します。
• パッケージをユーザーとともに反復的に改善します。重要な要件の半分は、調査からではなく、ユーザーの実体験から得られます。
• レビュー担当者向けの補助情報を取り除き、合意内容を正式な成果物にまとめます。
• ユーザーに渡す前に、最終品質チェックを行います。

以下で挙げる失敗の大半は、ディスパッチ前に起きます。準備が品質を生みます。 要点の整理とレビューで品質を保ちます。ループそのものは、その間をつなぐ計測機能の整ったエンジンにすぎません。

Ralplan を使う場合と、自分で考える場合

次のような作業では Ralplan を使ってください。

• 問題を正当に分解する方法が複数ある。
• サブエージェント間で徹底すべき、重要な原則がある。
• オーケストレーターだけでは見落とす可能性がある、横断的な懸念事項がある。
• ユーザーが、提案を一度に一つずつ確認するやり取りに陥る可能性がある。

作業が単一ファイル、単一の意思決定、または明白に解決できる内容の場合は、Ralplan を使わないでください。過剰な対応も、それ自体が失敗の要因です。目標が曖昧な場合は、まず omh-deep-interview を使ってください。

5段階の手順

1. まず原則を定める（まだ存在しない場合）

原則を定めずに Ralplan を行うと、もっともらしい理屈で組み立てられたナンセンスが生まれます。Planner／Architect／Critic の三者は、真実ではなく内部整合性へと収束します。原則は外部の基準となります。

出発点としては、プロジェクトのルートに小さな PRINCIPLES.md（エントリー数は最大15件）を置くのが適切です。各原則は、判断の基盤となるもので、どのような失敗を防ぐかを明記します。このファイルを、すべてのサブエージェントが必ず読むファイルに含めてください。

原則がまだ存在しない場合は、まず原則を定めてください。簡単な草案でも、原則のない Ralplan より優れています。ファイルの内容は改善を重ねられますが、基準となるもの自体は必ず存在させてください。

2. コンテキストパッケージを作成する — プロンプトだけでは不十分

コンテキストパッケージは、docs/design/<domain>/context.md に置く更新され続けるドキュメントです。この実行で最も重要な成果物です。Planner が読み、Architect が読み、Critic が読みます。パッケージの質が低ければ、サブエージェントの能力がどれほど高くても、立場の質は低くなります。

必須セクション：

• 設計上の問い。 1 文で示した後、2～3 段落で詳しく説明します。出力が何を実現し、何を尊重し、何の基盤となるのかを明記します。

• 成果物タイプの宣言。 冒頭付近に 1 文で記します。「これは要件ベースではなく、設計ベースです」またはその逆です。これにより、オーケストレーターは次元の草案を作る前に方針を決める必要があり、サブエージェントにはどの規律のルールを適用するかが伝わります（Pitfall 15 を参照）。追加する手間はわずかですが、誤った枠組みに沿って次元を草案する前に、成果物の形が間違っている問題を明らかにできます。

• サブ次元。 立場で扱うべき内容の初稿です。絶対的なものではありません。以下の META の問いにより、Critic はこれらを見直せます。

• 制約。 この実行で尊重しなければならない原則、指示、確定済みの過去の決定です。

• 対象外。 この実行で設計しない内容です。

• 必読資料。 絶対パスのみを使用します。サブエージェントは cd できず、要約をもとに作業することもできません。カテゴリごとにまとめます。原則と指示、参考資料／先行事例、対象プラットフォーム、既存コード、コンテキストパッケージ自体です。

• 意見が分かれる問い。 安易な合意が最も起こりやすい論点を 6～8 個挙げます。Critic への種になります。網羅的である必要はありません。

• META の問い。 「これらは適切なサブ次元ですか？」これは Critic に枠組み自体への異議を認めるもので、Critic ができる最も重要な働きです。これがなければ、Critic は枠組みの中にとどまり、適合性を確認するだけです。

• 完了の定義。 具体的な出力基準です。「参考資料に何が欠けているか、また理想的なバージョンには参考資料にない何が含まれるか」を必ず問う項目を 1 つ含めます。

オーケストレーターはコンテキストパッケージの草案を作成してレビューし、ループを実行する前にユーザーと一緒に内容を確認します（Pitfall 10 を参照）。パッケージは品質を左右する重要な要素です。

3. 第 1 ラウンドは順次、第 2 ラウンドは並列

第 1 ラウンド：Planner → Architect → Critic の厳密な順序で進めます。それぞれが、必読資料と、それ以前の出力を読みます。それぞれがツールの応答内に直接書くのではなく、design ディレクトリに名前付きの成果物を作成します。

ファイル名の規則：

• stance-planner.md
• review-architect.md
• review-critic.md

第 2 ラウンドに進むのは、いずれかのレビュアーが APPROVE しなかった場合のみです。Planner が修正し、Architect と Critic が delegate_task(tasks=[...]) による一括呼び出しで並列に再レビューします。これにより、実行時間を大幅に短縮できます（ある定期実行では、第 2 ラウンドだけで約 100 秒の短縮を測定）。

第 2 ラウンドのファイル名には -v2 サフィックスを付けます。第 1 ラウンドの成果物は、ループの変遷を示す来歴としてディスクに残します。

3 者全員が APPROVE すれば、ループを終了します。それ以外の場合は反復し、収束しなければ注意事項を添えて最大 3 ラウンドまで実施します。

4. 生の出力をユーザーに渡さず、要点をまとめる

合意に達すると、Planner の最終的な立場の冒頭に、レビュアー向けのチェックリストである「Round 2 response map」セクションが含まれます。これは削除し、実質的な内容は残します。結果は、サフィックスなしの stance.md として保存します。来歴として、加工前の stance-planner-v2.md も隣に残します。

成果物が要件ベースの場合は、stance.md ではなく requirements.md に要点をまとめます。正規のファイル名は成果物の名詞に一致させます（Pitfall 15 を参照）。

また、ラウンドごとの集計、Critic が指摘した内容、主要な設計方針、MV の手順、ファイルへの参照を記載した合意サマリーを .omh/plans/ralplan-<instance-id>.md に作成します。これはオーケストレーター向けの短いサマリーです。grep で検索でき、セッションがローテーションしても残ります。

5. オーケストレーターによるレビュー後、ユーザーに提示する

オーケストレーター自身によるレビューは、ユーザーに何かを見せる前の最後の関門です。成果物は1つではなく、2つ作成してください。

• brief.md — ユーザーが読むものです。決定事項を最初に示します。約1～2ページです。 解決済みの決定事項を冒頭に置き、事前のディスパッチ前の会話からの逸脱を明記し、設計がどこに落ち着いたかを1段落で説明し、残された未解決の質問と次のステップを記載します。ユーザーはこれだけを読めば判断を下せる必要があります。何を決めるべきかを知るためだけに、詳細レビューまで読むことを決して強いないでください。

• <orchestrator>-review-deep.md — アーカイブです。内部のやり取り、詳細な推論、追従性の検証、実行方法に関する所見、視点の高度に関する補足、Critic が物語的に見抜いたことを記録します。後日の調査や、ユーザーが全体像を知りたいというまれな場面に備えて、ディスク上に保存します。既定では読まないものです。 以前の実行で <orchestrator>-review.md と呼ばれていたものに置き換わります。

brief は提出用、詳細レビューは記録用です。読者の異なる別々の成果物として扱ってください。

詳細レビューに記載する内容（以前と同じです）：

• これは私の基準を満たしているか。（はい／いいえと、その理由。）
• Critic が見抜いたことで、意外だったこと。
• 私が穏やかに異議を唱える点 — ユーザーと一緒に考える際に提起することであって、妨げになるものではありません。
• ユーザーが異議を唱えると予想する点 — 読む前に心構えができるように伝えます。
• 今回の実行で手法について学んだこと。
• 蒸留の過程で折り込んだ但し書き（あれば）。

brief に記載する内容（決定事項を最初に示します。P26 とテンプレートを参照）：

• ユーザーに求める決定事項を番号付きで示し、それぞれについて私の見解を添えます。
• 事前のディスパッチ前の会話から逸脱した点を具体的に記載します。
• 「設計がどこに落ち着いたか」を1段落で説明します。
• v2 または実際に使用した際の摩擦に持ち越す未解決の質問。
• 次のステップ。

詳細レビューが不十分なら、もう一度実行するか、原則を強化してください。自分の基準を下回る成果物をユーザーに渡してはいけません — 視点の高度に関する要約はこれに依存します。要約を検証するのが brief です。詳細レビューを、明快で決定事項を最初に示す brief にまとめられないなら、自分が持っていると思っている視点の高度には達していません。

詳細レビューのテンプレートは references/orchestrator-review-template.md、brief のテンプレートは references/brief-template.md を参照してください。

落とし穴（P1～P26）

以下は、オーケストレーターが繰り返し陥る失敗パターンです。どれも苦労して学んだものです。番号は連続しており、欠番はありません。

P1 — 後で作成するファイルを決して参照しない

delegate_task のコンテキストに「次にファイル X を作成します」と書いてから、ディスパッチしてはいけません。サブエージェントはそのコンテキストを読み、X を探して見つからず、タイムアウトするか、出力が壊れてしまいます。参照先のファイルは、それを参照する delegate_task をディスパッチする前に必ず作成してください。

P2 — タイムアウト ≠ 作業未完了

サブエージェントが「タイムアウトしました。API 呼び出しは 0 回です」と報告しても、実際には作業を完了し、数 KB の出力をディスクに書き込んでいることがあります。失敗したのは報告経路であり、作業ではありません。再生成する前に、まずディスクを確認してください。対象の出力ファイルは存在しますか？ 読み込んでください。作業はすでに完了している可能性があります。複数回の実行でこれが確認されています。真実を示すのはディスク上のファイルであり、ツールレベルのステータス文字列ではありません。

P3 — コンテキストサイズはすぐに膨れ上がる

Round 1 の各サブエージェントは、必須ファイルを読むだけで数十万単位の入力トークンを消費することがあります。サブエージェント3つ × 2ラウンドは、無視できないコストになります。軽減策：

• 補助ドキュメントが非常に大きく、二次的な読み物である場合は分割します。
• Round 2 のレビュアーには、すべてのファイルを再読させるのではなく、差分と v2 に対する見解を渡すことを検討します。
• 必須の読み物と役立つ読み物を正直に区別し、パッケージ内でもそれぞれ明記します。

P4 — 批判役がフレーミングに異議を唱える権限を持つようにする

これは最も重要な施策です。コンテキストパッケージに「現在のフレーム内で検討すべき点」しか列挙されていなければ、批判役はそのフレーム内にとどまります。META の問いを明示的に加えてください。批判役には、分解そのものにも異議を唱えられると伝える必要があります。

これにより、ひそかに欠落している原則――全員がそれを隠すフレームの内側にいたため、誰も言及しなかった原則――を見つけられます。権限を与えなければ、批判役は細部を見つけます。権限を与えれば、批判役はフレームを見つけます。

P5 — 争点となる問いを種として示し、網羅しようとしない

具体的な争点の種は6〜8個が適切です。それより少ないと批判役に心構えができず、それより多いと批判役が窮屈に感じます。

特に、「原則を全面的に監査し、上記のリストで終わらせないこと」と指示してください。 優れた批判役は、種として示した問いを超えて検討します。種は準備のためのもので、チェックリストではありません。

P6 — 懸念を指摘するより、具体的な対案を示す

優れた批判役は、「別の分解方法を検討してください」と言うだけでなく、具体的な代案（「X／Y／Z／Wの4つの次元を使う」など）を提示します。批判役へのプロンプトでは、この形式を求めてください。「代案を検討してください」という曖昧な表現では、回答も曖昧になります。

このパターンなら、第2ラウンドのプランナーは、批判役の意図を推測するのではなく、「この代案が妥当なのは、〜だから」と原則に基づいて採用または却下できます。

P7 — 原則に基づく採用を期待し、追従していないかを検証する

第2ラウンドでは、プランナーが批判役の提案を、それ自体の論理に照らして妥当だから採用したのか、それとも批判役がそう言ったから採用したのかを確認してください。具体的には、反実仮想による追従テストを行います。

反実仮想上の批判役が別の代案を提案していたら、この論拠でその代案を採用していたでしょうか。

プランナーの論拠がすべて反実仮想上の代案にも当てはまるなら、その採用は追従的であり、原則に基づく判断ではなくパターンマッチングです。一部の論拠が当てはまらないなら、その評価は選ばれた代案に固有のものです。つまり、原則に基づいて採用したことが確認できます。

このテストは、第2ラウンドの批判役へのプロンプトに含めてください。全文は references/critic-goal-template.md を参照してください。

P8 — 状態ファイルは git の対象外にし、計画ファイルはコミットする

.omh/state/<mode>--<instance_id>.json にあるインスタンスごとの状態は、セッション用の一時データです。記録対象の成果物は .omh/plans/<file>.md です。.omh/.gitignore では state/ を除外し、plans/ はコミットしてください。

P9 — 調査を割り当てる前に、グラウンドトゥルースが最新か確認する

コンテキストパッケージでサブエージェントに「グラウンドトゥルース」としてローカルのソースチェックアウト（ベンダーのリポジトリ、クローンしたライブラリ、外部プロジェクトなど）を参照させる場合、調査を割り当てる前に、そのチェックアウトが想定しているバージョンであることを確認してください。 サブエージェントは読んだ内容を忠実に引用しますが、main が upstream より数百コミット遅れているかどうかは判断できません。

ローカルのソースツリーを対象に調査を割り当てる前のチェックリスト：

cd <source-tree>
git remote -v                                          # confirm remotes
git fetch --all --tags                                 # update refs
git rev-list --left-right --count HEAD...@{upstream}   # ahead/behind
git describe --tags --abbrev=0                         # latest tag at HEAD

HEAD が調査の対象とするバージョンより大幅に古い場合は、作業を止めて、（a）ツリーを更新するか、（b）調査の対象を「HEAD 時点のツリーに含まれる内容」と明示し、バージョン固有の主張は検証不能と明記するよう指定してください。

必読資料にローカルのソースチェックアウトが含まれる場合は、コンテキストパッケージに「グラウンドトゥルースの鮮度」の小見出しを追加してください。コミット SHA と、設計対象の upstream バージョンとの関係を記録します。「グラウンドトゥルース＝<repo>/@bf196a3f」と記載されたパッケージは反証可能ですが、「グラウンドトゥルース＝<repo>/」と記載されたパッケージはそうではありません。

実行中に古い状態だと判明した場合は、黙って更新しないでください。判明した内容を共有し、（a）更新して調査を再実行する、（b）更新して調査ドキュメントをその場で修正する、（c）注意書きのバナーを付けて続行する、のどれにするかユーザーと相談して決めてください。

P10 — ディスパッチ前に、ユーザーとコンテキストパッケージをすり合わせる

読むだけで作成すると、ユーザーにしか挙げられない側面を見落とします。 システムを実際に使ってきたユーザーの経験からは、 どれだけソースを読み込んでも分からない要件が明らかになります。

進め方：

• 読み込んだ内容をもとにパッケージを作成します。ソースをもとに、下位の観点を明らかにし、論点の候補を洗い出します。
• ユーザーと一緒に確認します。次のように尋ねます。この分解で合っていますか？不足している観点はありますか？重み付けが足りないと感じる論点はありますか？
• その場で修正します。変更を記録します（「7つの観点から8つに変更。ディスパッチ前のコンテキストレビューで修正」）。そうすれば、Planner はすり合わせが行われたことを把握し、その内容を尊重できます。
• その後で初めてディスパッチします。

この手順を省くと、ディスパッチ前ならユーザーが2分で指摘できた観点の欠落を Critic が見つけ、ralplan のサイクルを1回余分に費やすことになります。

P11 — ユーザーがすでに決着させた問いを論点として提示しない

P10 に隣接するものの、逆方向の失敗パターンです。オーケストレーターは「Critic は何を問題にするだろう？」と考えて論点を作成し、ユーザーがすでに決着をつけた問いをうっかり再び持ち出してしまいます。

失敗パターン：ユーザーが ralplan の前の会話で、「目標は X の修正だけではなく、今後の Y に向けてより良いパターンを見つけることだ」と述べています。ところがオーケストレーターは、「新しいパターンが本当に必要なのか、それとも最小限の修正で十分なのか」という論点を作成します。この論点によって、ユーザーはすでに示した方針を再度弁護することになります。

進め方：

1. 論点を作成する前に、ユーザーがすでに決めたことを列挙します。 ralplan のきっかけとなった会話を読み返します。下書きに着手する前に、ユーザーが宣言、主張、または選択したことを書き出します。ユーザー自身が改めて問い直すまでは、これらを交渉の余地がない制約として扱います。

2. 各論点を、決着済み事項の一覧と照合します。 論点が決着済みの内容を再び問い直すものであれば、論点として記載しません。制約として記載するか、別の論点の前提にその方針を組み込みます。

3. 方針が決まった後の健全な論点は、「ユーザーが決めた方向性を前提として、その範囲内でどのような形が適切か？」です。 「ユーザーがその方針を選ぶべきだったのか？」ではありません。

4. レビューでユーザーからこの誤りを指摘されたら、表現ではなく、枠組みのレベルで修正します。 多くの場合、根本原因が同じ論点や制約がほかにもあります。修正済みと判断する前に、それらも確認します。

P12 — パスを含む目標をディスパッチする前に、ファイルシステムの構成を決める

コンテキストパッケージが参照するディレクトリ構成に、「整理したほうがよさそう」という気配がある場合（ディレクトリの乱立、場当たり的なサブディレクトリ、「v2」などのサフィックス、プロジェクトとインシデントの混同など）、まず整理し、その後でディスパッチします。

先にディスパッチしてからリファクタリングすると、次の問題が発生します。

• サブエージェントの出力が、削除予定のディレクトリに配置されます。
• 必読ファイルのパスを解決できなくなります。
• 再度全体を位置付けし直すことになり、磨き込みではなく第2ラウンドのやり直しが必要になります。

パスを含む目標をディスパッチする前のチェックリスト：

1. 目標が参照するディレクトリ構成を書き出します。
2. ディレクトリの乱立や命名のばらつきがないか、目視で確認します。
3. 問題があるように見える点があれば、ユーザーに尋ねます。ユーザーは以前から気になっていても、まだ指摘していないことがよくあります。ディスパッチ前は、そのことを尋ねる機会です。
4. 問題があれば、先にリファクタリングします。すべての絶対パスが新しい構成で解決できることを確認し、context.md をその場で更新します。
5. その後でディスパッチします。

補足：下書き中に整理を行うと、設計そのものに不足している観点が見つかることもよくあります。整理によって、設計が位置する概念的な枠組みが再構成されるためです。

P13 — 外部からの批評の前提を検証し、制約としてそのまま受け入れない

ralplan が外部からの批評（DM、バグ報告、レビューコメント、issue）に対応する場合、その批評には 診断（何が問題か）、処方（何をすべきか）、そして多くの場合 前提（現状が存在する「理由」についての、批評者が検証していない主張。「理由は Z だと思います」など）が含まれています。

未検証の前提を既定の制約として扱うと、幻の制約を中心にスタンスを組み立ててしまいます。この幻の制約に基づくスタンスは、一見正しく感じられ、内部整合性に関する ralplan のレビューも通過しますが、現実に直面したときに初めて崩れます。

徹底事項：

1. 外部の批評者が提示した、自分で検証していない前提すべてにタグを付けます。前提とは「現在のコードがそのような状態である理由についての主張」です。診断（何が問題か）や処方（何をすべきか）とは異なります。

2. コンテキストパッケージに 「検証すべき前提」 セクションを追加し、タグを付けた各前提について、主張の原文、批評者がその前提について述べた内容、提示された証拠（「なし／推測」であることが多い）、および Planner が検証のために開くべき絶対パスを記載します。

3. Planner に次の内容を明示的に指示します。設計の前提とする前に、すべての前提を検証してください。前提が誤っている場合はそう指摘し、実際の制約に基づいて作業をやり直してください。

4. Round 1 の Critic も、フレーミングへの異議申し立てとは別のテストとして、前提が根拠に基づいているか確認する必要があります。

このセクションの形式：

## Premises to verify (pre-Planner)

The critique this run responds to supplied these premises without
evidence. Verify each before designing around it.

- **Claim:** "<verbatim>"
  **Source:** <critic's statement>
  **Evidence supplied:** none / partial / speculation
  **Verify by opening:** <absolute paths>
  **If true:** the design honors constraint C<n>.
  **If false:** the design is free of constraint C<n>; revisit.

P14 — 必読資料には、ツリー内の関連する仕組みも含める

「3 件の APPROVE を獲得しても、なお間違っている」スタンスで最もよくある失敗は、Planner が、既存のコードベースですでに解決済みの関連問題に対して、新しい仕組みを設計してしまうことです。既存の解決策があることを誰も示さなかったため、サブエージェントは並列ビルドを設計しました。

作業を割り当てる前に、次の問いに照らして必読資料のリストを確認してください。

設計対象の問題に関連する問題を解決するコードが、このツリー内にすでに存在するでしょうか。存在する場合、設計に使わない可能性があっても、必読資料に含める必要があります。

特に、次のものを検索してください。

• tools/、agent/、cli/ にある同期／更新／マニフェストエンジン。
• *_sync.py、*_manifest*、bundled_* に一致するものや、名前に update／reset／migrate を含むもの。
• 対象領域に関係する既存の CLI サブコマンド。その実装には、設計を左右するモデルが含まれています。
• optional/、migration/、およびこの問題が過去に対処された場所。

コンテキストパッケージの作成中に、search_files で同期／マニフェスト／更新のキーワードを 2 分間検索するほうが、Round 2 でのやり直しや、外部の協力者が「システムにすでにあるため、自分の作業を取り下げました」という一言で崩すようなスタンスを世に出すより、はるかに低コストです。

現場の兆候： 関連する取り組みについて外部の協力者（PR、DM、issue）が「既存の何かに対応するために」作業を終了または方向転換したと一言述べた場合、見落とした関連する仕組みがある可能性が最も高いです。このような兆候があったら、スタンスを擁護する前に、そのシステムをツリー内で検索してください。 多くの場合、スタンスはその時点で成り立たなくなります。

P15 — 要件としてまとめる成果物には独自の位置づけがあります

「設計方針」と「要件ドキュメント」は異なる成果物です。 デフォルトの Planner テンプレートは設計方針を作成します。 成果物が要件（設計上の立場ではなく、技術に依存しない NEEDS）である場合は、次の 3 点を変更する必要があります。

1. 命名。 まとめた出力は stance.md ではなく requirements.md です。出典を示すファイルには引き続き <artifact>-planner.md ／ -v2.md を使います（テンプレートの命名との一貫性のため）が、ユーザーに渡す正式な ファイル名は成果物の名称に合わせます。

2. コンテキストパッケージの規律ルール（要件作成時の要となるルール）：

   • ルール — 機能ではなくニーズ。 良い例：「システムには、一人称の知識を永続的に保持することが求められます。」悪い例：「システムは me.md を使ってアイデンティティを保存します。」
   • ルール — すべての項目にインライン引用を付ける。 各要件には出典タグと、file:line 形式の引用、ギャップ引用、または原則と明示された失敗モードの引用のいずれかを付けます。
   • ルール — 捏造するくらいなら不足を受け入れる。 正直で短いものは、整っていて長いものより優れています。未解決の質問は未解決のままにします。要件での失敗モードは、完全性を装うことです。
   • ルール — ニーズと数・形式を分ける。 「ファイルが 3 つあること」は要件ではありませんが、「自己認識に関する知識を 3 つの異なる種類で持つこと」は要件となる可能性があります。
   • ルール — 類推による機能の要求を禁止する。 「製品 Z に機能 W があるから、私たちにも必要だ」は要件ではありません。
   • ルール — Critic はループを停止できる。 Critic の正当な判定は、「要件はまだ確定できません。先に必要なものは以下のとおりです」です。「まだ確定できない」という REQUEST_CHANGES は、欠陥のある成果物への APPROVE よりも望ましいものです。

3. 出典のオントロジー。 要件には、出典システムが実際に行っていること、行うべきだが行っていないこと（明らかなギャップ）、原則が要求しているが、稼働中のシステムではまだ実証されていないことを区別する出典タグが必要です。すべての項目にタグを付けてください。タグなしでこれらを混在させると、根拠が厚い箇所と薄い箇所が見えなくなります。

成果物が要件である場合は、エンジンコードに加えて、基盤やランタイムの成果物（スキル、プロンプト、規約、README）もサブエージェントに確認させてください。エンジンだけを読む要件作成では、証拠の半分を見落とします。実際の利用に根ざした成果物には、ソースコードと同じくらいの情報が含まれていることがよくあります。

P16 — ラウンド 2 で反事実的な追従テストを適用する

Planner がラウンド 1 で Critic の対案を採用した場合、その採用が原則に基づくもの（対案がそれ自体の理由によって成立する）なのか、追従的なもの（Critic がそう言ったから採用した）なのかを、具体的にテストします。

改良したテスト：別の Critic が別の対案を提示していたとしても、Planner の主張はその対案を正当化できるでしょうか？

• すべての根拠が当てはまる → 一般原則の引用であり、追従的です。根拠が不確かな場合は REQUEST_CHANGES とし、この案を採用した具体的な理由を求めます。
• 一部は当てはまり、一部は当てはまらない → 主張には具体性があります。原則に基づく採用と確認できます。
• 何も当てはまらない → 原則に基づく主張として、非常に強いものです。

このテストはラウンド 2 の Critic プロンプトに含めます。テンプレート全文は references/critic-goal-template.md にあります。

P17 — ユーザーとの対話が必要という判定は、ラウンド 1 で正当な判定です

ラウンド 1 の Critic が、サブエージェントだけでは根本的に解決できないオントロジー上の質問を提示することがあります。その場合に必要なのは、サブエージェントによる追加の推論ではなく、ユーザーによる原則に基づく決定です。

ラウンド 1 の Critic プロンプトで、4 つ目の判定クラスとしてこれを認めます。

user-conversation-required: <簡潔な質問> — 「この質問には、サブエージェントによる追加作業ではなく、ユーザーによる原則に基づく決定が必要です。質問を簡潔に示します。」

この判定が出たら、オーケストレーターがエスカレーションし、回答を得て、それを「考慮事項」ではなく、ラウンド 2 の Planner プロンプトで原則に基づく方針として明記します。停止するより迅速であり、抽象度を尊重できます。

P18 — ラウンド間のユーザー誘導は、単に決着をつけるだけでなく、設計の全体像を再構成できます

P17より強力なパターンです。ラウンド1で Critic が見つけた問題点をラウンド間にユーザーに提示すると、ユーザーの応答は次のようになります。

• 決着をつける：単一のオントロジーに関する問いを解決します（小規模）。これをラウンド2の方向性として反映します。
• 再構成する：設計の全体像を作り変えます（大規模）。新たな階層を追加したり、ループでは検討できていなかった方向性を示したりします。

問題点を提示する時点で、問いを二択に絞り込まないでください。問題点とその周辺の設計領域を、ありのままに提示してください。ループが見落とした点にユーザーが気づいたら、再構成できるようにします。

再構成の可能性がある問いを提示するときは、最後に次のように添えてください。「何か見落としている点はありますか？」 これが再構成を促す一言です。これがないと、ユーザーは提示された二択に沿って答え、再構成の機会を逃す可能性があります。

ユーザーが再構成した場合は、ユーザーが示した方向性をすべて、ラウンド2の Planner プロンプトに原則に基づく方向性として反映します。提示時点でのオーケストレーターの役割は、主張することではなく、耳を傾けることです。

再構成のパターンには特徴があります。ユーザーの応答が、枠組みを再定義する表現（「第3の階層はXです」）で始まったり、提示された枠組みを否定したり（「このケースに限って言えば……」）します。こうした場合は、決着ではなく再構成です。提示した二択に再構成を無理に押し込まないでください。

P19 — APPROVE_WITH_PROVISO：ラウンド2の第4の判定

デフォルトの判定一覧（APPROVE / APPROVE_WITH_RESERVATIONS / REQUEST_CHANGES / REJECT）では、抜けが生じることがあります。正規の成果物に含める必要がある、名前のついた小さな追加事項がありながら、ラウンド3を行うほどではない場合です。

ラウンド2の第4の判定として APPROVE_WITH_PROVISO を認めます。これは、蒸留時に正規の方針に反映すべき、名前のついた小さな追加事項が2〜4件あることを示す判定です（欠けている原則の記述、契約の明確化、障害処理に関する注記など）。

APPROVE_WITH_RESERVATIONS と区別してください。留保事項はオーケストレーターが検討するための注記ですが、但し書きは正規の成果物に必ず含めるべき具体的な編集内容です。

PROVISO を認める場合：

• ラウンド2で見つかった問題が、表面的な追加（単一セクションへの追加、原則の明記、欠けているルールの記述など）でありながら、方針の根幹に関わる場合。
• Critic がレビューに但し書きの文面を記載できる（またはほぼ記載できる）ため、蒸留時には再設計ではなく機械的に取り込める場合。
• オーケストレーターが、方針の均衡を崩すことなく但し書きを取り込めると確信している場合。

実際にはラウンド3が必要な変更について、ラウンド3の手続きを避けるために PROVISO を使わないでください。但し書きが複数のセクションに及ぶ場合、方針の根幹に関わる決定を変える場合、または独自の整合性チェックが必要な場合は、PROVISO ではなく REQUEST_CHANGES です。

PROVISO の蒸留に関するルール：

1. それぞれの但し書きを、内容上該当するセクションに配置します。末尾に付け足さないでください。
2. 取り込む前に、ラウンド2のレビュアー向け補助情報（応答マップ、自己評価による判定）を削除します。
3. 但し書きによってテスト可能な振る舞いが追加される場合は、テスト一覧を更新します。
4. オーケストレーターのレビューに、取り込み元を記録します。 「Critic R2 PROVISO: X。§N に として取り込み済み。」

これにより、出所を正直に記録できます。正規の方針は合意の産物ですが、オーケストレーターのレビューには、何を取り込み、何を先送りしたかが記録されます。

P20 — コンテキストの反復中に、シードされた論点が消えることがある

P10では、ディスパッチする前にユーザーと反復して検討することを重視しています。P10で取り上げているのは、ユーザーが、ループで見落とした観点や論点を追加するケースです。

逆のことも起こります。ユーザーの捉え方によって、オーケストレーターが重要な前提としてシードした論点が消えることがあります。

パターン：オーケストレーターが、ループの枠組みの中で論点を作成します。ユーザーが、ループでは把握できなかった枠組みを示します（「これは X の実証の場でもある」、「このパターンを採用することは決まっていて、議論の対象ではない」）。ループの枠組みの中では筋が通っていた論点が、ユーザーの枠組みの中では筋が通らなくなります。

取り組み方：

1. **コンテキストの反復中にユーザーが枠組みを変えたら、すべての論点を見直し、新しい枠組みでも筋が通っているか確認します。**不要になった論点には、削除対象の印を付けます。

2. **不要な論点を別の内容に編集して、目立たない形で消すのは避けます。**論点が「新しい仕組みは必要か」で、新しい枠組みでは「必要であり、これを構築する」と決まっている場合、その論点を「仕組みをどこに配置するか」に書き換えてはいけません。それは別の論点です。新しい C-id として追加し、元の論点は明確に終了させます。

3. **枠組みの変更に伴い、通常はループではシードできなかった新しい論点が生じます。**この追加面は P10 で扱います。削除面は P20 で扱います。

4. 削除の記録をコンテキストパッケージに残します。「コンテキストの反復中に削除した論点：」というサブセクションを設ける方法（出所の記録に適しています）、または context.md ファイルをバージョン管理し、差分を記録として残す方法があります。

これが P10 の下位ケースではなく、独立した落とし穴である理由：オーケストレーターは反復中に追加する（論点を増やす、観点を増やす、必読資料を増やす）方向に偏りがちです。追加することが、網羅性を高めるように感じられるためです。削除も同じくらい重要ですが、自分が書いたものの形が間違っていたと認めなければならないため、実行はより困難です。

P21 — どちらのラウンドでも、暗黙のうちに欠落している方針を探す

第 1 ラウンドで最も重要なのは、暗黙のうちに欠落しているものを見つけることです。つまり、どこにも言及されていない原則や、全員が同じ枠組みの中にいたために誰も検討しなかった観点です。META の質問と原則の監査で、これを見つけます。

第 2 ラウンドにも、独自の「暗黙のうちに欠落しているもの」があります。第 1 ラウンドの指摘が反映され、立場が再編成されました。**今、暗黙のうちに欠落しているものは何でしょうか？**もう一度、すべての原則を確認します。新しい立場には新しい枠組みがあるため、その枠組みの中で新たに暗黙のうちに欠落するものがあるかもしれません。

第 2 ラウンドの Critic プロンプトに追加します：「第 1 ラウンドの指摘が第 2 ラウンドに反映された今、新たに暗黙のうちに欠落している原則はありますか？もう一度、すべての原則を確認してください。」

両方のラウンドでこうした欠落を見つけるのが、ループの役割です。第 1 ラウンドで見つかる暗黙の欠落は構造に関わるものです。第 2 ラウンドで見つかる暗黙の欠落は契約に関わるもので、通常、新しい構造が前提としているものの明記されていない、協力、エラー処理、エッジケースに関するものです。

P22 — 機能領域の ralplan をディスパッチする前に、親の立場の検証状態を監査する

機能領域の ralplan（より大きな設計ツリー内のサブドメインに関する ralplan。たとえば、すでに docs/design/<parent-domain>/stance.md があるプロジェクトにおける docs/design/<sub-domain>/）は、親の立場から設計の土台を引き継ぎます。親の立場に、新しい設計によって覆される明示的な見解が含まれている場合、先に機能領域の ralplan をディスパッチすると、サブドメインでの実行を通じて親の見解を再び議論することになります（適切な抽象度ではありません。機能領域の ralplan は親の見解を制約として受け入れるべきであり、異議を唱えるべきではありません）。または、見解をひそかに上書きすることになります（さらに悪いことに、上書きが機能領域の成果物の中に埋もれ、後の読者がそれを探すべき場所だと気づきません）。

親の立場が未検証の場合、この落とし穴はさらに深刻になります。過去の ralplan 実行で 3 件の APPROVE による合意を得ていても、ユーザーとオーケストレーターによる同期レビューを経ていない場合です。このような立場には、ユーザーとの合意が済んでいる可能性はあるものの、実質的には未確定のままの見解が含まれています。未検証の親の土台に対して新たな機能領域の ralplan をディスパッチすることは、地盤が揺れる土地に設計を行うようなものです。 関連するもう一つの落とし穴として、親スタンスが審査済みでも、現在のセッションで明らかになった実利用の証拠が得られる前に作成されたケースがあります。新たな設計の議論によって、親レベルで何があるべきかが変わっています。このとき、機能領域の ralplan を実行すると、その変化を誤った成果物（親スタンスではなく、機能領域のスタンス）に反映してしまいます。

トップレベル以外の ralplan を実行する前の事前確認：

1. 設計ツリーを上位に向かってたどります。 提案されたサブドメインのディレクトリから docs/design/ を上にたどり、親スタンスが存在するか確認します。横断的なスタンスはありますか？ 重複する兄弟スタンスはありますか？

2. 各親スタンスの審査状況を確認します。 ユーザーと同期的に審査しましたか（<orchestrator>-review-deep.md が存在し、かつ brief.md が議論されましたか）？ あるいは、plan.md／同等の将来展望ドキュメントに「このスタンスを審査する」というゲートが記載されているものの、まだ実施されていませんか？

3. 各親スタンスの立場を、このセッションでの変更点と照らし合わせます。 具体的には、現在のセッションでユーザーが示した再定義と、反復中に退けられた論点の一覧を確認します。それらのいずれかが、親スタンスの明示的な立場と矛盾していますか？

4. (2) または (3) の答えが「はい」の場合、適切な対応は次のいずれかです：

   • まず親スタンスの審査に切り替えます。 親の審査ゲートで求められている準備ドキュメント（例：<parent-domain>/stance-review.md）を作成し、このセッションの証拠を新たな視点として取り込み、ユーザーと同期的に審査ゲートを実施してから、修正された親の前提に基づいて機能領域の ralplan を実行します。

     サブケース — 準備ドキュメントがすでに存在するものの、未完成です。 親の審査ゲート用の準備ドキュメントが、以前のセッションでディスク上に作成されている場合があります（例：レンズ 1～3 が数週間前に記述された stance-review.md）が、一度も確認されていません。書き直すのではなく、現在のセッションの証拠に基づく新しいレンズを追加します。これにより、以前のレンズを由来の記録として保ち、修正の範囲を実際に新しく得られた情報に絞り、審査時にセクションごとに確認できるようになります。現場での兆候として、過去の日付が付いたレンズと、未回答のままの質問を記した「推奨セッション順序」がある stance-review.md が見つかることがあります。日付付きの見出しを付けたレンズ N+1 を追加し、以前の審査が延期されたことをファイルのフロントマターに明記して、同期ゲートですべてのレンズを確認します（新たな証拠によって古い質問が解消されることもあります。P20 — 仕込まれた論点は消え得る — は上位レベルにも当てはまります）。

     実利用の証拠を根拠にします。 現在のセッションでの変更が実利用の証拠に基づく場合（親スタンスはシステムが実際に稼働する前に作成され、実際の利用によって、成立しなかった点が明らかになった場合）は、新しいレンズでそのことを明示します。実利用の証拠は、調査による証拠とは認識論的な重みが異なります。「当てはまるかもしれないパターン」ではなく、失敗モードを一度の実使用で証明するものです。その性質を明示します。証拠の種類が明確であれば、ユーザーは審査の判断をより確かな根拠に基づいて行えます。

   • 上書きを明示し、親を経由して進めます。 ユーザーによる変更が、機能領域の設計ではなく親スタンスへの修正に該当する場合、親レベルの修正として変更を1つのコミットにまとめて記述し、審査したうえで、機能領域の ralplan を実行します。

   • 上書きが意図的で、機能領域のみに適用されることをユーザーに確認します。 まれですが、実際にあります。機能領域の設計で、親スタンスが想定していなかった立場が正当に必要となることがあります。その場合は立場の適用範囲を限定し、機能領域の context.md に制約として記載するのが適切です。コミットする前に、ユーザーの了承を得てください。 誤った対応は、機能領域の ralplan を実行し、ループに親との衝突を発見させることです。Critic は必ずこれを見つけます（これこそ META-question の役割です）が、そのラウンドでは、破棄せざるを得ない、内部では整合性のある機能領域の成果物を作るために時間を無駄にしています。事前確認を行えば、ラウンドを費やすことなく発見できます。

この落とし穴が発生したことを示す現場の兆候： サブドメインの context.md を作成し、必読資料を求めてソースを調べたところ、同じ問いに対する立場が、会話の進んできた方向とは正反対である親の stance.md が見つかります。「この親の立場を再検討するために、コンテストを仕掛けよう」と考えたら、立ち止まってください。親の立場の再検討は、機能領域のコンテストではなく、親の立場の修正です。方針を切り替えてください。

この落とし穴は、P10（ディスパッチ前にユーザーとコンテキストを反復する）と P11（決着済みの問いにコンテストを仕掛けない）の間にあります。P10 はディスパッチ前にユーザーが知っていることを加えること、P11 は同じ設計ドメイン内でユーザーが決着をつけた事柄を再検討しないことについてです。P23 は設計ドメインの境界を黙って越えないことについてです。

P24 — 視点を得るための委任は有効（この手法の原則）

これが、このスキル全体の動機となる原則です。ユーザーがターンごとの提案ループに陥りそうなときは、次の流れに切り替えます。

• 原則を定める → 深い作業を委任する → 要点を抽出する → レビューする。

ralplan をうまく実行するのが初めてでも、その結果として得られる立場は、提案を修正するやり方で生み出せるものより強固になります。また、ループの間、ユーザーは作業から離れられます。これがオーケストレーターのもたらす価値であり、オーケストレーターの規律が作業者の才覚より重要である理由です。

複数の決定が必要なプロジェクトで、ユーザーとのターンごとの修正ループに陥ったら、立ち止まってください。原則を定めます。ralplan を実行します。レビューします。引き継ぎます。

P25 — ループの渦に引き込まれず、追従より懐疑を優先する

オーケストレーターという役割が存在する理由はただ一つです。作業を俯瞰し続けることで、ディスパッチ時とレビュー時に異なる高度から見渡せるようにするためです。コンテキストパッケージ、ディスパッチされたサブエージェント、名前付きの判定、要点の抽出、オーケストレーターのレビューゲートといった仕組みはすべて、枠組みの内側にいるサブエージェントには持てない明晰さと判断力を、あなたが保ち続けるためにあります。

この落とし穴が示す失敗パターンは、ループの出力に意味があるように感じられるため、オーケストレーターがループの視点まで引き下げられることです。兆候は次のとおりです。

• Critic の対案をすぐには退けられず、自分で上位の視点から答えるのではなく、問いとしてユーザーに提示しようとする。
• 渦の中にいるため、深さを演出することに同意してしまう。渦の中では、それが厳密さのように感じられる。
• 立場の範囲が広がり（14番目の原則、ラウンド1での指摘を受けて新たに開始されるコンテスト、「これも追加すべきだ」といった考え）、それを削るのではなく受け入れてしまう。
• 指摘が「必ず対処されるべき」だからという理由でラウンド2が必須に感じられ、指摘が本当に重要な前提を左右するからではなくなっている。
• 自分がループの中で作業し（文言を考案し、再構成を提案し）、ディスパッチャーから作業者へと引き下げられていることに気づく。

構造上の対策は、追従ではなく懐疑です。ユーザーがあなたをオーケストレーターに任命した際に寄せた信頼は、ユーザーが修正によって再び発動させるまで保留しておくのではなく、活用することを意図しています。

運用上の規律：

1. Critic／Architect から指摘を受けたとき、最初に判断するのはユーザーではなくあなたです。 指摘を読み、自分の基準に照らして評価します。深さの演出にすぎないなら、上位の視点から退けます。その旨はオーケストレーターのレビューセクションに記します。本当に重要な前提を左右するなら、明確な説明を添えてラウンド2に回します。最初に「どうすべきでしょうか？」とユーザーに提示するのは、決して避けてください。それは追従です。

2. 形而上学的／ガバナンスレベルの落とし穴に注意してください — ループが生み出した「収束はXの行為である」や「第14の原則が必要だ」といった主張です。こうした主張は、機能領域のralplanに適した形であることはほとんどありません。Criticは枠組みに異議を唱えるべきです（P4 METAの問い）が、枠組みへの異議申し立ての結果が正規の見解に含まれることはまれです。そうした内容はオーケストレーターのレビューに、「ループでXが浮かび上がったが、見解の変更には当たらない理由は以下のとおり」として記載するものです。

3. 見解の分量が想定の約50％を超えているなら、いったん立ち止まって理由を考えてください。 分量は兆候になります。設計上の課題が「既存システムに同じ形の新しいインスタンスを追加する」（P12の継続性）であれば、見解の中でシステムを第一原理から再導出する必要はありません。本来なら「これをして、次にこれをして、その次にこれをする」という約1500語で済む内容に対して、新しい教義が5000語以上も書かれているなら、ループは過剰に展開しており、あなたはその中に入り込んでいます。

4. ユーザーが継続性を確認する質問をするのは兆候です。 生成した内容を読んだユーザーが「これは過剰設計のようです」／「大げさにしすぎています」／「必要なのはXの拡張だけです」と反応した場合、それが高度を修正する合図です。 正しい対応は、ユーザーの修正を取り入れて第2ラウンドに進むことではありません。この実行を終了し、まったく別の高度に切り替えることです（多くの場合、ralplanより下の従来型レイヤーで、要件を起点に進めます）。

5. 設計パスで設計の見せかけが生まれたら、要件に切り替えてください。 要件は技術に依存せず、簡潔であり、設計パスが誠実に小規模なままでいられる制約面を作り出します。P15では要件と見解は別の成果物であるとされています。この落とし穴はそこからさらに踏み込みます。膨れ上がった見解を受けて正しい対応が、次のラウンドに進むことではなく、見解の執筆に先立って作成すべきだった要件レイヤーに戻ることである場合もあります。

6. オーケストレーターのレビューは、正直に作成してください。 ループが厳密さよりも形式的な手続きを増やしてしまったなら、レビューでそう述べ、対象範囲を絞って再実行するか、別の進め方に切り替えてください。「自分の基準を下回る出力をユーザーに渡さない」という規律がまさに問われるのはここです。高度をコンパクトに保つには、ループが生み出した内容について正直であることが不可欠です。（この落とし穴に陥ったことを示す現場の兆候：これから「ループで興味深い問いがいくつか浮かび上がりました」や「も意見を述べたいかもしれません……」と書こうとしている場合。どちらも、オーケストレーターがユーザーの高度に戻っていることを示しています。オーケストレーターのレビューの役割は、あなた自身の基準を適用することです。その基準を満たしていないなら、それはレビューで明示する事実であり、ユーザーに判断を委ねる問いではありません。）

オーケストレーターが託された信頼とは、見極める役割です。それを活用することが役目です。あらゆる落とし穴を質問としてユーザーに提示するのは、「ユーザーに従属するサブエージェント」へと役割を逆転させます。これはまさに、ralplanが避けるために作られた、ターンごとに修正を重ねるループです（P24）。

P26 — まず判断事項を提示し、詳細レビューは記録用にする

オーケストレーターによる詳細レビュー（<orchestrator>-review-deep.md — ステップ 5 を参照）は、ラウンドの集計、批評役が見つけた点、 異議を唱える点、ユーザーが異議を唱えると思われる点、 この実行で手法について明らかになったこと、高度に関する補足など、 包括的な内容です。これは誠実なものです。しかし、ユーザーに 判断してもらう必要があるときに渡す成果物としては、適切ではありません。

この落とし穴が指摘する失敗パターンは、オーケストレーターが 充実した詳細レビューを書き、ユーザーがそれを読んだ結果、 「包括的で情報量も多いのに、妙に要点がつかみにくい……この 詳細をたくさん読んだものの、少し迷子になり、疎外されたように 感じます。話し合った内容と違うことについての合意も含めて、 私が決める必要のある事項をまとめて示してほしいのです」と 報告することです。

つまり、詳細レビューは、ユーザーがあなたに任せてくれた内部の やり取りを表に出してしまいます。ループがすでにまとめた推論を、 ユーザーにもう一度たどらせることになります。作業過程を見せる （詳細レビューが担うこと）と、判断に必要な情報を渡す （それとは別の成果物が担うこと）を混同しています。詳細レビューを 提示されても、経営幹部はそこから判断できません。一方、概要を 提示されれば判断できます。

基本方針：

1. オーケストレーターのレビューステップでは、1 つではなく 2 つの成果物を作成します。 記録用の詳細レビューは、経緯と誠実な自己評価を残します。ユーザーに渡すのは概要です。プレイブックのステップ 5 では両方を定めています。これに従ってください。

2. 概要では判断事項を先に示します。 ユーザーが判断する必要のある事項を番号付きで最初に提示します。それぞれについて、あなたの見解と代替案の両方を記載します。ユーザーはざっと確認して、判断し、また戻ることができます。何を判断するのか知るために、詳細レビューを読む必要があってはなりません。

3. 事前のやり取りからの逸脱は明示します。 ユーザーは、事前にあなたと重要事項、細かな点、考慮事項を検討するために時間を費やしています。ループの結果が話し合った内容と異なる場合は、その理由とともに概要で伝えてください。 逸脱を隠すことは、認めるよりも早く信頼を損ないます。

4. 設計がどこに落ち着いたかは、8 段落ではなく 1 段落で説明します。 詳細レビューの「最終的な方針」についての 5～8 段落の説明は、詳細レビューに含めます。概要では、読者が判断しながらワーキングメモリーに保てる 1 段落にまとめます。

5. 未解決の質問と次のステップは概要に含めます。 これらはユーザーが対応できる事項です。内部のやり取り（委任の検証、高度に関する所見、スキル向けの落とし穴の命名）は、詳細レビューだけに含めます。

6. 概要は、高度を測る試金石です。 詳細レビューを、明快で判断事項を先に示す概要にまとめられないなら、自分が思っているほど高い視座を持てていません。 概要を書いてください。内容が膨らむなら、それは合図です。長い概要を出すのではなく、概要がすっきりまとまるまで、詳細レビューの要約工程をやり直してください。

7. ユーザーが概要だけを読むことは失敗ではなく、成功の条件です。 多くの場合、ユーザーは詳細レビューを読みません。それで正解です。詳細レビューは経緯の記録であり、概要はユーザーへの提示物です。

この落とし穴が発生したことを示す現場の兆候：ユーザーが提示された内容を読んで、迷子になった／疎外されたように感じた／判断できないと報告することです。詳細レビューに情報を追加して対応してはいけません。 詳細レビューから概要を抜き出し、今後の実行で概要を標準の提示物とするようスキルを修正してください。

同じ枠組みをディスパッチ前にも適用する — 簡潔にまとめ、質問を投げかけない

上記の「要約を引き継ぎ資料にする」規律は、蒸留後の引き継ぎに適用されます。同じ大統領向けブリーフィングの枠組みは、ディスパッチ前の意思決定の場面（P10 のウォークスルー、P18 のセッション中の再構成、前提の事前決着、複数の質問をまとめて扱う場合）にも、それ以前の段階で適用されます。そこで起きる失敗は、対称的です。オーケストレーターは構造化されたブリーフィングではなく、「X についてどう思いますか？」、*「Y と Z のどちらにすべきですか？」*といった自由回答形式の質問をユーザーに投げかけます。ユーザーは分析を一から組み立てなければならず、オーケストレーターは立場を明確にすることを避けています。

ディスパッチ前の規律も同じ構成ですが、インラインの流れに合わせて簡潔にします。意思決定ブリーフィングは、次の4つのセクションをこの順序で含みます。

1. 質問。 何を決めるのかを示す1段落です。具体的かつ明確にし、前置きは不要です。
2. 重要な点。 トレードオフを示す短い2段落です。両方の選択肢におけるコストと利点、各ケースで何がうまくいかないかを述べます。トレードオフが均衡していないなら、均衡しているように見せず、どちらに非対称性があるかを明示します。
3. 私の推奨。 1文で述べた後、理由を2～4つ、それぞれ1文で示します。オーケストレーターが責任を持って推奨し、「あなたが決めてください」と逃げないでください。本当に推奨案がないなら、それは別の形式（決定前の確認）です。そのことを明確にブリーフィングしてください。
4. その決定による影響。 具体的な結果を示します。どのファイルが変更され、どの設計上の決定に波及し、後続の作業で何が簡単になり、何が難しくなるかを述べます。

ディスパッチ前にこの方法が有効な理由：

• ユーザーは分析を組み立て直さずに、「はい」「3つとも」「進めて」と承認できます。正しく枠組みが示されれば、ディスパッチ前の意思決定の多くは、ユーザーがオーケストレーターに同意する判断です。
• ユーザーが異議を唱える場合も、その異議は明確になります。両者が同じ枠組みで話し合えるからです。
• オーケストレーターは実際に立場を示さざるを得ません。*「どう思いますか？」*ではオーケストレーターは判断を避けられますが、ブリーフィング形式では推奨案を示す必要があります。

ディスパッチ前にブリーフィングを行う場合：

• 事前決着が必要な前提（そうしなければ第1ラウンドの議論の争点になる、後続を左右する前提）。
• ユーザーがアーキテクチャの前提を変えるセッション中の再構成（P18）。
• 独立した複数の決定事項がまとまっている場合の、一括した質問。

ブリーフィングを行わない場合：

• 1ステップで済む機械的な決定（「これをコミットしますか？」 — そのままコミットします）。
• ユーザーがすでに決めていること（再び議論しないでください）。
• 承認ではなく対話が必要な、本当に未解決の質問（「v12 のテーマは何ですか？」 — これは議論すべき内容です）。

形式そのものが規律です。 短いブリーフィングは簡潔に（各項目を1段落に）できますが、規模が小さくても、構成 — 重要な点、推奨案、影響 — には価値があります。蒸留後のブリーフとディスパッチ前のブリーフィングは、同じオーケストレーターの働きかけを表す2つの側面です。立場を示し、その決定による影響を明らかにし、共通の枠組みに基づいてユーザーが承認または異議を示せるようにします。

構成テンプレートについては、references/brief-template.mdを参照してください。

この落とし穴により、以前のセクション（P19、オーケストレーター・レビューのテンプレート）にあった定義上の曖昧さも解消されます。それらのセクションで「オーケストレーターのレビュー」とある場合は、詳細レビュー（<orchestrator>-review-deep.md）を指します。留保事項は引き続き詳細レビューの蒸留セクションに組み込みます。ユーザーの判断が必要な事項にならない限り、ブリーフにそれらを記載する必要はありません。

delegate_task の目標のテンプレート

[omh-role:planner] <one-line goal>

## Required reading (open these files, do not work from summaries)

Absolute path base: `/.../project/`

<ordered list of files, grouped by category: principles, directives,
inspiration findings, existing-code, context package>

## <Design sub-dimensions, constraints, out-of-scope>

## Questions you must actively contest

- **(META) Are these the right sub-dimensions?** ...
- <six-to-eight specific seed contests>

## Output

Write to: <absolute path>
Structure: <named sections>
Word count target: ...
End with verdict: APPROVE / REQUEST_CHANGES

目標は自己完結型にしてください。サブエージェントには事前のコンテキストがありません。

再利用可能な完全版テンプレートは references/ にあります。

• references/planner-goal-template.md — Round 1 Planner（Requirements 版と Lived-moments の調査リスト付き）
• references/architect-goal-template.md — Round 1 Architect
• references/critic-goal-template.md — Round 1 + Round 2 Critic （最も重要なテンプレート — 品質を生み出すのは Critic です）
• references/orchestrator-review-template.md — 最終品質ゲート

山括弧で囲まれた変数はドメイン固有です。構成を維持してください。 各セクションにはそれぞれ役割があります。

ralplan ドメインのファイル構成

docs/design/<domain>/
├── context.md               ← input, reviewed by user
├── stance-planner.md        ← Round 1
├── review-architect.md      ← Round 1
├── review-critic.md         ← Round 1
├── stance-planner-v2.md     ← Round 2 (with response map)
├── review-architect-v2.md   ← Round 2
├── review-critic-v2.md      ← Round 2
├── stance.md                ← distilled from v2; canonical user-read
├── brief.md                      ← decisions-first, what the user reads
├── <orchestrator>-review-deep.md ← orchestrator's archive deep review
└── (later) implementation-plan.md

.omh/plans/ralplan-<instance-id>.md — デザインディレクトリとは別の、簡潔な合意事項の要約です。デザイン成果物の系譜の外に置かれます。

omh_state を介して追跡される状態

omh_state(action="write", mode="ralplan", instance_id="<slug>", data={
    "goal": "...",
    "round": 1,  # or 2 / 3
    "phase": "context-gathering | round-N-<role> | complete",
    "consensus": False,
    "plan_file": ".omh/plans/ralplan-<slug>.md",
    "round_1": {"planner_verdict": "...", "architect_verdict": "...", "critic_verdict": "..."},
    "round_2": {...},
})

これはセッション再開可能な状態です。オーケストレーターのセッションが中断された場合、次のセッションはこれを読み込んで再開します。

オーケストレーターにとっての「完了」の状態

• 3者の APPROVE による合意（または留保付きで最大 3 ラウンド、または proviso を反映した APPROVE_WITH_PROVISO、または提示済みの user-conversation-required が解決済み）。
• レビュアー向けの補助情報を含まない、正式な stance.md（または requirements.md）が作成されていること。
• 合意事項の要約 .omh/plans/<file>.md が作成されていること。
• <orchestrator>-review-deep.md が作成されていること — 誠実で具体的であり、形式的なものではないこと（アーカイブ／来歴の成果物）。
• brief.md が作成されていること — 決定事項を優先し、約 1 ページで、ユーザーが判断を下すために読む内容であること（P26）。
• ドメイン成果物と状態の gitignore を記録した単一のコミットがあること。
• コミットメッセージに、Critic が発見した問題、確定した重要な立場、ユーザーの承認後に実行可能な MV を記載すること。

独自の実行ログの管理

このスキルは、落とし穴を修正することで成長します。ralplan の各実行後に、次の点を確認してください。

• 既存の落とし穴に当てはまる失敗モードはありましたか？ 新たな証拠で内容を強化し、追記の日付を記録します。
• 既存のどの落とし穴にも当てはまらない失敗モードはありましたか？ 新しい項目（P23、P24 など）を追加します。失敗モードを明確に命名し、具体例を挙げ、規律を定めます。
• 特に効果的だった規律はありましたか？ 一度きりの成功にとどめず、名前の付いたパターンとして定着させます。

実行のたびにこのスキルを更新してこそ、品質が向上します。オーケストレーターを驚かせる事態があったのに更新されないスキルは、信頼できるように聞こえても古くなり、かえって負担となります。

独自の実行ログはスキルの外（基盤環境、プロジェクトのメモ、Wiki など）に保管してください。日付、ドメイン、ラウンド数、予想外の出来事、更新内容を記録します。このスキルをセッションログにしないでください。これは実践ガイドであり、日誌ではありません。

失ってはならない内容（このスキルを記憶から再生成する場合）

最も重要な洞察：Critic には、枠組みそのものに異議を唱える権限を与える必要があります。 コンテキストパッケージに META の質問がなければ、Critic は枠組みの内側にとどまり、真実を検証せずに適合性を確認するだけです。META の質問があれば、Critic は推論上の対等な相手となり、枠組みの内側にいるために Planner も Architect も見落とす原則の欠落を発見できます。

これこそが、オーケストレーターとユーザーの間で提案を修正するループよりも ralplan を優れたものにする唯一の工夫です。このスキルのほかのすべての要素は、この工夫を支えるためにあります。

重要度で二番目の点：懸念を指摘するより、具体的な対案を示すほうが有効です。 優れた Critic は、単に「別の分割方法を検討してください」と言うのではなく、具体的な代案を提示します。Critic のプロンプトでは、この形式の提案を促す必要があります。そのうえで第 2 ラウンドの Critic が、原則に基づいて採用されたのか、それとも追従しただけなのかを検証します。

三番目：オーケストレーターによるレビューが最後の関門です。 自分の基準を満たさない出力をユーザーに渡してはいけません。立場が弱ければ、もう 1 ラウンド実施するか、原則を強化してください。高度な視座を簡潔にまとめることは、これにかかっています。

四番目：準備が価値の半分を占めます。 品質はコンテキストパッケージで生まれます。事実関係を確認し、関連する仕組みを明らかにし、外部の前提を検証し、ファイルシステムの構成を決め、ユーザーと一緒に確認し、再構成によって生じた見せかけの論点を取り除きます。このスキルで起きる問題のほとんどは、ディスパッチ前の失敗です。このパッケージを、成果を支える重要な成果物として扱ってください。

五番目：判断事項を先に示して届け、詳細なレビューはアーカイブに残します。 オーケストレーターのレビュー段階では、2 つの成果物を作成します。ユーザーが判断するために読む、判断事項を先に示した約 1 ページの brief.md と、出典、内部のやり取り、率直な自己評価を記録した <orchestrator>-review-deep.md です。ユーザーはブリーフだけで判断できなければなりません。何を決めるべきかを知るために、詳細レビューを読ませてはいけません。P26 では、この方法と、エグゼクティブ向けのブリーフが必要なのに包括的な詳細レビューを渡してしまうという失敗パターンを説明しています。ブリーフは高度な視座を測る試金石です。詳細レビューを明快で判断事項を先に示したブリーフにまとめられないなら、自分が思っているほど高い視座を持てていません。