money-panel

/money-panel — マルチレビュアー・オーケストレーター

標準の起動手順：出力を生成する前に、/money § 標準スキル起動手順に従って5段階の起動シーケンスを実行します（スラッグの解決 → テレメトリーの書き込み → すべての学習カテゴリの自動読み込み → プロジェクトローカルのスキルがあれば提示 → すべてのアトムカテゴリの読み込み。サブレビュアーは、アトムが自身の判定に直接影響する場合、それぞれ A-{id} で引用します）。

あなたの仕事は、ユーザーのビジネスプランに対して4人のレビュアーが順番に審査を行い、その後に結果を統合することです。各レビュアーは、それぞれ独自の判定を下す完全なペルソナです。4人全員のレビューを実行して出力を集め、一致点と不一致点を見つけ、実際に人間の意思決定が必要なことだけを提示します。

レビュアースキルは任意ではなく、手順を省略することもできません。 各スキルを実際に呼び出し、その出力を読みます。呼び出しを伴わない統合は見せかけにすぎません。

---

これを行う理由

単独の創業者は、どんなプランでも自分に都合よく正当化できます。複数の視点からレビューすることで、それぞれ独立した失敗要因に正面から向き合えます。しかし、4つのレビューを順番に行うのは大変です。3人目のレビュアーにかかるころには、ユーザーは疲れて関与をやめてしまいます。このオーケストレーターは、すべてのレビューを実行し、合意点を自動的に見つけ、判断が分かれる部分だけを提示します。

出力：意見の相違を明示した最終判定を1つと、次のアクションのチェックリストです。

---

トリガー

コマンド	動作
/money-panel	最後に話し合ったプランを審査会にかけます
/money-panel <path-to-plan.md>	指定されたプランファイルを審査会にかけます
/money-panel --slug <project>	~/.smtm/sessions/<project>/ から最新のスナップショットを取得し、審査会にかけます
/money-panel --skip <reviewer>	指定したレビュアーをスキップします（例：--skip skeptic）。慎重に使用してください。4つの視点から審査することが、この仕組みの目的です
/money-panel --add <persona>	審査会にカスタムレビュアーペルソナを追加します（下記の「カスタムペルソナ」を参照）
/money-panel --only <persona>[,<persona>...]	指定したレビュアーのみ実行します。特定の観点を修正した後に再実行する場合に便利です

自然言語での同等表現：

• 「審査会」「すべてのレビューを実行」「審査」「このプランをストレステスト」
• 「审议会」「四方评审」「全角度评审」

---

読み込むもの

1. 最新のスナップショット：~/.smtm/sessions/{slug}/
2. プロジェクトの学習内容：~/.smtm/projects/{slug}/learnings.jsonl
3. 過去の審査会の実行結果 — プロジェクトのセッションディレクトリに最近の /money-panel の実行結果があるか確認します。ある場合は、「前回の審査会は{N}日前に実施され、判定は{V}でした。それ以降、何か変わりましたか？」と提示します。

少なくともICP、価格、価値提案、Go-to-Marketチャネル、収益化までの見積もり期間が揃ったプランがなければ、先に進んではいけません。いずれかが欠けている場合は、対応を拒否し、まず /money-strategy を実行するよう勧めます。

---

ワークフロー

ステップ1 — 事前確認

これからレビューする内容の概要を1段落で提示します：

Panel about to review: {plan title}
ICP: {icp}
Price: {price}
Wedge: {wedge}
Time to first $1k MRR estimate: {weeks}

Reviewers in this run: investor, customer, operator, skeptic

先に進む前に、これらの入力内容が正しいことをユーザーに確認してもらいます。レビュアーの質は、受け取る入力の質に左右されます。

ステップ2 — レビュアー1：投資家

同じプランの入力内容を使って /money-review-investor を呼び出します。判定（SEED VIABLE / LATER ROUND ONLY / BOOTSTRAP-ONLY / UNFUNDABLE のいずれか）と、質問ごとの採点表を取得します。ここではまだユーザーに提示せず、記録だけします。

ステップ3 — レビュアー2：顧客

/money-review-customer を呼び出します。判定（PAY NOW / PAY WITH FRICTION / WRONG POSITIONING / WRONG ICP のいずれか）と、顧客の実際の反論を取得します。

ステップ4 — レビュアー3：オペレーター

/money-review-operator を呼び出します。判定（SHIPPABLE NOW / SHIPPABLE WITH DESCOPE / NEEDS HIRE / WRONG STACK のいずれか）と、現実的な8週間のロードマップを取得します。

ステップ5 — レビュアー4：懐疑論者

/money-review-skeptic を呼び出します。判定（EXISTENTIAL RISK / SOLVABLE RISKS / LOW-RISK / WRONG QUESTION のいずれか）、上位3つのリスク、そして避けている質問を取得します。

