kill-or-build（事業判断・計画書作成） は何をしますか？
最後のステップ。起業家が行動に移せる、パックが見つけた事実だけに基づいた、どの部分が現実かを正直に示す一つの文書。
最初に ${CLAUDE_SKILL_DIR}/../receipts/rules.md を読んでください。
このフォルダにあるツール：
python3 "${CLAUDE_SKILL_DIR}/compile.py" --dir founder
ステップ1：現状を確認する
python3 "${CLAUDE_SKILL_DIR}/compile.py" --dir founder --check
評決と各チェック結果を出力します。チェックはすべて自動計算されます：
- 各ユニットが固定費前に利益を生み出しているか（
founder/numbers.json）。 - 1年目に営業利益が出ているか。
- 損益分岐点が、もし容量が指定されていればその範囲内に収まっているか。
- 十分な数のシミュレーション購入者が購入しているか（
founder/panel/results.json。デフォルトの基準は25%、--min-buy-rateで変更可能。その理由も説明すること）。低いパネル結果は計画を失敗させますが、高いパネル結果は何も証明しません。 - 実際の需要：
founder/evidence/claims.csvに少なくとも1件のMEASURED（測定済み）需要クレーム（支払い、デポジット、署名済みパイロット、予約）があること。
評決の一覧：
| 評決 | 意味 |
|---|---|
| Incomplete（未完成） | まだ数字がない場合：/burn-test を提案 |
| Not yet（未達） | チェックのいずれかが失敗。各失敗が番号付きで表示される |
| Unproven（未検証） | 理論上の計算は成立するが、実際の購入者の確約がない |
| Profitable（収益性あり） | 計算が成立し、少なくとも1人の実際の購入者が確約した |
エビデンスセクションを最新にするため、最初に ledger.py summary を実行してください：
python3 "${CLAUDE_SKILL_DIR}/../receipts/ledger.py" summary
数字がない場合、評決は Incomplete になります：/burn-test を実行するよう提案してください。不足している他のセクションは、それを埋めるスキルと共に一覧表示してください。推測で不足セクションを自分で埋めてはいけません。
ステップ2：サマリー
founder/summary.md を書きます。半ページ、平易な言葉で、最初に The hard truth（厳しい真実）： このビジネスが失敗する最も可能性の高い理由を述べます。
- 事業内容と対象顧客を2文で。
- 評決と、その背後にある3つの数字（マージン、損益分岐点、1年目）。
- 現実のもの：
MEASUREDおよびTHEY SAID ITクレームの数とその内容。次に、まだ推測の段階のもの。 - シミュレーションパネルとボードが合意した点と、意見が分かれた点（シミュレーションであると明記）。
- 最大のリスクとそれに対して行う対策。
- 創業者が始めるために必要なもの（CFOからの資金、ローンチからの最初のテスト）。
- 今週やるべきこと。
評決が Not yet の場合、サマリーは何を変える必要があるか、どのスキルでそれを変えるかを最初に述べます。Unproven の場合、今月中に事業を証明または破綻させる現実世界のテストを一つ、最初に述べます。失敗しているチェックを和らげてはいけません。また、未検証の計画を検証済みであるかのように書いてはいけません。
ステップ3：編集
python3 "${CLAUDE_SKILL_DIR}/compile.py" --dir founder
founder/business-plan.md を書き出します：タイトル、評決とそのチェック結果、主要な数字の表、アイデア、続いてパックが生成した各セクション（サマリー、ボード、競合、パネル、価格、オファー、数字、マーケティング、ブランド、オペレーション、ローンチ）、そしてまだ完了していないこと。
ステップ4：ワンページ
創業者と近しいパートナー向けに founder/one-pager.md を書きます：問題、顧客、オファーと価格、数字の表、実際のエビデンス（パネルはシミュレーションであると明記）、資金の使途、そして依頼内容。計画書と同じ数字を、一字一句同じで記述します。
外部の人（顧客、資金提供者、融資担当者）には、計画書やこのページを送ってはいけません：代わりに /handshake を実行してください。これはその相手が見ても良いクレームのみから構築され、結果をチェックします。
ルール
- 評決は
compile.pyから取得します。手動で Profitable と書いてはいけません。失敗している数字を切り上げて成功に見せてはいけません。Unproven を「もう少し」と呼んではいけません。 - 一度、明確に述べてください：パネルとボードはシミュレーションであり、数字は予測です。実際の顧客と実際の見積もりだけがそれらを確認します。財務、法律、税務のアドバイスではありません。
- ユーザーがPDFやデッキを希望する場合、計画のエクスポートを提案しますが、マークダウンを真実の源泉として維持してください。
出力
founder/summary.md、founder/business-plan.md、founder/one-pager.md。その後、ユーザーに評決を一行で、ハードトゥルース、そして今週やるべき現実世界のアクションを一つ伝えます。次に：承認を得る必要がある受け手向けに /handshake。