mcpField
B
boardroom

boardroom

github.com/alirezarezvaniその他28.9k425 回インストール2 日前に更新
リポジトリ

boardroom について

boardroomは、戦略ブリーフをC-suiteアドバイザーが検討するスキルです。独立した意見表明、相互の検証、反対意見の検討を経て、提言と異論を記したメモを作成し、創業者の判断に引き継ぎます。

主な機能

  1. 01アドバイザーによる個別の意見表明
  2. 02役割間の相互検証
  3. 03反対意見の検討
  4. 04異論を含むボードメモの作成
  5. 05創業者への意思決定の引き継ぎ

活用シーン

  1. 01複数の役割で戦略ブリーフを評価
  2. 02決定前に意見の相違を把握
  3. 03提言と未解決事項を記録

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/alirezarezvani/claude-skills --skill boardroom

インストール後、Claude Code で/boardroomを入力して読み込まれたか確認します。

詳細

/cs:boardroom — 複数の役割による役員会での審議

コマンド： /cs:boardroom <brief-path>

単一の戦略ブリーフを対象に、C-suite全体でboard-meetingスキルのプロトコルを実行します。これはプラグインの中核です。gstackのレビュー工程では近似することしかできない、複数の役割による審議を行います。

パイプライン内の位置

/cs:office-hours  →  /cs:brief  →  /cs:boardroom  →  /cs:decide  →  /cs:execute  →  /cs:post-mortem
                                     ↑ you are here

6つのフェーズ（board-meetingスキルより）

フェーズ1 — ブリーフィング
  • Chief of Staffが、Affected Rolesに記載されたすべてのアドバイザーにブリーフを配布します。
  • 各アドバイザーはcompany-context.mdとブリーフを読みます。
  • まだ議論は行いません。
フェーズ2 — 個別の検討（隔離）
  • **重要：**各アドバイザーは、他のアドバイザーの見解を見ずに、独立して自分の見解をまとめます。
  • これにより、集団思考を防ぎ、異論を表面化させます。
  • 各アドバイザーは、自身の視点からの冒頭意見、推奨事項、主な懸念点を3つ、主な支持理由を3つ記します。
フェーズ3 — 相互検証
  • 各自の見解を同時に公開します。
  • 各アドバイザーは、自身が担当する観点から、他のアドバイザーの見解を批評します。
    • cs-cfo-advisorは数値を批評します
    • cs-ciso-advisorはリスクを批評します
    • cs-cpo-advisorはJTBDを批評します
    • cs-cmo-advisorはポジショニングを批評します
    • cs-cro-advisorは収益の計算を批評します
    • など
フェーズ4 — 悪魔の代弁者による検討
  • executive-mentor/devils-advocateエージェントが、最有力の選択肢に対して/em:challengeを実行します。
  • 深刻度の評価を添えて、3つの懸念点を提示します。
フェーズ5 — 統合
  • Chief of Staffが、どの選択肢が多数の支持を得ているか、未解決の異論は何かをまとめます。
  • 推奨事項と異論を含む役員会メモを作成します。
フェーズ6 — 意思決定の引き継ぎ
  • メモを創業者に提示します。
  • 創業者は承認、修正、または却下します。
  • 承認されたメモは、記録のため/cs:decideに送られます。

出力：役員会メモ

~/.claude/boardroom/YYYY-MM-DD-<slug>.mdに保存されます。

# Board Memo: <topic>
**Date:** YYYY-MM-DD
**Brief:** <link to /cs:brief file>
**Status:** AWAITING FOUNDER DECISION | APPROVED | REJECTED

## Question
[One sentence from the brief]

## Recommended Option
**<Option name>** — chosen because <synthesis reasoning>

## Vote Tally
| Advisor | Vote | One-Sentence Reason |
|---|---|---|
| cs-ceo-advisor | A | <reason> |
| cs-cfo-advisor | A | <reason> |
| cs-cto-advisor | B | <reason> |
| ... | | |

## Dissent
- **<dissenter>:** <unresolved concern>

## Devil's Advocate Concerns
1. **CRITICAL** — <concern> — Mitigation: <plan>
2. **HIGH** — <concern> — Mitigation: <plan>
3. **MEDIUM** — <concern> — Mitigation: <plan>

## Success & Kill Criteria
[Copied from brief, refined by the panel]

## Recommended Decision Path
- `/cs:decide` → log the decision
- `/cs:execute` → 90-day plan
- `/cs:cross-eval` → multi-model sanity check (optional, high-stakes)
- `/cs:freeze N` → cooldown lock (optional, irreversible)

フェーズ2での隔離が重要な理由

自分の見解をまとめる前に他のアドバイザーの見解を見ると、そちらに引きずられます。フェーズ2での隔離は、board-meetingプロトコルで最も効果の高い実践です。迎合によって抑え込まれていた異論を表面化させます。

gstackのレビュー工程より優れている理由

gstack /autoplan/cs:boardroom
役割CEO → デザイン → エンジニアリング（3つ）最大10のC-suite役職
順序順次フェーズ2で隔離し、その後同時に実施
異論の記録暗黙的明示的な異論の欄
対立的な検討なしフェーズ4で悪魔の代弁者が検討
出力レビュー済みの計画異論と中止基準を含む、投票で決まったメモ

ワークフロー

  1. ~/.claude/briefs/<file>からブリーフを読み込みます
  2. 影響を受ける役割を特定します
  3. 各cs-*アドバイザーを個別に呼び出します（フェーズ2）
  4. 各自の見解を集めます
  5. 相互検証のラウンドを実施します（フェーズ3）
  6. 最有力の選択肢に対して/em:challengeを実行します（フェーズ4）
  7. メモをまとめます（フェーズ5）
  8. 創業者に引き継ぎます（フェーズ6）

振り分け

  • /cs:decide — 承認されたメモを記録します
  • /cs:cross-eval — 重要な決定に対するセカンドオピニオン
  • /cs:freeze — クールダウンロック

関連項目

バージョン： 1.0.0

コメント

Markdown 対応