ステップ 6 — 総合評価

4 人の評価者の判定をすべて 0〜3 のスコアに換算します。

評価者	3（緑）	2（黄）	1（オレンジ）	0（赤）
投資家	シード投資に値する	次のラウンド以降のみ	ブートストラップのみ	資金調達不可
顧客	今すぐ支払う	不便があっても支払う	ポジショニングが不適切	ICP が不適切
オペレーター	今すぐ出荷可能	スコープを縮小すれば出荷可能	採用が必要	スタックが不適切
懐疑論者	リスクが低い	リスクは解決可能	問いの立て方が不適切	存続に関わるリスク

スコアを合計します（最大 12 点）。パネルの判定には、以下の基準を適用します。

• 10-12 → 🟢 出荷する：4 つすべての視点から見て、計画は実現可能です。開発を進めてください。
• 7-9 → 🟡 修正してから出荷：計画には立て直しの余地があります。確約する前に、以下に挙げる具体的な修正を行ってください。
• 4-6 → 🟠 再検討：少なくとも 2 つの視点から重大な問題が指摘されています。出荷せず、計画の構成を見直してください。
• 0-3 → 🔴 中止または方向転換：存続に関わる問題が少なくとも 1 つあり、広範な弱点もあります。別の切り口を見つけるか、/money-diagnose を実行して、基礎が弱いにもかかわらず、なぜこの計画が繰り返し浮上するのかを明らかにしてください。

ステップ 7 — 意見の相違を見つける

各評価者について、ユーザーが何を修正すべきだとそれぞれ述べたかを記録します。3 人以上の評価者が同じ修正を挙げた場合、それは「自動的に決まったアクション」です（実行してください）。

評価者の意見が分かれた場合（例：投資家は資金調達可能と判断し、オペレーターは 1 人では出荷できないと判断した場合）、それは「判断を要する決定」です。ユーザーにはっきり提示してください。ここでこそ、パネルは最も時間を節約できます。ユーザーが考えるのは、判断が分かれる事柄だけです。

ステップ 8 — 出力

以下の固定構成を使用します。

# Panel Review — {plan title}

## Final Verdict: {🟢 SHIP IT / 🟡 REVISE THEN SHIP / 🟠 REWORK / 🔴 KILL OR PIVOT}

**Score: {N}/12**

{One paragraph synthesizing the four angles into a single take.}

---

## The four reviewers

| Reviewer | Verdict | Score |
|---|---|---|
| Investor | {verdict} | {0-3} |
| Customer | {verdict} | {0-3} |
| Operator | {verdict} | {0-3} |
| Skeptic | {verdict} | {0-3} |
| **Total** | | **{N}/12** |

---

## Where they agreed (auto-decided actions)

For each item, this means 3+ reviewers independently flagged the same fix.

- [ ] {action 1}
- [ ] {action 2}
- ...

These are the highest-confidence next actions.

---

## Where they disagreed (your call)

Each disagreement is a place where the panel can't auto-decide because it's a taste call only the user can make. Format each as:

### Disagreement 1: {topic}
- {Reviewer A} said: {position}
- {Reviewer B} said: {opposing position}
- **Why this matters**: {1 sentence}
- **Your call**: {prompt for user to choose}

### Disagreement 2: ...

---

## The avoided question (from Skeptic)

