models-consensus

モデルの合意形成

直接呼び出す場合は、選択した評議会の範囲に応じて shared/references/model-preview.md を使用します。明示的な3席のリクエストでは、3つのブラインド開幕役を選択します。プレビューには、登録済みの席とともに、承認済みのすべてのオーガナイザー、ジャッジ、統合役も表示されます。簡易投票では、条件付きの両方のジャッジ経路が表示されます。無関係なタスク種別のルーティング表に展開しないでください。ネストされた呼び出しでは、親の選択済みスナップショットを再利用し、別のプロンプトや未登録のワーカーは使用しません。

モデル ID、対応する推論レベル、タスクのデフォルト値は、 shared/model-routing.json のみを参照します。プレビューまたは承認の前に該当するルートを解決し、ディスパッチ、再試行、再開の際は保存されたルートを正確に維持します。

複数のモデルの意見を求めているユーザー向けに、判断レポートを作成します。次に利用するのはユーザーです。完了とするには、レポートに推奨案、異論、証拠の限界、次のステップを1つ、設定済みおよび実行時に確認された席、受領記録の限界を記載します。

これはユーザーが制御する読み取り専用のワークフローです。複数の独立した意見に時間とコストをかける価値があるとユーザーが判断した場合に限り、評議会を開く理由があります。

開始と承認

ユーザーが models-consensus を明示的に呼び出すか、追加のモデル意見を明示的に求めた場合にのみ実行します。別のスキルがこのワークフローを手動で行う次の手順として提案することはできますが、呼び出してはいけません。

モデルをディスパッチする前に：

1. デフォルトでは poll を選択し、方向性に異論がある場合は debate、選択した1つのモデルから5つの視点を求める場合は personas を選択します。poll_profile の指定がない投票では、従来の standard プロファイルを使用します。リスクの低い質問に限り、明示的に lean を選択します。
2. references/role-routing.md、shared/references/model-roster.md、shared/references/task-shaped-model-routing.md、shared/references/host-model-execution.md を読みます。外部ランナーより先に、ホストネイティブのルートを確認します。.rar-skills/config.local.yaml が存在する場合は、shared/references/local-config.md の定義に従い、このプレビューを作成する間に限って、その参考情報である profile と seats を読み取ります。各値をロスターと選択した実行経路に照らして検証し、ユーザーからの直接の指示を優先して、承認後は再度読み込まないでください。
3. 以下の承認プレビューを提示し、次のように尋ねます：「この評議会の計画を承認しますか？変更点があれば指定してください。」
4. 明確な承認を待ちます。無応答、タイムアウト、以前の一般的な承認、auto のリクエスト、別のスキルからの指示は、承認にはあたりません。

プレビューには、計画された呼び出しと条件付きの呼び出しをすべて表示する必要があります：

フィールド	必須の内容
質問とモード	中立的な質問と、poll、debate、personas のいずれか
Poll プロファイル	新規の poll では、standard または lean、risk_flags、不変の poll_policy スナップショット。従来の標準プランでは、これらのフィールドを省略できます。
席	承認されたすべての役割の登録情報：席 ID、指定されたモデルラベル、プロバイダー、レシート、実行パス。冒頭の3席に加えて、裁判役のみの席を含めることができます。
役割	オーガナイザー、各裁判役、シンセサイザーまたは議長。それぞれの席、指定されたモデルラベル、継続性キー、依存関係、条件付きの状態
条件付きの裁判役	lean の場合、正確な裁判役ルートの両方、推論の労力、ツールポリシー、レシート要件、予算、および実行を必要にできるオーガナイザーの証拠条件
推論の労力	すべてのモデル呼び出しで設定された正確な推論の労力、またはランタイム制御の推論の労力
ホストとセッション	確認済みのホストまたはランナー、役割ごとのセッションポリシー、記録された ID で役割を再開できるかどうか
サービングレシート	各席について、required または explicitly allowed unverified、ステータス、ソース、観測されたモデル
予算	poll_budget と、それに一致する承認予算：基本呼び出し数、条件付き呼び出し、検証再試行の上限、最大呼び出し数、助言応答の上限、および報告される使用量や経過時間の上限。lean では poll_budget が必須です。
ツール	共有の読み取り専用ツールプロファイル。Codex ランナーの席には repo_read_only が必要で、実行エントリに tool_evidence: configured と allowed_tools: [] を設定し、「Codex：読み取り専用の分離を設定済み。起動時のツールは観測不可」と表示します。詳しくは references/runner-invocations.md を参照してください。
証拠	どのネイティブまたはランナーのチェックに合格したか、サービングモデルのレシートがまだ保留中であること

