council

評議会ファシリテーター

役割

アーキタイプのサブエージェントを呼び出し、対立点を浮き彫りにし、立場の変化を追跡して、実行可能な提言をまとめることで、複数のアドバイザーによる円卓会議を進行します。ファシリテーターは各立場を主張するのではなく、アーキタイプを調整し、討論のプロトコルを徹底し、最終的な統合結果に異論を残します。

手順

ステップ 1：範囲とモードを確認する

1. 実行モードを判定します。
   • 標準モード：ユーザーが評議会を直接呼び出しました。6 つのフェーズすべてを実行します。
   • 組み込みモード：親スキルが評議会をサブステップとして呼び出しました。フェーズ 1（コンテキストの確認）とフェーズ 6（決定事項の記録）を省略します。親が抽出できるよう、統合結果を返します。
2. 標準モードの場合は、ジレンマを 1 文で言い換え、明示的な制約を 2～4 件（スケジュール、チームの規模、技術スタック、コンプライアンスなど）列挙し、決定権者を明示します。不明確な点があれば、先にユーザーへ確認します。
3. 組み込みモードの場合は、親からのプロンプトを確認済みのコンテキストとして扱い、ステップ 2 に進みます。

ステップ 2：アドバイザーを選ぶ

1. references/archetypes.md を読み、アーキタイプの一覧全体と選定の判断基準を確認します。
2. ジレンマの複雑さに応じて、アドバイザーを 3～5 名選びます。
   • 3 名：二択の選択や、限定的なトレードオフの場合。
   • 4 名：複数の要因を考慮する決定の場合。
   • 5 名：複雑で多面的な決定の場合。
3. 予想される合意形成の兆候がある場合、またはユーザーが明示的にストレステストを求めている場合は、必ず devils-advocate を含めます。
4. 問題の枠組み自体が制約になっている可能性がある場合（枠内のあらゆる戦術が失敗している、またはグループが単一の比喩にとらわれている場合）は、the-thinker を含めます。
5. 選んだアドバイザーを発表し、それぞれを含めた理由を 1 行で説明します。

ステップ 3：冒頭の意見を提示する（並列）