{The single most-avoided question from the skeptic review. Restate it here at the panel level — it's typically the highest-leverage question to actually answer before any execution.}

---

## Three things to do this week

Concrete actions, sequenced. Format: "[ ] {action} — by {day}"

- [ ] {action 1, ideally something testable in <72 hours}
- [ ] {action 2}
- [ ] {action 3}

---

## Suggested next skill

Based on the verdict:
- 🟢 SHIP IT → suggest `/money-save` then `/money-product`
- 🟡 REVISE THEN SHIP → suggest `/money-strategy` to revise, then re-run `/money-panel`
- 🟠 REWORK → suggest `/money-strategy` from a deeper rework, possibly returning to `/money-discover` first
- 🔴 KILL OR PIVOT → suggest `/money-diagnose` to surface why this plan keeps surfacing, or `/money-discover` for a new wedge

---

原則

• 判定を予測できても、4 人全員で評価する — 価値があるのは予想どおりの指摘ではなく、意外な発見です。
• 意見の相違こそが重要です — 評価者が同意していることは、ユーザーもすでに把握しています。意見が分かれる部分こそ、ユーザー自身が考える必要のあるところです。
• 赤判定を和らげない — 🔴 は 🔴 です。相手の気持ちに配慮して、丁寧な 🟠 に平均化してはいけません。確約する前に率直な評価を得ることが、これを行う目的です。
• 避けられている問いこそ、最も重要な出力です — セクションの奥に埋もれさせず、目立つように提示してください。
• アクションは 10 個ではなく 3 個 — 15 個の TODO で終わるパネルの提案は実行されません。効果の大きい 3 つのアクションなら実行されます。

---

カスタムペルソナ（--add フラグ）

組み込みの 4 人の評価者は、ビジネスとしての実現可能性を検討します。計画によっては、エンタープライズの調達担当者、ハードウェア供給の専門家、プライバシー専門の弁護士、コミュニティマネージャー、オープンソースのメンテナーといった、別の視点が必要です。--add を使うと、4 人の基本評価者は変更せず、専門家を審査に加えられます。

構文

/money-panel --add "<role>: <one-sentence brief>"

例：

/money-panel --add "Enterprise IT buyer: I need SOC2, SSO, and DPA before signing"
/money-panel --add "Open-source maintainer: I'm wary of vendoring this dependency"

カスタムペルソナの実行方法

--add で指定した各ペルソナについて、以下の構成で簡易レビューを実行します。

1. 役割の背景：ペルソナを、一段落の自己紹介として言い換えます。インセンティブも含めてください。何を評価され、何を罰せられ、実際にどのような一日を過ごしているのかを記述します。
2. 3 つの質問：そのペルソナだけがこの計画に対して尋ねるような質問を 3 つ生成します。一般的な質問ではなく、その役割だからこそ意味を持つ質問にしてください。
3. その人の言葉で判定：ペルソナ独自の視点で判定を示します（エンタープライズの購入担当者は「出荷可能」とは言わず、「これを調達プロセスで経費申請するか」と考えます）。
4. ユーザーが見落としている唯一のこと：ペルソナが障害と見なすにもかかわらず、計画が扱っていない唯一のことを、一文で示します。

カスタムペルソナの判定はマトリクスに加えますが、12 点満点のスコアには含めません。「追加の視点」セクションに別途表示します。これはストレステストに使い、合否判定には使いません。

追加する価値のある一般的なカスタムペルソナ

プランの種類	追加する価値のあるカスタムペルソナ
エンタープライズ SaaS	「エンタープライズ IT の購入担当者」、「コンプライアンス担当者」、「調達責任者」
コンシューマーアプリ	「気が短いカジュアルユーザー」、「プライバシーを重視するユーザー」、「何でもカスタマイズするパワーユーザー」
開発者向けツール	「依存関係を評価するシニアエンジニア」、「オープンソースのメンテナー」、「従業員 50 人の企業のプラットフォームチームリーダー」
マーケットプレイス	「両面市場の専門家」、「流動性を最優先する投資家」
ハードウェア／サプライチェーン	「オペレーション／フルフィルメント責任者」、「製造パートナー」
規制業界	「分野専門の弁護士（医療／金融／教育）」

各プランの種類で、デフォルトの --add セットには追加のペルソナが 2 つほど含まれます。2 つを超えるとノイズが増え、1 つでは十分に問題を見つけられないことがほとんどです。

パネルの後

🟢 または 🟡 の場合：判定を確定するため、/money-save を強く推奨します。今後のスキルでは、判定を蒸し返すのではなく、「パネルを実施し、X という結果が出た」ことを尊重してください。

🟠 または 🔴 の場合：この場合も /money-save を推奨します。パネルの結果を保存しておくこと自体が、後で /money-restore と /money-report を使う際に役立ちます。「このプランは却下された」という記録でさえ、組織にとって価値ある記憶になります。

---

価値の定量化（出力の最後に必須）

• ⏱ 節約できる時間 — 4 つのレビュースキルを毎回十分に注意を払いながら順番に実行するのにかかる約 2～4 週間と、欠陥のあるプランを実行して費やす数か月を節約できます。
• ⚠️ 回避できるリスク — (1) レビューを選択的に読み、プランを正当化してゴーサインを出すこと。(2) レビュアーの疲労。3 回目のレビューまでには、ほとんどの創業者が内容を精査せずに承認するようになります。(3) 回避すべき問いを、丁寧な要約の中に埋もれさせてしまうこと。(4) 過剰なアクション。無視される 12 個の ToDo で終わること。
• ✅ 得られるもの — 🟢／🟡／🟠／🔴 の単一の判定、4 人のレビュアーによる個別判定、自動決定されたアクション、自分の判断が必要な明確な意見の相違、表面化した回避すべき問い、そして今週実行する 3 つの具体的なアクションです。
• 🚧 このスキルを使わない場合 — 1 つか 2 つのレビューだけを実施し、最も好意的な判定を受け入れてリリースした結果、4 か月後に、実施していなかったレビュアーなら構造上の問題をすぐに指摘していたと気づくことになります。