カウンシル（Council） は何をしますか？
曖昧な状況下での意思決定のために4人のアドバイザーを招集します：
- （コンテキスト内の）クロードの声
- 懐疑派（Skeptic）サブエージェント
- 実用主義者（Pragmatist）サブエージェント
- 批評家（Critic）サブエージェント
これは曖昧さの下での意思決定のためであり、コードレビュー、実装計画、アーキテクチャ設計のためのものではありません。
使用すべき場合
次のような場合にカウンシルを使用します：
- 決定に複数の信頼できる道筋があり、明らかな勝者がいない場合
- トレードオフを明示的に表面化する必要がある場合
- ユーザーがセカンドオピニオン、異論、または複数の視点を求めている場合
- 会話のアンカリングが現実的なリスクである場合
- Go / No-Goの判断が対抗的な挑戦から利益を得る場合
例：
- モノレポ vs ポリレポ
- 今出荷する vs 磨き上げるために保留する
- フィーチャーフラグ vs 完全ロールアウト
- スコープを簡略化する vs 戦略的な幅を維持する
使用すべきでない場合
| カウンシルの代わりに | 使用するスキル |
|---|---|
| 出力が正しいかどうかの検証 | santa-method |
| 機能を実装ステップに分解する | planner |
| システムアーキテクチャの設計 | architect |
| バグやセキュリティのためのコードレビュー | code-reviewer または santa-method |
| 単純な事実に関する質問 | 直接答えるだけ |
| 明らかな実行タスク | タスクを実行するだけ |
役割
| 声 | レンズ |
|---|---|
| アーキテクト | 正しさ、保守性、長期的な影響 |
| 懐疑派 | 前提への挑戦、単純化、前提の打破 |
| 実用主義者 | 出荷速度、ユーザーへの影響、運用上の現実 |
| 批評家 | エッジケース、デメリットリスク、障害モード |
3つの外部の声は、質問と関連コンテキストのみを渡して、新しいサブエージェントとして起動する必要があります。継続中の会話全体は渡しません。これがアンカリング防止のメカニズムです。
ワークフロー
1. 本当の質問を抽出する
決定を1つの明確なプロンプトに絞り込みます：
- 何を決定するのか？
- どのような制約が重要か？
- 何を成功と見なすか？
質問が曖昧な場合は、カウンシルを招集する前に1つの明確化質問をします。
2. 必要なコンテキストのみを収集する
決定がコードベース固有の場合：
- 関連するファイル、スニペット、イシューテキスト、またはメトリクスを収集する
- コンパクトに保つ
- 決定に必要なコンテキストのみを含める
決定が戦略的/一般的な場合：
- リポジトリのスニペットは、回答を実質的に変更するものでない限りスキップする
3. 最初にアーキテクトの立場を形成する
他の意見を読む前に、以下を書き留めます：
- あなたの初期の立場
- そのための最も強い3つの理由
- あなたの好む道における主なリスク
これを最初に行うことで、統合が単に外部の意見を反映するだけになるのを防ぎます。
4. 3つの独立した意見を並行して立ち上げる
各サブエージェントは以下を受け取ります：
- 決定質問
- 必要に応じてコンパクトなコンテキスト
- 厳格な役割
- 不要な会話履歴は含めない
プロンプトの形：
あなたは4人の声を持つ意思決定カウンシルの[役割]です。
質問：
[決定質問]
コンテキスト：
[関連するスニペットまたは制約のみ]
以下のように回答してください：
1. 立場 — 1〜2文
2. 理由 — 簡潔な箇条書き3つ
3. リスク — あなたの推奨における最大のリスク
4. 驚き — 他の意見が見落とす可能性があること1つ
直接的で、曖昧さを避けてください。300語以内に収めてください。
役割の強調：
- 懐疑派：フレーミングに挑戦し、前提を疑い、最もシンプルで信頼できる代替案を提案する
- 実用主義者：スピード、シンプルさ、現実世界での実行を最適化する
- 批評家：デメリットリスク、エッジケース、計画が失敗する理由を表面化する
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が実際にゲート要因かどうかを疑問視する
- 実用主義者は、信頼を損なわずに今何を出荷できるかを問う
- 批評家はサポート負荷、期待債務、ロールアウトの混乱に焦点を当てる
価値は全会一致ではありません。価値は、選択する前に不一致を判読可能にすることです。