decision-council

name	decision-council
description	重要な意思決定を、複数の役割エージェントを並列起動して多角検証する skill。Devil's Advocate を必須枠として、時間軸・立場軸・論理軸・価値軸の 4 カテゴリから固定役を常駐させる。決定の「逆戻り可能性」に応じて 3 役 / 5 役 / 7 役を自動選択し、テーマに応じてアドホック役 (Maintainer / Adversary / Historian など) を追加する。Use when: (1) アーキテクチャ・技術選定など中長期に効く判断、(2) 撤退・廃止・大規模リファクタなど後戻りコストが高い判断、(3) 採用・組織変更・体制変更など人に関わる判断、(4) 「これでいいのか自信がない」と感じる根幹判断。普段の小さな判断には使わない。

Decision Council

重要な意思決定を、性質の異なる複数の役割エージェントに並列で意見を出させ、それを統合してユーザーに提示する skill。

このスキルが解く課題

中長期に効く重要な判断は、自分一人で考えると以下のバイアスに引っかかる:

• 時間割引: 短期コスト・短期メリットを過大評価し、長期影響を軽視する
• フレーミング固着: 自分の立場・自分が見えている範囲でしか考えない
• 集団思考: 周囲が賛成だと反対意見が出てこない（Devil's Advocate 不在）
• 動機曖昧: 何を最大化すべきか曖昧なまま決断する

このスキルは、各バイアスに対応する 役割エージェントを並列起動 することで、「考慮し忘れた観点」を構造的に潰す。

設計原則: 4 カテゴリ + Devil's Advocate

役を「観点」ではなく 「何のバイアスを防ぐか」 で配置する。

カテゴリ	防ぐバイアス	常駐役 (固定)
🕰 時間軸	時間割引	Future Self (1〜5 年後の自分)
👥 立場軸	フレーミング固着	End User (実際に影響を受ける人)
🧠 論理軸	論証の弱さ	Steel-Manner (反対意見の最強版を構築)
⚖ 価値軸	動機曖昧	Pragmatist (実装現実・運用負荷)
🔥 (独立)	集団思考	Devil's Advocate (必須・全否定役)

役は固定。「カテゴリから選ぶ」ではなく「カテゴリには決まった役がいる」設計。役を毎回選ばせると、その選定にスキル本体の判断力が割かれ、本来の議論が薄くなる。

重み判定: 3/5/7 役の自動選択

決定の 逆戻り可能性 (Bezos の two-way doors) で重みを決める:

重み	役数	どんな決定	起動する役
軽	3 役	数日で取り消せる、影響範囲が局所	DA + Future Self + Pragmatist
標	5 役	取り消しに数週間〜数ヶ月、複数人に影響	DA + 4 カテゴリ全員
重	7 役	実質取り消し不能、年単位の影響、人や組織が動く	5 役 + Pre-mortem + Strategist

判定基準の詳細は references/decision-mechanics.md を参照。

アドホック役: ハイブリッド方式

決定のテーマに応じて、常駐役に アドホック役を 0〜3 個追加 する。

• 既知パターン (テーブル): 技術選定 → Maintainer、セキュリティ → Adversary など、既に経験則のあるテーマは表で対応
• 未知パターン (LLM 生成): テーブルに該当しないテーマは「このテーマで見落としやすい観点は何か」を考えて役を 1〜3 個生成

マッピング表の詳細は references/decision-mechanics.md を参照。

ワークフロー

Step 1: 決定の明確化

ユーザーから決定したい内容を聞き、1〜2 文で言語化 する。曖昧な相談（「アーキテクチャをどうしようか」）は、具体的な選択肢に絞り込む（「モノリス継続 vs マイクロサービス分割」）まで深掘りする。

選択肢が出揃わないうちに役を起動すると、各役が違うものを評価して議論が空中分解する。

Step 2: 重みとアドホック役の決定

references/decision-mechanics.md の判定基準に従い:

1. 逆戻り可能性から 3/5/7 を判定
2. テーマから アドホック役 0〜3 個 を選定 (テーブル → LLM フォールバック)

ユーザーに「N 役で進めます。アドホックは X, Y を追加します」と提示して合意を取る。

Step 3: Round 1 — 並列独立議論

各役を 同一メッセージ内で並列起動 する (Agent tool を複数同時呼び出し)。各役は他の役の意見を見ない。

各役へのプロンプトは references/role-definitions.md のテンプレートに沿って組み立てる。プロンプトには必ず以下を含める:

• 決定したい内容 (Step 1 で言語化したもの)
• 選択肢
• 役の責務 (テンプレート参照)
• 出力形式 (要点 3〜5 個 + 推奨 + 懸念)

Step 4: Round 2 — 反論・補強

Round 1 の全意見をマージしてユーザーに提示した後、Devil's Advocate と Steel-Manner のみ Round 2 を起動 する。

• Devil's Advocate: Round 1 の意見全体を読んで「この議論で見落としているリスク」を再指摘
• Steel-Manner: Round 1 で支持が薄かった選択肢を最強化して再提示

Round 2 を全員でやると意見が収束しすぎる (集団思考が再発する)。批判役 2 人だけにすることで反対視点を保つ。

Step 5: 統合と推奨提示

Claude (skill 実行者) が司会として:

1. 各役の主張を 1〜2 行に要約
2. 意見が割れている論点 を明示 (合意点はサラッと触れる)
3. トレードオフ表を作る (選択肢 × 各役の評価)
4. 推奨 を 1 つ提示し、根拠を述べる
5. 「この決定で死ぬ条件 (= 撤退条件)」を 1〜2 個提示

推奨は出すが、最終決定はユーザーがする。司会として誘導しない。

Step 6: 出力

出力フォーマットは プロジェクト規約に従う:

• docs/decisions/ に ADR がある → ADR フォーマットで docs/decisions/NNNN-*.md を提案
• decisions/ adrs/ 等のディレクトリがある → そのフォーマットに合わせる
• それらがない → プレーンテキストで本文に提示するだけ (ファイル化しない)

ファイル化を希望されない限り、ユーザーが読んで判断できる形で本文に出すのがデフォルト。

アンチパターン

このスキルが避けるべき失敗:

• 選択肢が曖昧なまま役を起動: Step 1 を省略すると各役が違う前提で論じ、議論が噛み合わない
• Round 1 で役同士が会話する: Round 1 は独立並列が原則。会話させると最初に発言した役の意見に引っ張られる
• Round 2 を全員でやる: 集団思考が再発する。批判役 (DA / Steel-Manner) のみで良い
• Claude が答えを誘導する: 司会は中立。推奨は出すが、各役の主張を不当に削らない
• 「全員が賛成」で終わらせる: DA が反対していなかったら、DA のプロンプトが弱い。やり直す
• 小さな決定にも使う: 役起動コスト (時間・トークン) が高い。逆戻り可能な軽い判断には使わない
• 撤退条件を出さない: Step 5 の「死ぬ条件」を省略しない。これが将来の見直し基準になる
• 出力フォーマットを skill 側で固定: ADR があるリポジトリと無いリポジトリで使い分けないと浮く

連携するスキル

• repo-kickoff: ADR を整備済みのリポジトリで使うと、出力先が明確で連携しやすい
• claude-code-rules: 「重要な決定はこの skill を使う」というルールを .claude/rules/ に書くと、適切なタイミングで呼び出される