council は何をしますか？
あいまいな決断のために4人のアドバイザーを招集します：
- コンテキスト内のClaudeの声
- Skeptic（懐疑論者）サブエージェント
- Pragmatist（現実主義者）サブエージェント
- Critic（批評家）サブエージェント
これはあいまいな状況下での意思決定のためのものであり、コードレビュー、実装計画、アーキテクチャ設計のためのものではありません。
使用するタイミング
以下の場合に評議会を使用します：
- 決定に複数の信頼できる選択肢があり、明らかな勝者がいない場合
- トレードオフを明示的に表面化する必要がある場合
- ユーザーがセカンドオピニオン、異議、または複数の視点を求めた場合
- 会話のアンカリングが実際のリスクとなる場合
- ゴー／ノーゴーの判断が敵対的な挑戦から恩恵を受ける場合
例：
- モノレポ vs ポリレポ
- 今すぐリリース vs 磨き上げてからリリース
- フィーチャーフラグ vs フルロールアウト
- スコープを簡素化 vs 戦略的広がりを維持
使用すべきでないタイミング
| 評議会の代わりに | 使用するスキル |
|---|---|
| 出力が正しいか検証する | santa-method |
| 機能を実装ステップに分解する | planner |
| システムアーキテクチャを設計する | architect |
| バグやセキュリティについてコードをレビューする | code-reviewer または santa-method |
| 単純な事実に関する質問 | 直接回答する |
| 明らかな実行タスク | タスクを実行する |
役割
| 声 | レンズ |
|---|---|
| Architect | 正確性、保守性、長期的な影響 |
| Skeptic | 前提の挑戦、簡素化、前提の打破 |
| Pragmatist | 出荷速度、ユーザーへの影響、運用の現実 |
| Critic | エッジケース、 downside リスク、障害モード |
3つの外部の声は、質問と関連コンテキストのみを、継続中の会話全体ではなく、新しくクリーンなサブエージェントとして起動する必要があります。これがアンカリング対策のメカニズムです。
ワークフロー
1. 本当の質問を抽出する
決定を1つの明示的なプロンプトに絞り込みます：
- 何を決定しているのか？
- どのような制約が重要か？
- 何を成功とするか？
質問があいまいな場合は、評議会を招集する前に1つ明確化の質問をします。
2. 必要なコンテキストのみを収集する
決定がコードベース固有の場合：
- 関連するファイル、スニペット、イシュー本文、またはメトリクスを収集する
- コンパクトに保つ
- 決定に必要なコンテキストのみを含める
決定が戦略的／一般的な場合：
- 答えを実質的に変える場合を除き、リポジトリのスニペットはスキップする
3. 最初にArchitectの立場を形成する
他の声を読む前に、以下を書き留めます：
- あなたの初期の立場
- そのための最も強い3つの理由
- あなたが好むパスにおける主なリスク
これを最初に行うことで、統合が単に外部の声を反映するだけになるのを防ぎます。
4. 3つの独立した声を並行して起動する
各サブエージェントは以下を受け取ります：
- 決定質問
- 必要な場合のコンパクトなコンテキスト
- 厳格な役割
- 不必要な会話履歴はなし
プロンプトの形：
あなたは4人の声を持つ意思決定評議会の[ROLE]です。
質問：
[決定質問]
コンテキスト：
[関連するスニペットまたは制約のみ]
以下で応答してください：
1. 立場 — 1-2文
2. 理由 — 簡潔な箇条書き3つ
3. リスク — あなたの推奨における最大のリスク
4. 驚き — 他の声が見逃すかもしれない1つのこと
直接的で、曖昧さを避けてください。300語以内に収めてください。
役割の強調：
- Skeptic：枠組みに挑戦し、前提を疑問視し、最もシンプルで信頼できる代替案を提案する
- Pragmatist：スピード、シンプルさ、現実世界での実行を最適化する
- Critic： downside リスク、エッジケース、計画が失敗する理由を表面化する
5. バイアスガードレール付きで統合する
あなたは参加者であり統合者でもあるため、以下のルールを使用します：
- 理由を説明せずに外部の見解を却下しない
- 外部の声があなたの推奨を変えた場合は、明示的にそう述べる
- 最も強い反対意見を、たとえそれを却下する場合でも、常に含める
- 2つの声があなたの初期の立場に反して一致した場合、それを実際のシグナルとして扱う
- 評決の前に、生の立場を表示したままにする
6. コンパクトな評決を提示する
以下の出力形式を使用します：
## Council: [短い決定タイトル]
**Architect：** [1-2文の立場]
[理由を1行]
**Skeptic：** [1-2文の立場]
[理由を1行]
**Pragmatist：** [1-2文の立場]
[理由を1行]
**Critic：** [1-2文の立場]
[理由を1行]
### 評決
- **コンセンサス：** [一致した点]
- **最も強い反対意見：** [最も重要な不一致]
- **前提チェック：** [Skepticは質問自体に挑戦したか？]
- **推奨事項：** [統合されたパス]
スマートフォンの画面でもスキャン可能に保ちます。
永続化ルール
このスキルから ~/.claude/notes やその他のシャドウパスにアドホックなメモを書き込まないでください。
評議会が推奨事項を実質的に変更した場合：
knowledge-opsを使用して、教訓を適切な永続的な場所に保存する- または、結果がセッションメモリに属する場合は
/save-sessionを使用する - または、決定がアクティブな実行の真実を変更する場合は、関連するGitHub / Linearイシューを直接更新する
決定が実際に何かを変える場合にのみ永続化します。
複数ラウンドのフォローアップ
デフォルトは1ラウンドです。
ユーザーが別のラウンドを希望する場合：
- 新しい質問に焦点を当てたままにする
- 前回の評決は必要な場合にのみ含める
- Skepticを可能な限りクリーンに保ち、アンカリング防止の価値を維持する
アンチパターン
- コードレビューに評議会を使用する
- タスクが単なる実装作業である場合に評議会を使用する
- サブエージェントに会話の全トランスクリプトを渡す
- 最終評決で不一致を隠す
- 重要度に関係なくすべての決定をメモとして永続化する
関連スキル
santa-method— 敵対的検証knowledge-ops— 決定の差分を正しく永続化するsearch-first— 必要に応じて評議会の前に外部参照資料を収集するarchitecture-decision-records— 決定が長期的なシステムポリシーになった場合に結果を形式化する
例
質問：
ECC 2.0を今すぐアルファとしてリリースすべきか、それともコントロールプレーンUIがより完成するまで待つべきか？
考えられる評議会の形：
- Architectは構造的な整合性と混乱した表面を避けることを推す
- SkepticはUIが実際にゲート要因であるかどうかを疑問視する
- Pragmatistは信頼を損なわずに今すぐ出荷できるものを問う
- Criticはサポート負荷、期待負債、ロールアウトの混乱に焦点を当てる
価値は全会一致ではありません。価値は、選択する前に不一致を読み取れるようにすることです。