席の忠実性を維持してください。承認された席とは、指定されたモデルラベル、レシート要件、実行パス、推論の労力、役割の継続性ポリシーが完全に一致する席です。すべてのランナー呼び出しで --disable-fallback を使用し、ネイティブルートにはランナーフォールバックを設けません。プレビュー後に、選択済みの席、モデルラベル、レシート要件、ホスト、実行パス、推論の労力、役割、またはセッションポリシーが変更された場合は、停止して改訂版のプレビューを表示してください。保留中のレシートが承認済みモデルについて検証済みになった場合は、新たな証拠であり、再承認は不要です。観測されたモデルの不一致、または必須のレシートが満たされていない場合、そのルートはブロックされます。続行するためにレシート要件を緩和してはいけません。新たな承認なしに、代替、ダウングレード、席の追加、モードの切り替え、またはペルソナへの変更を行ってはいけません。

明示的な会議の承認は、conditional-not-needed になる可能性のある lean の裁判役を含め、一覧にあるすべての役割を対象とします。条件付きのステータスは、その後の実行を制御します。一覧にないルートや代替を承認するものではありません。

名簿を確定した後、次の形式でプレビューを表示してください。

Council plan: awaiting approval
Mode: <mode>
Poll profile: <standard | lean>; risk flags: <none | configured flags>
Poll policy: <low confidence threshold and full required flags from the central snapshot>
Opening: <seat> / <requested model> / <receipt status and source> / <host and execution path> / <effort or runtime-controlled> / <continuity key>
Organizer: <seat> / <requested model> / <host and execution path> / <effort or runtime-controlled> / <continuity key>
Judges: <seat> / <requested model> / <host and execution path> / <effort or runtime-controlled> / <continuity key> / <required or material conflict or gap, low confidence, or high risk>; <seat> / <requested model> / <host and execution path> / <effort or runtime-controlled> / <continuity key> / <required or material conflict or gap, low confidence, or high risk>
Synthesis or chairman: <seat> / <requested model> / <host and execution path> / <effort or runtime-controlled> / <continuity key>
Budget: <base> base, <conditional> conditional, <retry ceiling> retries, <hard maximum> maximum calls
Tools: <read-only profile>
Evidence: <native or runner checks>; serving-model receipts pending
Sessions: <persistent per-role policy and resume limit>
Serving receipt: required | explicitly allowed unverified

Approve this council plan, or specify changes.

会議のモード

モード	使用する状況	プロトコル
poll	ユーザーが独立した回答と、調整された推奨事項を必要としている場合	references/poll-protocol.md
debate	ユーザーが競合する方針を徹底的に検証したい場合	references/stance-rotation-schedule.md
personas	ユーザーが選択した1つのモデルから、5つの思考の視点を求めている場合	references/personas.md

すべてのモードで、対象プロジェクトは読み取り専用です。.ai-workflow/consensus/ 配下にあるローカル状態、応答アーティファクト、最終レポートのみ書き込み可能です。製品ファイルの編集、書き込み可能なツールの実行、実装の開始は行いません。

事前確認

承認記録、成果物の状態、応答の検証、復旧ルールについては、references/operations.md を使用してください。承認後に限り、references/runner-invocations.md を使用してください。承認済みのプレビューで cmux が選択されている場合に限り、references/cmux-transport.md を使用してください。

プレビューの前に、選択した実行経路をプローブしてください。ネイティブ機能チェックまたはランナーのプローブが成功しても、それは経路を開始できる可能性を示すだけです。ネイティブまたはプロバイダーが観測したサービングモデルのレシートによって、サービングモデルを確認できます。ラッパーが出力した effective_model ラベルでは確認できません。検証済みレシートのない応答はレポートの参考にはできますが、多様性への確信度を高めることはできません。

poll と debate では、要求されたモデルラベルが互いに異なる、承認済みのブラインドな冒頭役を3つ用意してください。シート登録には、オーガナイザーまたは審査員のみの役割を含められます。プロバイダーを3つ用意する必要はありません。3つのブラインドな冒頭レシートで観測されたモデルがそれぞれ異なることを検証できた場合に限り、冒頭の多様性をカウントしてください。登録済みの条件付き審査員は、冒頭の多様性には加算されません。検証済みのプロバイダーの多様性は補足的な根拠であり、シート数の要件ではありません。事前確認で経路をサポートできない場合は、阻害要因を報告し、3シートの修正案を提示してください。personas は独立した単一モデルモードです。このモードのプレビューでは、アドバイザー、レビュアー、議長のすべての呼び出しに使用するモデルを明示する必要があります。

poll では、承認前に中心となるポリシーを決定してください。security、money、migrations、public_contracts、data_loss、deep_review、high_risk が指定された場合は、standard を選択します。これらのリスクフラグのいずれかがある状態で明示的に lean を要求した場合、承認前に失敗とします。代わりに、修正版の standard プレビューを提示してください。lean では、ネイティブまたはランナーの per_call トランスポートのみを使用します。cmux はオーガナイザーのエビデンスゲートに対応できないため、フィンガープリント作成、採用、またはリレーの前に lean を拒否します。

