council

Council

Council は、対照的な視点によって代替案、前提、見落とされた証拠を明らかにできる、難しい質問向けの任意の判断戦略です。呼び出し側がブレインストーミング、アーキテクチャ設計、計画、または検証のために複数の視点を選択した場合に使用します。追加のコンテキストが役立つ理由となる不確実性を明示してください。定型的な作業に Council は不要です。関連する手法として、計画に対する敵対的な課題を提示するのが Premortem、Plan に関する重要な選択を行うのが Idea Genie、受け入れ判定を行うのが Validate です。

統合を決めるルール

これらのルールは、実行する Council にも、呼び出し側がすでに別の場所で集めた判断（複数のレビューやサブエージェントによる調査）を統合するよう求めた場合にも適用されます。

• 判定はしません。 Council は、PASS、FAIL、NOT_PROVEN、準備状況、承認のいずれも返しません。合意をこうした判定に変えるよう求められた場合も、対応を断り、新たに実施する Validate の読み取りがその判定を担うことを伝えてください。Council の報告は、その判断に対する助言的な入力です。
• 反響するコンセンサスは一つとして扱います。 同じモデルまたは同じ証拠の手法を共有する判定者間の合意は、何人が共有していても、一つの確認として数えます。コンセンサスに関するすべての主張について、その背後にある手法とモデルを明示してください。
• 呼び出し側の方針を既定のまま維持します。 呼び出し側の決定に反する判断は、5つのフィールドすべてを備えた caller_challenge エントリーにします。コンセンサスの要点にしたり、推奨内容をひそかに変更したりしてはいけません。
• 何も除外しません。 共有する前に初期の見解をすべて確定し、各所見を必ず一つの統合カテゴリに分類し、異論を残します。

Council の実施

用途	各参加者に求める内容	呼び出し側に返す内容
ブレインストーミング	独自の選択肢、前提、失敗の可能性	有望なアイデアと、検証する価値のある反論
設計または計画	提案するアプローチ、トレードオフ、証拠	未解決の判断事項を明示した推奨事項
検証	同じ対象と受け入れ基準に基づく所見	責任を負う新たな検証担当者への助言的な所見
デュエル	ランク付けしたアイデア、その後、他の各メンバーのアイデアに対するスコア	メンバー間の合意に基づいてランク付けしたアイデア、スコアの差、異論
面接パネル	Interview の各質問への回答	呼び出し側が承認または修正する、合意された回答と未確定の回答

1. 質問、制約または受け入れ基準、認可された証拠、対象のダイジェストを確定します。参加者、モデルの固定指定、実際のディスパッチ上限を選択します。呼び出し側は、各参加者に個別のモデル、推論の労力、視点（たとえば、アーキテクト、信頼性、セキュリティ、シンプルさ）を割り当てられます。別々のコンテキストで同じモデルを使用しても、名簿上は別の参加者として扱われますが、その合意は引き続き一つのモデルによる確認として数えます。
2. 各参加者に、新しく独立したコンテキストと同一の範囲に制限した情報パケットを渡します。作成者が望む結論は決して伝えません。視点はメンバーが何を調べるかを導くものであり、得られる証拠を左右するものではありません。他の参加者の回答を開示する前に、提案または判断を集めます。コンテキスト ID が再利用されている、または衝突している場合、その見解は独立していません。上限の範囲内で分離を修復するか、その旨を開示してください。
3. 証拠、推論、見落としを明示するよう求めます。ブレインストーミングでは、新たな仮説と、裏付けのある主張を区別します。新規性は証明ではありません。
4. 確定済みの初期の見解を統合するか、以下のうち呼び出し側が選択したモードを実行します。異論と見解の変化を残します。
5. 推奨事項とその限界を含む council-report.v1 を返します。Council は対象を変更せず、実装または納品の権限も付与しません。

独立した比較を既定とします。複数のモデルによって提示される視点の幅は広がりますが、合意だけでは改善を証明できません。

オプションのモード

呼び出し元が選択したモードのみを読み込みます。

