mturac カウンシル
曖昧な決定のために4人のアドバイザーを召集します：
- コンテキスト内のCodexの声
- 懐疑論者のサブエージェント
- 現実主義者のサブエージェント
- 批評家のサブエージェント
これは曖昧さの下での意思決定のためのものであり、コードレビュー、実装計画、またはアーキテクチャ設計のためではありません。
使用時期
以下の場合にカウンシルを使用します：
- 決定に複数の信頼できるパスがあり、明らかな勝者がない場合
- 明示的なトレードオフの表面化が必要な場合
- ユーザーが別の意見、反対意見、または複数の視点を求める場合
- 会話のアンカリングが実際のリスクである場合
- ゴー/ノーゴーの判断が敵対的な挑戦から利益を得る場合
例：
- モノレポ vs ポリレポ
- 今すぐリリース vs 磨きのために保留
- フィーチャーフラグ vs フル展開
- スコープを簡略化 vs 戦略的な広さを保つ
使用すべきでない場合
| カウンシルの代わりに | 使用するもの |
|---|---|
| 出力が正しいかどうかの検証 | santa-method |
| フィーチャーを実装ステップに分解する | planner |
| システムアーキテクチャの設計 | architect |
| バグやセキュリティのコードレビュー | code-reviewerまたはsanta-method |
| 直接的な事実の質問 | 直接答える |
| 明らかな実行タスク | タスクをやる |
役割
| 声 | レンズ |
|---|---|
| アーキテクト | 正確さ、保守性、長期的な影響 |
| 懐疑論者 | 前提の挑戦、単純化、仮定の打破 |
| 現実主義者 | リリース速度、ユーザーへの影響、運用上の現実 |
| 批評家 | エッジケース、下降リスク、失敗モード |
3つの外部の声は、質問と関連コンテキストのみで新鮮なサブエージェントとして起動され、進行中の会話全体ではありません。これがアンチアンカリングメカニズムです。
ワークフロー
1. 本当の質問を抽出する
決定を1つの明示的なプロンプトに縮小します：
- 何を決定しているのか？
- どの制約が重要か？
- 何が成功とみなされるか？
質問が曖昧な場合、カウンシルを召集する前に1つの明確化質問をします。
2. 必要なコンテキストのみを収集する
決定がコードベース固有の場合：
- 関連するファイル、スニペット、課題テキスト、またはメトリクスを収集
- コンパクトに保つ
- 決定を行うために必要なコンテキストのみを含める
決定が戦略的/一般的な場合：
- 答えを実質的に変えない限りリポジトリのスニペットをスキップ
3. 最初にアーキテクトの立場を形成する
他の声を読む前に、以下を書き留めます：
- 初期の立場
- それを支持する3つの最強の理由
- 好ましいパスの主要なリスク
最初にこれを行うことで、合成が単に外部の声を反映するだけにならないようにします。
4. 3つの独立した声を並行して起動する
各サブエージェントは以下を受け取ります：
- 決定の質問
- 必要な場合はコンパクトなコンテキスト
- 厳格な役割
- 不必要な会話履歴なし
プロンプトの形式：
You are the [ROLE] on a four-voice decision council.
Question:
[decision question]
Context:
[only the relevant snippets or constraints]
Respond with:
1. Position — 1-2 sentences
2. Reasoning — 3 concise bullets
3. Risk — biggest risk in your recommendation
4. Surprise — one thing the other voices may miss
Be direct. No hedging. Keep it under 300 words.
役割の強調：
- 懐疑論者：フレーミングに挑戦し、仮定に疑問を呈し、最もシンプルな信頼できる代替案を提案する
- 現実主義者：速度、シンプルさ、実世界の実行を最適化する
- 批評家：下降リスク、エッジケース、計画が失敗する可能性のある理由を表面化する
5. バイアスガードレールで合成する
あなたは参加者と合成者の両方なので、これらのルールを使用します：
- 外部の見解を説明なしに却下しない
- 外部の声が推奨を変えた場合、明示的にそう述べる
- 拒否した場合でも、最強の反対意見を常に含める
- 2つの声が初期の立場に反対する場合、それを実際のシグナルとして扱う
- 判決の前に生の立場を表示したままにする
6. コンパクトな判決を提示する
この出力形式を使用します：
## Council: [short decision title]
**Architect:** [1-2 sentence position]
[1 line on why]
**Skeptic:** [1-2 sentence position]
[1 line on why]
**Pragmatist:** [1-2 sentence position]
[1 line on why]
**Critic:** [1-2 sentence position]
[1 line on why]
### Verdict
- **Consensus:** [where they align]
- **Strongest dissent:** [most important disagreement]
- **Premise check:** [did the Skeptic challenge the question itself?]
- **Recommendation:** [the synthesized path]
電話画面でスキャンできるようにします。
永続化ルール
このスキルから~/.codex/notesや他のシャドウパスにアドホックなノートを書かないでください。
カウンシルが推奨を実質的に変えた場合：
- 適切な永続的な場所にレッスンを保存するために
knowledge-opsを使用する - または結果がセッションメモリに属する場合は
/save-sessionを使用する - または決定がアクティブな実行の真実を変える場合、関連するGitHub / Linearの課題を直接更新する
決定が何か実際のものを変える場合のみ永続化します。
マルチラウンドフォローアップ
デフォルトは1ラウンドです。
ユーザーが別のラウンドを望む場合：
- 新しい質問を焦点を絞ったものに保つ
- 前の判決は必要な場合のみ含める
- アンチアンカリングの価値を保持するために懐疑論者をできるだけクリーンに保つ
アンチパターン
- コードレビューにカウンシルを使用すること
- タスクが単なる実装作業の場合にカウンシルを使用すること
- サブエージェントに会話トランスクリプト全体を渡すこと
- 最終判決で不一致を隠すこと
- 重要性に関わらずすべての決定をノートとして永続化すること
関連スキル
santa-method— 敵対的な検証knowledge-ops— 永続的な決定デルタを正しく保存するsearch-first— 必要に応じてカウンシル前に外部参照資料を収集するarchitecture-decision-records— 決定が長期的なシステムポリシーになった場合に成果を正式化する
例
質問：
Should we ship ecc 2.0 as alpha now, or hold until the control-plane UI is more complete?
カウンシルの可能性のある形：
- アーキテクトは構造的な整合性と混乱したサーフェスを避けることを主張する
- 懐疑論者はUIが実際にゲーティングファクターであるかどうかを疑問視する
- 現実主義者は信頼を損なわずに今すぐ何が出荷できるかを尋ねる
- 批評家はサポートの負担、期待の負債、ロールアウトの混乱に焦点を当てる
価値は一致にありません。価値は選択前に不一致を明確にすることにあります。