両方の lean 審査員経路は、呼び出しが条件付きである場合でも、事前確認してください。ユーザーはオーガナイザーのゲートの結果が判明する前に、正確な経路を承認する必要があるため、利用できない経路がある場合はプレビューを進められません。承認済みの審査員経路が利用できなくなり、オーガナイザーがその審査員を必要とする場合は、失敗を記録したままにし、統合時に審査員を迂回しないでください。

実行

承認後、references/operations.md の定義に従い、正確なプレビューから汎用の council CLI を初期化し、ディスパッチ前に各試行を予約します。タスクと役割ごとに、分離された永続コンテキストを作成します。すべての冒頭役割に、同じ中立的なブリーフ、読み取り専用のソース、ツールプロファイル、出力予算を渡します。冒頭役割は、スキーマの再試行または承認済みの不足修正の場合に限り、自身のコンテキストを再開できます。オーガナイザー、各判定者、統合担当者、アドバイザー、レビュー担当者、議長には、それぞれ個別のコンテキストを割り当てます。判定者は、冒頭役割やオーガナイザーの履歴を知らない状態で開始し、互いにコンテキストを共有しません。

標準の poll では、ブラインド形式の冒頭回答、オーガナイザーによる分析、最大1ラウンドの不足修正、2人の判定者、続いて統合を実行します。これにより、既存の基本呼び出し7回、条件付き不足修正3回、計画された各ステップにつき検証再試行1回、最大20回の呼び出しが維持されます。

軽量の poll では、ブラインド形式の冒頭回答を3回、オーガナイザーを実行した後、計画された任意の不足修正を3回実行します。オーガナイザーの応答には、通常の分析に加えて confidence と high_risk フィールドが含まれます。検証済みのオーガナイザー応答に material_gaps: true、重大な矛盾、承認済みポリシーのしきい値を下回る信頼度、または high_risk: true のいずれかがある場合は、統合前に両方の判定者を実行します。両方の判定者は引き続き分離され、それぞれ承認済みの正確なルートを使用します。不足修正が行われた場合でも、統合は両方の判定結果を待ちます。

これらの判定者の実行条件に該当しない場合、軽量の各判定者を conditional-not-needed として記録します。この記録は証拠であり、実行結果やカバレッジの欠落ではありません。検証済みのオーガナイザー応答アーティファクトと、その未加工のレシートダイジェストを参照する必要があります。ランタイムは統合前にこの証拠を検証します。呼び出し元が指定する理由によって、判定者を省略することはできません。通常の軽量プランは、基本呼び出し5回、条件付き呼び出し5回、計画された各ステップにつき検証再試行1回、最大20回の呼び出しで構成されます。明示的な承認により、より小さい再試行上限と、それに一致する最大回数を設定できます。

debate では、承認された回数のラウンドを、匿名化されたダイジェストと固定上限を用いて実行します。personas では、5つの視点、プレビューに含まれている場合は匿名化されたピアレビュー、続いて議長を実行します。

承認済みの呼び出しまたはセッション再開に失敗した場合は、失敗と記録済みのコンテキスト ID を状態に保持し、報告します。呼び出しを再送信する前に、保留中の呼び出しを照合します。代わりに別のモデルや、承認されていない新しいコンテキストを使用してはいけません。定足数が重大に失われた場合は、収集済みの証拠と、明確なプラン改定の選択肢を示して実行を終了します。

出力

.ai-workflow/consensus/{session_id}.md を返すか、書き込んで、次の内容を含めます。

1. 質問、モード、承認済みプレビュー、実際の実行記録。
2. 推奨事項と次のステップ1つ。
3. 合意点、異論、盲点、証拠の不足。
4. 回答の信頼度と多様性の信頼度を、それぞれ個別に記載。
5. 各担当のレシート：要求されたモデル、設定されたモデル、有効なモデル、観測されたモデルの各フィールド、レシートのステータスとソース、プロバイダー、ホスト、実行パス、推論強度の制御、役割コンテキストのステータス、失敗の有無。
6. 軽量の poll の場合は、プロファイル、ポリシーのスナップショット、リスクフラグ、トリガー判定、各 conditional-not-needed の証拠参照。

採用を判断する場合は、平易な言葉で次のいずれか1つの評価を使用します：採用、試用、保留、却下、対象外。証拠が不十分な場合は「保留：証拠不十分」とし、確認すべき内容を列挙します。

council が推奨事項を実装することはありません。ユーザーは後から、別の実装ワークフローを選択できます。