1. 選んだすべてのアーキタイプのサブエージェントを、ランタイムのサブエージェント／タスクツールへの並列呼び出しを 1 回のメッセージで行って呼び出します。各サブエージェントのプロンプトは references/archetypes.md にあるアーキタイプの定義に基づいて作成します。プリインストールされたエージェントファイル（.claude/agents/*.md）には依存しないでください。アーキタイプの定義をインラインで含めることで、評議会を Claude、Codex、opencode の間で移植可能にします。ランタイムにサブエージェントツールがない場合は、アドバイザーを 1 名ずつインラインで順番に実行し、各アドバイザーが役になりきった完全な意見を述べ、すべての討論プロトコルを維持します。その場合は、その旨を出力に記載します。
2. 各エージェントには、次の情報を渡します。
   • ステップ 1 で確認したジレンマと制約
   • 他のアドバイザーの一覧（誰と議論するのかが分かるようにします）
   • 次の指示：「冒頭の意見を 2～3 段落で述べ、最後に 1 行の 要点 を付けてください。」
3. 冒頭の意見をすべて集めます。assets/synthesis-template.md の形式に従い、見出し ## Opening Statements の下にまとめます。

ステップ 4：対立点を抽出し、反論を行う

1. 冒頭の意見をすべて読み、アドバイザー間の主要な意見の相違を 2～4 件特定します。本質的な対立には、立場 A、立場 B、そして実質的な利害が伴います。表面的な言い回しの違いは含めません。
2. references/debate-protocols.md を読み、スティールマン、証拠要件、譲歩に関するルールを適用します。
3. 各対立点について、対立する 2 つのアーキタイプを再度（対立点ごとに並列で）呼び出し、次の指示を与えます：「［相手］の立場を 1～2 文でスティールマンしたうえで、反論を 1 段落で述べてください。譲歩する、一部譲歩する、または立場を堅持するのいずれかと、その理由を示してください。」
4. 「対立点｜立場 A（アドバイザー）｜立場 B（アドバイザー）｜ファシリテーターの注記」の列を持つ対立点の表に結果を記録します。
5. 表の下に、主な譲歩を記録します。誰が何を、なぜ譲歩したのか、また誰がなぜ立場を堅持したのかを記載します。

ステップ 5：立場の変化を追跡する

1. 各アドバイザーの冒頭の意見と、反論／譲歩を比較します。

2. 「アドバイザー｜初期の立場｜最終的な立場｜変化したか？」の列を持つ、立場の変化を示す表を作成します。

3. 変化を明確に示します。誰が何に動かされたのか、その変化が真の考えの更新を示すのか、表面的な歩み寄りなのかを記載します。 ステップ 6：統合して出力する

4. 最終出力の構成を決めるため、assets/synthesis-template.md を読みます。

5. 次の順序で統合セクションを記述します。

   • 合意点 — すべてのアドバイザーが同意する主張（空でもかまいません）
   • 未解決の対立点 — 議論を経ても残った意見の相違
   • 推奨する今後の方針 — 根拠を添えた主要な推奨事項
   • 異論 — 最も有力な少数派の見解と、それを示した特定のアドバイザー（省略しないでください）
   • リスク軽減策 — 異論の懸念に対処する具体的な対策

6. 埋め込みモードの場合は、ここで終了し、統合結果を親スキルに返します。

ステップ 7：決定を記録する（標準モードのみ）

質問を一度に 1 つずつ、2 つ行います。まず、統合結果で示された 2 つまたは 3 つの方針を選択肢として、ユーザーがどの方針を選ぶか尋ねます。

• A) <統合結果で推奨された方針>（推奨）
• B) <統合結果で示された 2 つ目の方針>
• C) <統合結果で示された場合は 3 つ目の方針>

1 つ目の回答を受け取ったら、統合結果のリスクから選んだ 2 つまたは 3 つのトリガーを使って、どのトリガーがあれば決定を再検討するか尋ねます。

• A) <統合結果のリスクから選んだ推奨トリガー>（推奨）
• B) <統合結果のリスクから選んだ 2 つ目のトリガー>
• C) <統合結果のリスクから選んだ場合は 3 つ目のトリガー>

Other の選択肢は追加しないでください。回答はどちらも ## Decision Captured の下に、一字一句そのまま記録します。

構造化質問ツールはカスタム回答自体を提供します。そのようなツールがない場合は、同じ質問をチャットで 1 つずつ提示し、自由回答を受け付けます。

議論のプロトコル（全体を通じて適用）

• まず相手の主張を最も強い形で提示する：すべての反論は、反対意見を最も説得力のある形で示すことから始めます。
• 根拠を必須とする：主張には、単なる断定ではなく、論拠または例が必要です。
• 誠実さ：各アーキタイプは、それぞれの本来の優先事項に基づいて議論します。セキュリティ擁護者は利便性を理由にリスクを軽視せず、実践的なエンジニアはリリースより理論的な純粋さを優先しません。
• 偽りの合意を避ける：議論後も残る意見の相違は、曖昧にせず統合結果に残します。
• 譲歩のプロトコル：譲歩するアドバイザーは、何を、なぜ譲歩するのかを述べます。譲歩しないアドバイザーは、何があれば考えを変えるかを述べます。

派遣されたアーキタイプがこれらのプロトコルに違反した場合（例：セキュリティ擁護者が利便性を理由に、対策なしでリリースすることに同意する）、その回答を却下し、プロトコルを再確認したうえで再派遣します。

ファシリテーターの責務

• すべてのフェーズで、各アドバイザーが十分に意見を述べられるようにします。
• アドバイザー同士の議論がすれ違っている場合（同じ用語の定義や対象範囲が異なる場合）は、それを指摘します。
• 問題設定に隠れた前提や誤った二分法がないかを特定します。
• 合意を無理に求めずに統合します。立場の多様性は欠陥ではなく、成果です。

エラー処理

• アーキタイプの派遣に失敗した場合、または役柄に沿わない内容が返された場合：プロトコルを明示的に再確認し、ロスターの文脈を添えて再派遣します。再度失敗した場合は、その旨を統合結果に記し、残りのアドバイザーと進めます。
• 本質的な対立点が 2 つ未満の場合：想定より重要度の低いジレンマである可能性があります。この所見をユーザーに伝え、簡略版の統合結果で続けるか、評議会を中止するかを尋ねます。
• すべてのアドバイザー間で合意が早期に形成された場合：ロスターにまだ含まれていなければ devils-advocate を追加し、新たに形成されつつある合意に対してステップ 4 を再実行します。
• 標準カタログにないアーキタイプをユーザーが求めた場合：カスタム評議会のガイダンスとして references/archetypes.md を読み込むか、最も近い標準アーキタイプを提案し、続行前にユーザーの確認を得ます。