decide

敵対的コンセンサスプロトコル

構造化された3エージェントによる討論を実施し、戦略的な決定について合意に達します。2人の提唱者が対立する立場を最も説得力のある形で論じ、モデレーターが難しい質問を投げかけ、リスクを特定し、拘束力のある合意をまとめます。

これが効果的な理由：敵対的な構造によって、ブレインストーミングでは見落とされる議論が明らかになります。証拠に基づく調査によって、認識の閉鎖を防ぎます。第2ラウンドで譲歩を必須にすることで、立場の硬直化を防ぎます。モデレーターは双方の意見を聞いた後、拘束力のある合意を書き上げます。

事前検証

討論を実施する前に、入力に少なくとも2つの区別できる選択肢または行動方針を伴う、真の意思決定が含まれていることを確認します。

入力が事実に関する質問、説明の依頼、または単一の選択肢についての記述である場合は、代わりに直接回答します：「このプロトコルは、選択肢の中から選ぶ場合に最も効果を発揮します。検討中の選択肢を示して言い換えるか、直接質問していただけますか？」

迷う場合は、討論を実施する方向で進めてください。

フェーズ0：調査と意思決定の枠組み設定

ステップ0.1：背景情報の収集

プロジェクトのドキュメントとコンテキストファイルを読み、意思決定の範囲を把握します。一般的な情報源として、README、アーキテクチャドキュメント、製品ドキュメント、最近のgit履歴、ユーザーが参照したファイルなどがあります。

ステップ0.2：2つの立場を特定する

意思決定のテーマから、明確に対立する2つの立場を組み立てます。

• 立場A：意思決定の一方の立場
• 立場B：それと対立する立場

テーマから自然に2つの立場（例：「gRPC vs REST」）が示される場合は、そのまま使います。テーマが自由形式の場合（例：「価格戦略」）は、対象領域を調査し、最も有力な対立するアプローチを2つ組み立てます。

ステップ0.3：制約を特定する

ユーザーのメッセージまたはプロジェクトドキュメントから、厳格な制約を抽出します。予算の上限、スケジュール要件、チームの規模、技術的制約、ビジネス要件、譲れない価値観などが該当します。

ステップ0.4：ブリーフを提示する

先に進む前に、討論のブリーフを作成します。次の3つの条件に照らして評価します。

• 2つの立場を、大きな重複なく表現できるか？
• 質問は真に開かれているか（誘導的でなく、答えを前提としていないか）？
• 意味のある違いがある結果が少なくとも2つ存在するか？

すべての条件を満たす場合は、ブリーフを提示してフェーズ1に進みます。

Decision: [one-line summary]
Position A: [name] — [one-sentence description]
Position B: [name] — [one-sentence description]
Constraints: [list any hard constraints]
Launching Round 1...

いずれかの条件を満たさない場合は、ブリーフを提示し、枠組みを変更するか、このまま進めるかをユーザーに尋ねます。

フェーズ1：第1ラウンド — 立場文書

3つのエージェントを並行して起動します。各エージェントは独立して実行され、他のエージェントの出力を読むことはできません。

• 提唱者A：立場Aを最も説得力のある形で論じます。外部調査を行い、支持する情報源を少なくとも2つ見つけます。アーキテクチャ、実装計画、コスト、スケジュール、リスク、軽減策を含む包括的な立場文書を作成します。情報源を本文中で引用します。
• 提唱者B：提唱者Aと同じ構成および調査要件に従い、立場Bを最も説得力のある形で論じます。
• モデレーター：外部の反証を用いて両方の立場を批判的に検討します。各立場に異議を唱える情報源を少なくとも2つ見つけます。最も難しい質問を10個（各立場につき5個）挙げ、各アプローチの最大のリスクを5つ特定し、ハイブリッドモデルを提案したうえで、暫定的な推奨を示します。

references/debate-prompts.mdの第1ラウンドのセクションに従って、エージェントへのプロンプトを作成します。

第1ラウンドの統合

3つすべてのエージェントが完了したら、次の内容をユーザーに提示します。

1. 3者全員が合意する点 — 合意事項の表
2. 意見が分かれる点 — 各エージェントの立場を示す、対立点の表
3. 主な対立点についての簡潔な解説

その後、直ちに第2ラウンドに進みます。

フェーズ 2：第 2 ラウンド — 強制的な収束

3 人のエージェントを並行して起動します。各エージェントには、他のエージェントの主張の要約を渡し、応答を求めます。

• 改訂版の提唱者 A：提唱者 B とモデレーターからの最も強い指摘に応答します。有効な指摘は率直に認め、立場 A が依然として優位な点は擁護し、修正した立場を示します。
• 改訂版の提唱者 B：同じ構成で、提唱者 A とモデレーターからの指摘に応答します。
• 合意形成モデレーター：最終合意に向けて議論を進めます。合意したモデル、解決した対立点、実行スケジュール、主要指標 3 つ、最大のリスク 1 つ、および 1 段落のエレベーターピッチを含む、拘束力のある合意文書を作成します。

references/debate-prompts.md の第 2 ラウンドのセクションに従って、エージェントへのプロンプトを作成します。

フェーズ 3：結果を提示する

ステップ 3.1：合意内容を提示する

ユーザーに次の内容を提示します。

1. 各提唱者が譲歩した要点（考えが変わった理由）
2. 合意モデル — モデレーターの最終提案
3. 構成または計画の詳細（階層、アーキテクチャ、スケジュール）
4. 追跡する主要指標
5. 最大のリスクとその軽減策

ステップ 3.2：保存するか尋ねる

合意内容を保存するかどうか、ユーザーに尋ねます。決定の種類に基づいて、適切なファイルを判断します。

• ビジネス上の決定 → biz.md
• アーキテクチャ上の決定 → ARCHITECTURE.md または ADR-NNN.md
• プロダクト上の決定 → PRODUCT.md
• 戦略 → 適切なプロジェクト文書
• または、該当するファイルがなければ新規ファイル

オーケストレーターのガイドライン

• 各ラウンドで、3 つすべてのエージェントを必ず 1 回のステップで起動します（並行して）。
• エージェントの主張は決して編集しないでください。忠実に提示します。
• 第 2 ラウンドのモデレーターの合意が拘束力のある成果物です。ただし、最終的な決定権はユーザーにあり、覆すことができます。
• 独自のコメントは簡潔にします。検討はエージェントが行っており、あなたは要約して提示します。
• 第 2 ラウンド後もエージェント間で合意に至らない場合、残る意見の相違を明確にし、ラウンドを重ねるのではなく、ユーザーに決着を委ねます。
• プロンプトの具体的な内容は領域に合わせて調整します。価格決定ならコストの数値、アーキテクチャ上の決定なら技術的なトレードオフが必要です。
• 関連するプロジェクトのコンテキストをすべてのエージェントプロンプトに含めます。エージェントは個別に実行され、互いの出力を読むことができません。