handshake (提案生成) 是做什麼的？
計劃是為創辦人準備的。提案則是為一個人、一個「是」而寫的。這項技能從實際已知的事實出發，讓創辦人無需為一個無法證實的數字辯護，即可直接寄出。
使用者在 /handshake 後輸入的內容：$ARGUMENTS
先閱讀 ${CLAUDE_SKILL_DIR}/../receipts/rules.md。帳本工具：
python3 "${CLAUDE_SKILL_DIR}/../receipts/ledger.py" <gate | scan | summary>
以下，LEDGER 即指上述指令。
步驟 1：對象是誰，以及什麼「是」
若未指定，請詢問對象是誰以及創辦人希望得到的「是」。指明接收者：顧客、資助者、投資者、貸款機構、企業內部人員、或是產品的使用者。閱讀 ${CLAUDE_SKILL_DIR}/receivers.md 以了解該類接收者需要看到什麼。
如果對方提供了文件（如 RFP、徵求提案、電子郵件、職缺公告），請先閱讀，從中提取他們明確提出的要求，並儲存為 founder/opportunities/<name>.md（格式：${CLAUDE_SKILL_DIR}/../first-dollar/opportunity.md）。
將要求壓縮到最小、最實際的「是」（規則 7）。如果創辦人想向陌生人索取一筆大額預付款，請明確指出：一個基於對方自身數據、有時限的試用計畫，更有可能獲得同意；並同時提供兩種選項。
步驟 2：資料夾能支撐什麼
LEDGER check
LEDGER gate --audience <public | anonymised | permission>
根據提案的傳播方式選擇聽眾：public 用於可能被轉發的內容、anonymised 用於私密寄送、permission 僅在 founder/evidence/people.md 中每個 ASK FIRST 宣稱者都已同意時使用。
僅根據 gate 輸出的內容來建構提案。如果接收者需要的資料是資料夾無法支援的，請不要迴避：在輸出結尾的 Gaps（差距）段落下列出，並說明如何取得（/receipts 的任務 4 會深入處理）。切勿用猜測、引用面板意見或董事會觀點來填補差距。
如果關於需求的任何內容都未被 MEASURED（測量），提案應誠實地透過措辭表達：「我們正在尋找三家公司進行試用」，而不是「公司已排隊等候」。
步驟 3：撰寫
- 一句話版本、三句話版本、三分鐘大綱。
- 接收者所需的格式（來自
receivers.md）。如果對方提供了徵求提案或通話內容，請使用他們自己的標題來回答。遵守他們的限制（對 NSF 的章節計算字元數並標明）。 - 在工作草稿中，每個事實都引用其宣稱 ID，例如
[c04]。將PLANNED（計畫中）的宣稱寫為目標（「我們預期」、「試用將測試」），絕不能寫成結果。 - 一個簡短的可能出錯的地方（What could go wrong）區段，使用平實的語言。接收者信任這一點。
- Gaps（差距）：為了讓這份提案更強而有力所需要的內容，以及每項差距最便宜的取得方式。
將成果儲存為 founder/outputs/<YYYY-MM-DD>-<receiver>.md。
步驟 4：寄出前檢查
LEDGER scan founder/outputs/<file>.md --audience <the same audience>
scan 會拒絕任何接收者無法看到的引用宣稱（如 SIMULATED 或 PRIVATE 宣稱、未獲許可的 ASK FIRST），並標記那些沒有真實買家付款或簽約的證詞（「驗證過」、「已證明」、「強勁需求」）。修正它列出的每個問題，並重新執行直到完全乾淨。然後，如果創辦人需要，可以製作一份不含 [c..] ID 的可寄送副本，同時保留引用版本的草稿。
規則
- 絕對不引用、計算或描述虛擬買家、董事會成員或模型輸出為真實顧客、使用者、顧問或市場研究。
- 不得有虛構的顧問、合作夥伴、標誌、客戶名稱或數字。「會計領域的顧問」需要在
people.md中有真實顧問的姓名，並已同意被列出。 - 沒有來源的市場規模不可引用；否則應寫為附帶方法的估計值。
- 寄送是創辦人的責任。草擬電子郵件或訊息，但不要實際寄出。
輸出
founder/outputs/<日期>-<接收者>.md（若需可另附乾淨副本），以及若有徵求提案或通話則有 founder/opportunities/<名稱>.md。結尾應包含一句話摘要、差距清單，以及下一步行動：本週應寄送給誰、以及對方回覆時應使用 /receipts 記錄什麼。