# Kickoff

> 開案——建立專案骨架（缺件時）並從一個粗略想法產出 SPEC.md 初稿。使用時機：專案剛開始或在空資料夾開工、SPEC.md 還是空白模板、或使用者說「開案」「kickoff」「init」「初始化專案」「幫我起草規格」「我想做⋯⋯（一個粗略想法）」時。安裝位置：使用者層（~/.claude/skills/），空專案才有 skill 可用。

- Skill: `mirandaplayer1/kickoff-2` (Agent Skill, multi-file: 8 files)
- Install (CLI): `npx skillmds@latest add mirandaplayer1/kickoff-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mirandaplayer1/kickoff-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: mirandaplayer1 (https://skillmd.com/u/mirandaplayer1)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mirandaplayer1/kickoff-2

---


# 開案（Kickoff）

目的：規格初稿不該讓使用者面對空白模板憑空填寫，而是從一段腦力激盪對話中蒸餾出來。使用者只需要帶一個粗略想法來；工作流骨架（檔案模板）缺件時由本 skill 順手建好。

**門檻：SPEC.md 初稿未經使用者核可前，不進入任何實作。專案再簡單都要走這個流程——簡單專案的規格可以短到幾句話，但不能跳過。「太簡單不用規格」的專案，正是未經檢驗的假設造成最多重工的地方。**

## 步驟

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

## 原則

- 初稿求快不求全：寬鬆的正確勝過精緻的錯誤，細節留給後續兩個 skill 收斂。
- 蒸餾不發明：規格內容必須來自對話與素材，agent 自行假設的部分一律標注「假設」並列入未知清單。
- 範圍提案必須含一個「小到不好意思」的選項——最小可行版本常常才是對的起點；對所有方向無情地刪去非必要功能（YAGNI）。
- HTML 產出一律照 WORKFLOW.md〈HTML 產出與互動介面〉：內嵌留言層＋「複製結果」出口（現成片段 `notes/html-comment-layer.html`）。