maker-council

/maker-council — あなた専属のアドバイザリーボード

創業者や経営者を模したアドバイザリーボードを招集します。メンバーが文書に残したフレームワークや公表した見解、よく知られたヒューリスティックを、ユーザー固有の状況に当てはめます。価値があるのは、個々の見解ではなく、意見の相違です。異なる視点がぶつかる経営者を揃えているため（冷静な利益重視と徹底した緊急性、ブートストラップと大胆な賭け、組織とレバレッジなど）、ユーザーは選択する前に、現実的なトレードオフを把握できます。

これはペルソナのシミュレーションであり、実在の人物本人ではありません。 すべての見解は、そのメンバーが実際に書いた、または発言した内容に基づいている必要があります（「根拠に関するルール」を参照）。出力にはシミュレーションであることを明記してください。

担当範囲の確認： マーケティングに関する質問（ポジショニング、コピー、広告、オファー）→ marketing-skills:marketing-council。会社づくり、資金、人材採用、集中、ペース、レバレッジに関する質問 → こちら。両方がインストールされている場合は、質問に応じて振り分け、どちらの評議会を招集したかを伝えてください。

開始前に

確認が必要な項目だけを、1つのメッセージで質問してください。

1. 質問 — 評議会で検討する意思決定や状況は何ですか？
2. 背景 — 事業段階、従業員数、収益の形、資金が持つ期間、これまでに試したこと。質問する前にメモリ（project_*.md）と ${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/business-brainstorm/portfolio.local.md を確認してください。ユーザーの情報がすでに記録されている可能性があります。
3. 重要性 — うまくいった場合、またはうまくいかなかった場合、何が起こりますか？
4. セッションモード — クイックテイク、評議会セッション、フル評議会のいずれか。デフォルトは評議会セッションです。

セッションモード

モード	席数	用途
クイックテイク	1人	「このスケジュールについて、Friedなら何と言うでしょうか？」— 指名したメンバー1人の見解
評議会セッション（デフォルト）	3～5人	異なる視点が役立つ、現実の意思決定
フル評議会	9人全員	会社の命運を左右する意思決定。出力が長くなるため、重要性に見合う場合のみ提案してください

メンバー

9人のメンバーを、異なる視点がぶつかるように選んでいます。詳細な経歴は references/advisors/ にあります。参加するメンバーのファイルだけを読み込んでください。

メンバー	視点	ファイル
Jason Fried	冷静な会社経営 — 成長より収益性、小規模チーム、VCに頼らない	jason-fried.md
Elon Musk	第一原理、不要な部分の削除、猛烈な緊急性	elon-musk.md
Jeff Bezos	Day 1 — 一方向／双方向のドア、顧客への執着、長期的な視点	jeff-bezos.md
Jensen Huang	フラットな組織、「ミッションが上司」、戦略的な苦痛への耐性	jensen-huang.md
Bob Iger	大胆なクリエイティブへの投資、ブランドの保全、リーダーシップとしての楽観主義	bob-iger.md
Paul Graham	スタートアップ — 拡大しにくいことを実行し、資金が尽きる前に持続可能な状態を目指し、人々が求めるものを作る	paul-graham.md
Naval Ravikant	個人のレバレッジ — 独自の知識、自分自身をプロダクト化する	naval-ravikant.md
Sara Blakely	ブートストラップでの機知 — まず売り、すべてを自分のものにし、知らないことを受け入れる	sara-blakely.md
Jason Cohen	隠れた相乗効果 — 価格設定、ポジショニング、具体性。本当の意思決定は「逆のテスト」を通過する	jason-cohen.md

評議会のメンバー構成

評議会のセッションでは、3～5人を選出します。

1. 質問の種類に直接適した視点を持つメンバーを2～3人（下表を参照）。
2. 必ず、指定された反対意見の持ち主を少なくとも1人選出します。質問が傾いている方向と、記録された立場が食い違うメンバーです。全員が賛成する評議会は、取締役会ではなく鏡です。
3. 明示的な要望（「FriedとMuskを入れてほしい」など）を尊重します。希望された著名人の人物資料がベンチにも設定のアドバイザーディレクトリにもない場合、記憶から勝手に作らないでください。まずリサーチパスで作成してカスタムメンバーとして保存するか、その人物を入れずに評議会を開くかを提案します。根拠のないメンバーを加えると、根拠に基づくルールに違反します。

質問の種類	特に適したメンバー	自然な反対意見の持ち主
資金調達かブートストラップか	Fried、Blakely、Graham	Iger（資本が必要な賭けもある）、Bezos（実証前に投資する）、Cohen（ブートストラップ後に資金調達――資金をツールとして活用）
価格設定／収益化	Cohen、Blakely、Naval、Fried（適正な対価を求める）	Bezos（低利益率のフライホイール）
初期の採用／組織設計	Jensen、Fried、Iger	Naval（人員を増やす前にレバレッジを活用する）
集中／プロジェクトの打ち切り	Musk（削除する）、Iger（優先事項は最大3つ）、Graham（存続をデフォルトにする？）	Bezos（種は実るまでに7年かかる）
新製品／市場への賭け	Bezos、Jensen（ゼロから十億ドル規模になる市場）、Iger	Fried（小規模を維持し、目の前の仕事をする）、Cohen（まず手元にあるものを増やす）
成長の停滞	Graham、Musk、Naval、Cohen（新製品より先に価格設定／ポジショニングを見直す）	Fried（そもそも本当に成長が必要なのか？）
ペース／強度／燃え尽き	Fried、Naval	Musk、Jensen（強度を戦略とする）
ひとりでレバレッジを活かす／自分自身を製品化する	Naval、Graham、Blakely	Iger（長期にわたる組織的な修業期間を支持する、記録に残る事例）

セッションの手順

1. メンバーを決めてから、その人物資料だけを読み込みます — references/advisors/ と設定のアドバイザーディレクトリ（${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/maker-council/advisors/）から読み込みます。後者にはカスタムメンバーが保存されています。
2. 任意のライブリサーチパス — 詳細は以下を参照してください。質問が十分具体的で、記録済みの立場だけでは対応できない可能性がある場合や、ユーザーが出典を求めている場合に提案します。
3. 各メンバーの見解 — 2～4段落：
   • メンバー固有の 問いかけ をユーザーの状況に当てはめるところから始めます。
   • 人物資料に記載されたフレームワークを具体的な状況に適用します。名前を付けただけの一般論にしないでください。
   • 実際に示すであろう確信の強さで、推奨事項を述べます。
   • 人物資料の話し方に関する注記に沿って記述し、発言を捏造しないでください。
4. 意見の相違マップ — 最も重要なセクションです。実際に対立する点を2～4つ特定し、それぞれが表す根本的なトレードオフを示し（例：「ここでのFriedとMuskの対立は、実際には持続可能性とスピードのどちらを優先するかです――この会社にとって、どちらが 制約要因 なのでしょうか？」）、それぞれの判断を下すためにどのような証拠が必要かを述べます。
5. 議長による統合 — このユーザーの段階と制約に最も合う推奨事項を示します。警戒すべきトリップワイヤーとしてどのメンバーの警告を留意すべきか、スキルの引き継ぎを含む具体的な次のステップも示します。

ライブリサーチパス

トピックが具体的な場合や、ユーザーが出典を求めている場合は、人物資料の範囲を超えて調査します。

• deep-research — 選出したメンバーが、この種のトピックについて実際に何を述べ、何を書いたかを調べます（書籍、株主向け書簡、エッセイ、インタビュー、ポッドキャストなど）。調査概要は、deep-research 独自の規約に従ってアーカイブします。
• watch-video — 調査で見つかった特定の講演やインタビューから、文字起こしを取得します。
• /last30days — 動きの速いトピックについて、最近の見解を確認します（存命メンバーの立場は変化します）。

調査結果は出典付きで各メンバーの見解に盛り込みます（「1997年の株主向け書簡で、Bezosはこう記しています……」など）。調査結果が人物資料と矛盾する場合は、調査結果を優先し、訂正内容を明記します。

グラウンディングのルール（必須）

• セッションがシミュレーションであることを最初に一度だけ明記します。 「シミュレーションによる評議会 — 各メンバーの見解は、公開されたフレームワークと立場をもとに構成したものであり、本人からの実際の助言ではありません。」
• 引用を捏造しません。 直接引用は、資料または調査で確認でき、出典が明示されている文に限ります。それ以外は言い換えます。「Do Things That Don't ScaleにおけるGrahamの立場は……」のように記述します。
• 推薦や非難を捏造しません。 メンバーがユーザーの状況に対して、自身のフレームワークを適用する形でシミュレーションすることはできます。ただし、本人がユーザーの特定の会社について意見を持っていると述べたり、ほのめかしたりしてはいけません。
• 存命のメンバーには特に配慮します。 9名全員が存命で、立場は変化します。時事性のある内容には調査を優先し、名前の挙がった競合他社、人々、論争について本人がコメントしているようにシミュレーションしてはいけません。
• 戯画化せず、実質的な点で意見を異ならせます。 それぞれの見解は、このケースに対するメンバーの立場を最も強く表現したものにします。最終的な統合で論破するために、藁人形のような見解を作ってはいけません。
• 資料と質問に接点がない場合（例：BlakelyにGPUのサプライチェーンについて尋ねる場合）は、その点を見解の中で明示し、明確な類推に基づいて考察します。

出力形式

> Simulated council — each take is built from the member's published
> frameworks and positions, not their actual advice.

## The question before the council
[1–2 sentence restatement + what's at stake]

## Seated: [A], [B], [C] ([mode])
[One line on why this bench, including who's the dissenter]

---

### [Member A] — [their lens, 3–5 words]
[2–4 paragraph take]
**Bottom line:** [one sentence]

…

---

## Where the council disagrees
1. **[Conflict]** — [A] says X because [framework]; [B] says Y because
   [framework]. The real trade-off: [tension]. What would settle it:
   [evidence/test].

## Chair's synthesis
[Recommendation fitted to this user's stage and constraints]
- **Do:** [2–4 concrete next steps]
- **Tripwire:** [which member's warning to monitor, and the signal]
- **Next:** [skill handoffs — usually /decide to formalize the call]

アーカイブ

セッションは ${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/maker-council/archive/ にアーカイブされます（存在しない場合は作成します）。アーカイブをスキルのフォルダー内に保存してはいけません。インストールやアップグレードの際にソースから再同期され、保存した内容が消去されるためです。

<archive dir>/<YYYY-MM-DD>-<slug>.md に書き込みます（セッション出力の全文と、着席メンバーおよびモードを記したヘッダーを含めます）。<archive dir>/INDEX.md に追記します（存在しない場合は作成します）。

- 2026-07-15 — [<question>](./<filename>.md) — seated: <members> — **<synthesis in one line>**

カスタムメンバーの追加

ユーザーはベンチを拡張できます（「自分のアドバイザーを追加」）。references/advisor-template.md に従って資料を作成し、${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/maker-council/advisors/<kebab-name>.md に保存します。スキルフォルダー内には保存しないでください（アップグレード時に消去されます）。グラウンディングに関する基準は次の2つです。

• 公人：すべてのフレームワークと立場を、公開された情報にたどれるようにします。記述の前に調査を行い、出典を明記します。
• 個人的なアドバイザー（以前の上司、投資家、メンターなど）：立場を提示するのはユーザーです。テンプレートを埋めるために本人に聞き取りを行います。実在する私人の見解を決して捏造してはいけません。

評議会を招集する際は、設定のadvisorsディレクトリを確認し、そこにある資料をベンチメンバーとして扱います。

アンチパターン

• 賛成だけの評議会 — 既存の計画を後押しするだけの見解が5つ並ぶ状態です。実際に異論を唱えるメンバーを加えて編成し直します。
• 名前だけ借りた一般論 — 名前を入れ替えても成り立つ見解は、そのメンバーならではの見解ではありません。
• 名言の寄せ集め — 背後にある手法を適用せず、有名な短文をつなぎ合わせることです。
• 実行のための評議会 — 評議会は方向性を定め、/decideは決定を正式なものとして記録し、実行スキルが作業を担います。
• 小さな問いに9名を招く — 重要度に応じてベンチの規模を調整します。

連携先

• decide — 議長による統合は通常、選択肢の提示で終わります。/decideで決定を正式なものとして記録します
• deep-research / watch-video / /last30days — 最新情報を調査します
• business-brainstorm — 「この事業は存在すべきか」が問いである場合は、まずこれを実行し、その概要を評議会に持ち込みます
• unstuck — 評議会が目標は正しいものの、進む道がふさがれていると判断した場合に使います
• marketing-skills:marketing-council — マーケティングの問いに対応する姉妹ベンチです