• 範囲を限定した議論または多数決ルール：議論。先行する回答を見た返信は、他の参加者の見解を踏まえたものであり、新たな独立した見解ではありません。また、多数決によって真実や承認が確立されることはありません。
• メンバー同士でアイデアを採点する場合：デュエル。
• インタビューに回答する評議会：インタビューパネル。
• 修正後も残る検証ジャッジ間の不一致：ジャッジの意見相違。

手法を重み付けした合意

異なるエビデンス手法間の合意は、同じ手法内の合意よりも重く扱います。各ジャッジのエビデンス手法（静的な読解、対象の実行、履歴の追跡など）を、判断とともに記録してください。コンセンサスを主張するには、それを支持するジャッジの中に少なくとも2つの異なる手法が含まれている必要があります。そうでない場合は単一手法による合意として報告し、何人のジャッジが支持していても、1つの確認として重み付けしてください。ここでいう失敗モードはエコーコンセンサスです。つまり、1つの共通手法により同一の入力から全員一致の判断が生み出され、それが独立した確認であるかのように見せかけられることです。

モデル多様性の軸

デフォルトでは、Codex と Claude の両方で、作者のモデルファミリーに属する新しいコンテキストを使用します。呼び出し元は明示的に混合モデルファミリーによるレビューを選択し、agent-native のモデルディスパッチレシピにある範囲限定アダプターを使用して各モデルを固定できます。レビュー時間は呼び出し元またはネイティブ側の制限に従い、固定の10分上限はありません。固定した各ジャッジの model_identity を、その手法およびコンテキスト ID とともに記録してください。単一モデルでの全員一致は、単一手法での合意と同じ理由から、1つの確認として重み付けします。要求されたプロファイルに許可済みのライブアダプターがない場合は、diversity_unsatisfied を開示してください。制限を明示すれば、利用可能な見解を返してもかまいませんが、不足している要件を満たすことにはなりません。必須のモデルファミリー横断検証が未達成の場合、収束を妨げます。Council は、その代わりに単一モデルでの合意を用いることはできません。

呼び出し元への異議

合意の形のうち、決して統合してはならないものがあります。**判定者全員が、呼び出し元の明示した方針は誤りだと同意する場合です。**呼び出し元に反対する独立した合意は強いシグナルですが、それ自体が決定権を持つわけではありません。呼び出し元は、どの判定者にも与えられていない文脈を把握しているため、判定者の立場を提言に織り込む統合を行うと、その文脈を、覆されたことを誰にも知らせずに消し去ってしまいます。

判定によって、呼び出し元が指定した内容の変更が推奨される場合（分けていたものを統合する、求めていたものを削除する、明示した方針を覆すなど）は、合意点ではなく、caller_challenge エントリーとして記録してください。次の5つのフィールドを使用します。任意の judge_count には少なくとも2人の支持者が必要です。また、disagreement_kind で異議の種類を分類します。

• caller_stated：呼び出し元の方針を、言い換えずにそのまま記載します。
• judges_recommend：変更内容、支持者、および各判定者の見解が独立したものか、他者の意見を踏まえたものかを記載します。議論中の投票を独立した判断として記述してはいけません。
• reasoning：最も説得力のある根拠を記載します。
• context_possibly_missing：判定者に与えられていなかったことを、証拠に基づいて記載します。これがエントリーを誠実なものにするフィールドであり、最も省略されやすいフィールドです。このフィールドがなければ、新たなラベルを付けただけの多数派によるすり替えです。
• cost_if_wrong：呼び出し元の方針が正しかった場合に何が損なわれるかを記載します。

呼び出し元の方針がレポートの既定であり、既定のまま維持されます。立証責任は判定者側にあります。判定者が、その変更を好みの問題ではなくセキュリティまたは実現可能性の欠陥として分類する場合は、どちらなのかを記載してください（disagreement_kind）。異議の種類を把握したうえで、最終的な判断は引き続き呼び出し元が行います。

