顧問団

曖昧な決定を下す際に、4人の顧問を招集します：

• コンテキスト内のClaudeの声
• 懐疑論者サブエージェント
• 実用主義者サブエージェント
• 批評家サブエージェント

これは曖昧性下での意思決定に適用され、コードレビュー、実装計画、またはアーキテクチャ設計には適用されません。

使用する場面

以下の場合に顧問団を使用します：

• 複数の実行可能なパスが存在し、明らかな優位者がない決定
• トレードオフの明確化が必要
• ユーザーが第二意見、異議、または複数の視点分析をリクエストしている
• 会話アンカリング効果の実際のリスクが存在する
• 対立的チャレンジを通じて「実行/放棄」決定を最適化できる

例：

• 単一リポジトリ vs マルチリポジトリ
• 即座にリリース vs ポーリッシュしてリリース
• フィーチャーフラグ vs フルロールアウト
• スコープの簡略化 vs 戦略的な広がりの維持

使用しない場面

顧問団を使用すべきでない場合	代わりに使用する
出力が正しいか検証する	santa-method
機能を実装ステップに分解する	planner
システムアーキテクチャを設計する	architect
コード内のエラーまたはセキュリティ脆弱性をレビューする	code-reviewer または santa-method
直接的な事実の問題	直接回答する
明確な実行タスク	直接実行する

役割

声	視点
アーキテクト	正確性、保守性、長期的影響
懐疑論者	前提に疑問を呈する、簡潔にする、仮定を破る
実用主義者	配信速度、ユーザーへの影響、運用上の現実
批評家	エッジケース、下行リスク、失敗モード

3つの外部の声は新しいサブエージェントとして起動し、問題と関連コンテキストのみを提供し、完全な会話履歴は提供しないようにします。これはアンカリング防止メカニズムです。

ワークフロー

1. 真の問題を抽出する

決定を明確なプロンプトに簡略化します：

• 何を決定しているのか？
• どの制約条件が重要か？
• 成功とは何か？

問題が曖昧な場合は、顧問団を招集する前に澄清の質問を提起します。

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

決定がコードベースに関連している場合：

• 関連するファイル、コードスニペット、問題説明、またはメトリクスを収集
• 簡潔に保つ
• 決定に必要なコンテキストのみを含める

決定が戦略的または一般的な場合：

• 答えを実質的に変える場合を除き、リポジトリコードスニペットをスキップ

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

他の声を読む前に、以下を記述します：

• あなたの初期立場
• その立場をサポートする3つの最強の理由
• 推奨パスの主な危険性

このステップを最初に完了して、総合的な意見が外部の声を単に反映しないようにします。

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

各サブエージェントが受け取るもの：

• 決定問題
• 必要な簡潔なコンテキスト
• 厳密な役割定義
• 余分な会話履歴なし

プロンプトテンプレート：

あなたは四声部の意思決定委員会の[役割]です。

問題：
[決定問題]

背景：
[関連スニペットまたは制約条件のみを含める]

回答形式：
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が本当にボトルネックなのか疑問を呈する
• 実用主義者：信頼を損なわずに今配信できることを質問する
• 批評家：サポート負担、期待債務、ロールアウト混乱に焦点を当てる

価値は合意に達することではありません。価値は選択の前に分歧を明らかにすることにあります。