盈虧判定（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）。 - 第一年產生營業利潤。
- 若有提供產能資料，損益兩平點須在產能範圍內。
- 有足夠的模擬買方購買（
founder/panel/results.json；預設比例為 25%，可使用--min-buy-rate變更並說明原因）。低的座談小組轉換率會使計畫失敗；高的轉換率則無法證明任何事情。 - 實際需求：在
founder/evidence/claims.csv中至少有一項MEASURED的需求聲明（付款、訂金、已簽約試行、預訂）。
裁決結果：
| 裁決 | 含義 |
|---|---|
| 不完整 | 尚無數字：請提供 /burn-test |
| 尚未成功 | 某項檢查失敗；會列出失敗的項目編號 |
| 未經驗證 | 紙上計算可行，但尚無真實買方承諾 |
| 獲利 | 計算可行，且至少有一位真實買方承諾 |
請先執行 ledger.py summary，以便證據區塊為最新狀態：
python3 "${CLAUDE_SKILL_DIR}/../receipts/ledger.py" summary
如果沒有數字，裁決結果為「不完整」：提議執行 /burn-test。
列出其他遺漏的部分，以及能填補該部分的技能。請勿憑猜測自行填補遺漏的部分。
步驟 2：摘要
撰寫 founder/summary.md，長度約半頁，使用平實的文字，開頭必寫「殘酷的事實：」——這是此計畫最可能失敗的單一原因。
- 用兩句話說明這項事業是什麼以及目標客戶是誰。
- 裁決結果及其背後的三個數字（利潤率、損益兩平點、第一年狀況）。
- 什麼是真實的：
MEASURED和THEY SAID IT聲明的數量，以及其內容。接著說明哪些部分仍屬猜測。 - 模擬座談小組與評審團達成共識及意見分歧之處，並明確標示為模擬結果。
- 最大的風險以及相應的應對措施。
- 創辦人需要開始行動的事項（財務長提供的現金、上市計畫中的首次測試）。
- 本週需要做的一件事。
如果裁決結果為「尚未成功」，摘要需以必須改變的事項以及可實施該改變的技能為開頭。如果為「未經驗證」，則需以本月能夠驗證或終結此計畫的唯一真實世界測試為開頭。切勿弱化任何失敗的檢查項目，也切勿將「未經驗證」的計畫撰寫得像是已通過驗證一般。
步驟 3：編譯
python3 "${CLAUDE_SKILL_DIR}/compile.py" --dir founder
此指令會寫出 founder/business-plan.md：標題、裁決結果及其檢查項目、關鍵數字表格、商業構想，然後是套件產出的每個章節（摘要、評審團、競爭者、座談小組、定價、提案、數字、行銷、品牌、營運、上市），以及尚未完成的部分。
步驟 4：一頁式摘要
為創辦人及其緊密合作夥伴撰寫 founder/one-pager.md：問題、客戶、提案與價格、數字表格、真實證據（以及標示為模擬的座談小組結果）、資金用途，以及請求事項。數字必須與計畫書一模一樣。
對於外部人士（客戶、投資者、貸款機構），請勿寄送計畫書或此頁面：請執行 /handshake，它僅會根據該對象可以看到的聲明來建構內容，並檢查結果。
規則
- 裁決結果來自
compile.py。切勿手寫「獲利」，切勿將失敗的數字四捨五入成通過的數字，也切勿稱「未經驗證」為「快成功了」。 - 清楚說明一次：座談小組和評審團皆為模擬結果，數字均為預測值；唯有真實客戶和真實報價才能加以確認。此非財務、法律或稅務建議。
- 如果使用者想要 PDF 或簡報，請提供匯出計畫書的選項，但應以 Markdown 作為唯一真實來源。
輸出
founder/summary.md、founder/business-plan.md、founder/one-pager.md。接著以一行告知使用者裁決結果、殘酷的事實，以及本週在真實世界中需要做的一件事。下一步：為需要說「好」的接收者執行 /handshake。