JunMystery/Agent-Guidance-Rust

評議会（Council）

あいまいな意思決定のために4人のアドバイザーを招集します：

• コンテキスト内のClaudeの声
• 懐疑論者（Skeptic）サブエージェント
• 現実主義者（Pragmatist）サブエージェント
• 批評家（Critic）サブエージェント

これはあいまいさの下での意思決定のためのものであり、コードレビュー、実装計画、アーキテクチャ設計には使用しません。

使用するタイミング

次の場合に評議会を使用します：

• 決定に複数の信頼できる道筋があり、明らかな勝者がいない場合
• 明示的なトレードオフの提示が必要な場合
• ユーザーがセカンドオピニオン、異議、または複数の視点を求めた場合
• 会話のアンカリングが現実的なリスクである場合
• 実行/不実行の判断が敵対的な挑戦から恩恵を受ける場合

例：

• モノレポ vs ポリレポ
• 今すぐリリース vs 磨き上げるまで待つ
• フィーチャーフラグ vs 完全ロールアウト
• スコープの簡略化 vs 戦略的広がりの維持

使用すべきでないタイミング

評議会の代わりに	使用するスキル
出力が正しいかどうかの検証	santa-method
機能を実装ステップに分解	planner
システムアーキテクチャの設計	architect
バグやセキュリティのコードレビュー	code-reviewer または santa-method
単純な事実に関する質問	直接回答する
明らかな実行タスク	単にタスクを実行する

役割

声	レンズ
アーキテクト	正確性、保守性、長期的な影響
懐疑論者	前提への挑戦、簡略化、前提の打破
現実主義者	リリース速度、ユーザーへの影響、運用の現実
批評家	エッジケース、 downside リスク、障害モード

3つの外部の声は、質問と関連コンテキストのみを渡して、新たなサブエージェントとして起動する必要があります。完全な進行中の会話は渡しません。それがアンカリング防止の仕組みです。

ワークフロー

1. 本当の質問を抽出する

決定を1つの明確なプロンプトにまとめます：

• 何を決定しているのか？
• どのような制約が重要か？
• 何が成功と見なされるか？

質問があいまいな場合は、評議会を招集する前に1つ明確化の質問をします。

2. 必要なコンテキストのみを収集する

決定がコードベース固有の場合：

• 関連するファイル、スニペット、課題テキスト、またはメトリクスを収集します
• コンパクトに保ちます
• 決定に必要なコンテキストのみを含めます

決定が戦略的/一般的な場合：

• 答えを実質的に変更しない限り、リポジトリのスニペットはスキップします

3. 最初にアーキテクトの立場を形成する

他の声を読む前に、以下を書き留めます：

• あなたの初期の立場
• そのための3つの最も強い理由
• あなたの好む道における主なリスク

これを最初に行うことで、統合が単に外部の声を反映するだけになるのを防ぎます。

4. 3つの独立した声を並行して起動する

各サブエージェントは以下を受け取ります：

• 決定質問
• 必要な場合のコンパクトなコンテキスト
• 厳格な役割
• 不要な会話履歴はなし

プロンプトの形式：

あなたは4人の声による意思決定評議会の[役割]です。

質問：
[決定質問]

コンテキスト：
[関連するスニペットまたは制約のみ]

次のように応答してください：
1. 立場 — 1～2文
2. 理由 — 3つの簡潔な箇条書き
3. リスク — あなたの推奨における最大のリスク
4. 驚き — 他の声が見落とす可能性があること1つ

直接的で、曖昧さを避けてください。300語以内に収めてください。

役割の強調：

• 懐疑論者：枠組みに挑戦し、前提を疑い、最もシンプルで信頼できる代替案を提案する
• 現実主義者：スピード、シンプルさ、現実世界の実行を最適化する
• 批評家： downside リスク、エッジケース、計画が失敗する可能性のある理由を明らかにする

5. バイアスガードレールを使って統合する

あなたは参加者であり統合者でもあるため、次のルールを使用します：

• 理由を説明せずに外部の見解を却下しない
• 外部の声によって推奨が変わった場合は、その旨を明示する
• たとえそれを却下する場合でも、最も強い反対意見を常に含める
• 2つの声があなたの初期の立場に反して一致した場合、それを実際のシグナルとして扱う
• 評決の前に生の立場を表示可能にしておく

6. コンパクトな評決を提示する

次の出力形式を使用します：

## 評議会: [短い決定タイトル]

**アーキテクト:** [1～2文の立場]
[理由の1行]

**懐疑論者:** [1～2文の立場]
[理由の1行]

**現実主義者:** [1～2文の立場]
[理由の1行]

**批評家:** [1～2文の立場]
[理由の1行]

### 評決
- **一致点:** [合意した点]
- **最も強い反対意見:** [最も重要な不一致]
- **前提チェック:** [懐疑論者が質問自体に挑戦したか？]
- **推奨:** [統合された道]

スマートフォンの画面でスキャン可能に保ちます。

永続化ルール

このスキルから ~/.claude/notes やその他のシャドウパスにアドホックなメモを書き込まないでください。

評議会が推奨を実質的に変更した場合：

• knowledge-ops を使用して、教訓を適切な永続的な場所に保存します
• または、結果がセッションメモリに属する場合は /save-session を使用します
• または、決定がアクティブな実行の真実を変更する場合は、関連するGitHub/Linearの課題を直接更新します

決定が実際に何かを変える場合にのみ永続化します。

複数ラウンドのフォローアップ

デフォルトは1ラウンドです。

ユーザーが別のラウンドを希望する場合：

• 新しい質問に焦点を当てます
• 前回の評決は必要な場合にのみ含めます
• アンカリング防止の価値を維持するために、懐疑論者を可能な限りクリーンに保ちます

アンチパターン

• コードレビューに評議会を使用する
• タスクが単なる実装作業である場合に評議会を使用する
• サブエージェントに会話の全トランスクリプトを渡す
• 最終評決で不一致を隠す
• 重要性に関係なくすべての決定をメモとして永続化する

関連スキル

• santa-method — 敵対的検証
• knowledge-ops — 耐久性のある決定デルタを正しく永続化する
• search-first — 必要に応じて評議会の前に外部参考資料を収集する
• architecture-decision-records — 決定が長期的なシステムポリシーになった場合に結果を形式化する

例

質問：

ECC 2.0をアルファ版として今リリースすべきか、それともコントロールプレーンUIがより完成するまで待つべきか？

予想される評議会の形：

• アーキテクトは構造的完全性と混乱した表面を避けることを推す
• 懐疑論者はUIが実際にゲーティングファクターであるかどうかを問う
• 現実主義者は信頼を損なわずに今すぐリリースできるものを問う
• 批評家はサポート負荷、期待負債、ロールアウトの混乱に焦点を当てる

価値は全会一致ではありません。価値は、選択する前に不一致を読み取れるようにすることです。