この失敗モードをひそかな採用と呼びます。評議会が呼び出し元に反対する形で意見を収束させ、あたかも呼び出し元が最初から判定者の案を求めていたかのように読める統合結果を返すことです。停止条件：呼び出し元が明示した方針に反するすべての判断を、5つのフィールドをすべて含む caller_challenge に記載するか、レポートに記載しないこと。異議の対象となった決定を取り消せるかどうかは、実際の取り消しコストと既存の権限を踏まえ、Plan に記載します。評議会は、どちらも当然のことと見なしてはいけません。

統合セクション

レポートの末尾には、合意点と相違点を明示した統合結果を記載します。合意点には各手法の広がりを、相違点には各立場が引用した証拠を記載し、少数意見の所見はそのままの言葉で残します。また、未解決の前提と caller_challenge エントリーも記載します。すべての判定者の所見が、これらのいずれか一つに正確に分類されたとき、統合は完了です。統合から所見をひそかに除外することは、多数派によるすり替えです。

出力

• **保存先：**呼び出し元が選択した、保護された外部の非 Git ストレージです。既存のレガシー証拠は保持してください。保存先が指定されていない場合に、ワークスペースへフォールバックしてはいけません。保存先が指定されていなければ、レポートを会話内にインラインで返し、ファイルは書き込みません。
• ファイル名：council-report.json。
• 形式：council-report.v1 JSON。凍結された質問と対象のダイジェスト、各判定者のコンテキスト ID、証拠の方法論、引用された証拠、開示された欠落事項に加え、合意点／相違点／少数意見／未解決事項の統合結果と、すべての caller_challenge エントリーを含めます。各 judgment と方法論および参照元の参照先には、既存のフィールドを使ってモードと候補のダイジェストを記録してください。新しいスキーマは不要です。verdict、readiness、PASS フィールドは含めません。バリデーターはこれらを拒否します。
• **検証コマンド：**このスキルの scripts/validate-output.sh <council-report.json>。

タイムアウト、エラー、または証拠のない判定を返した判定者は、合意の集計対象から除外し、未回答として記録します。適格な初回判定が2件未満の場合は、薄い合意を統合するのではなく、独立した検討範囲が不十分であると報告してください。有効なレポートを作成できない場合は、判定者の記録を捏造せず、不完全な結果と入手可能な証跡を返してください。

プロンプト

Use /agentops:council to compare architectures for reliable Job redelivery.
Use four distinct available models I authorize for this source. Have each
propose an approach independently, then debate the alternatives. Require
three of four to support the same exact recommendation. Cap debate at five
rounds and the whole council at 60 minutes. Preserve objections and explain
what evidence we still need before implementation or validation.

ディスパッチ前に、実際に承認されたモデルのピン留めを解決してください。これらの範囲例は呼び出し側の選択であり、スキルのデフォルトではありません。検証では、変更していない受け入れ条件と正確な候補を提示し、PASS に投票せず、調査結果を新しいバリデーターに返してください。

次の状態であれば正常に動作しています

• 相互レビューの前に初期見解が封印されており、議論がある場合は範囲が限定され、ピアからの情報を受けたものとしてラベル付けされ、正確な候補への投票と反対意見が保持されています。
• すべての判定者の調査結果が、ちょうど1つの統合バケットに分類されています。いずれも抜け落ちていません。
• 呼び出し側が明示した方向性と矛盾する判定は、5つすべてのフィールドを含む caller_challenge エントリーとして記載されており、合意事項として扱われていません。
• すべての合意に関する主張で、少なくとも2つの異なるエビデンス手法が示されているか、単一手法による一致とラベル付けされ、確認1件として重み付けされています。
• レポート内のどこにも verdict、readiness、PASS フィールドがありません。

境界

Council は、いかなるバージョンの判定も作成しません。PASS／FAIL／NOT_PROVEN や verdict.v* を出力せず、対象の編集、作業の再試行、次のアクションの選択、Git、クローズ、リリース、納品の承認も行いません。Council を Validate 戦略として使用する場合は、責任を負う新しいバリデーターがそのレポートを受け取り、Validate が唯一のセマンティックな結果の管理者であり、任意の verdict.v2 を記述できる唯一の主体であり続けます。