mirandaplayer1 開案（Kickoff）
目的：規格初稿不該讓使用者面對空白模板憑空填寫，而是從一段腦力激盪對話中蒸餾出來。使用者只需要帶一個粗略想法來；工作流骨架（檔案模板）缺件時由本 skill 順手建好。
門檻：SPEC.md 初稿未經使用者核可前，不進入任何實作。專案再簡單都要走這個流程——簡單專案的規格可以短到幾句話，但不能跳過。「太簡單不用規格」的專案，正是未經檢驗的假設造成最多重工的地方。
步驟
- 骨架檢查與建立：列出專案資料夾內容，確認骨架（
WORKFLOW.md、SPEC.md、DECISIONS.md、notes/）是否就位。齊全就直接進第 1 步；缺件時把本 skillassets/底下全部內容複製到專案根目錄（維持相對路徑），規則——- 永不覆蓋既有檔案：已有同名檔逐一詢問，預設跳過；使用者的東西比模板重要。
- 已有
CLAUDE.md→ 不覆蓋、不合併內容，只在檔案末尾追加一行@WORKFLOW.md（已有這行就不動），追加前告知使用者。 - 忠實複製：不要「順手改良」assets 裡的模板；模板的演進走各專案
/reflect的回饋，再由使用者手動更新到本 skill 的 assets。 - 建完列出檔案樹驗證（
CLAUDE.md內含@WORKFLOW.md），然後直接續跑第 1 步——skill 全部住在使用者層，專案裡不放副本。 - 使用者只要求建骨架、還不想談內容時，到此為止即可，並提示之後說「我想做○○○」再繼續。
- 聽起點：請使用者用幾句話說他想做什麼、為什麼現在做、心中有沒有隱約的想像或參考對象。不追問細節，先拿到原始材料。
- 探索：讀專案資料夾既有素材（舊成品、資料、筆記），必要時搜尋網路了解領域慣例與同類作品。
- 範圍評估：提問之前先判斷——這個想法是一個專案，還是好幾個獨立子專案（例如「教材＋行銷網頁＋報名系統」）？若是後者，先協助拆解：有哪些獨立部分、彼此關係、建議的先後順序，然後只對第一個子專案往下走。不要浪費問題在一個本來就該拆掉的專案的細節上。
- 腦力激盪方向：提出三到五種做法，從最小可行到最有野心排列，各附一句「什麼條件下該選這個」。把建議選項放在最前面並說明理由，讓使用者可以直接同意或反駁。這一步防止範圍設得太窄（錯過高價值做法）或太寬（做不完）。每個方向標注它賭的信念（例如「這個版本假設完整覆蓋勝過快速上手」）——信念寫出來，使用者才能反駁信念而不是挑表面。使用者否決某方向時，把否決蒸餾成一句「你拒絕了 X，代表真正的需求是 Y」，經確認後寫進規格——對選項的反應本身就是規格素材。做法之間的差異取決於「業界怎麼解」而大家都還不知道時，先跑
/scout產出比較報告再回來選。方向多於三個、或差異適合視覺呈現時，做成單一 HTML 比較頁（存notes/）：格狀併排、每個方向標注取捨與適用條件、可加簡易示意圖，底部附「複製我的選擇」按鈕輸出選擇＋理由讓使用者貼回對話。 - 分節起草 SPEC.md：依選定方向逐節填寫，每完成一節就呈現並問「到這裡對嗎」，確認後才寫下一節（節奏依複雜度調整，簡單的節可以併批）——
- 一句話目標、受眾與情境、要做／不做：從對話中蒸餾，用使用者自己的說法。
- 骨架：主動提案（目錄結構、敘事線、頁面流），標注「初稿，待確認」。
- 驗收條件：提議可驗證的完成定義。
- 未知清單：對話中出現過但沒有結論的問題全部記入對應象限。
- 參考範例：對話中提到的任何參考對象。
- 規格自我審查：寫完後用新的眼光掃一遍，就地修正——
- 佔位符掃描：還有沒有「待補」「TBD」或空泛的句子？
- 前後一致：各節之間有沒有矛盾？骨架和目標對得上嗎？
- 範圍檢查：這份規格是不是仍然大到該回頭拆解？
- 歧義檢查：有沒有哪句話可以有兩種解讀？有就挑一種寫死。
- 核可與交棒：請使用者讀一遍規格並核可。核可後建議下一步跑
/interview（釐清沒定的）再/blindspot（掃沒想到的）；使用者要求修改就改完重跑第 6 步。
原則
- 初稿求快不求全：寬鬆的正確勝過精緻的錯誤，細節留給後續兩個 skill 收斂。
- 蒸餾不發明：規格內容必須來自對話與素材，agent 自行假設的部分一律標注「假設」並列入未知清單。
- 範圍提案必須含一個「小到不好意思」的選項——最小可行版本常常才是對的起點；對所有方向無情地刪去非必要功能（YAGNI）。
- HTML 產出一律照 WORKFLOW.md〈HTML 產出與互動介面〉：內嵌留言層＋「複製結果」出口（現成片段
notes/html-comment-layer.html）。