從點子到規格
協助使用者將點子轉化為可供規劃的規格。由你引導對話；使用者負責回答。
產出物與狀態
- 每個工作項存在於
docs/specs/<YYYYMMDD>-<類型>-<名稱>/目錄中。類型遵循 Conventional Commits（feat、fix、refactor、docs…），名稱使用 kebab-case。若目錄已存在，則加上-2。 spec.md與plan.md在前言中標示status: draft | approved | obsolete。只有使用者能設定為approved。- 若修改已核准的產出物，則將其狀態改回
draft並告知使用者。 - 工作管理（優先權、負責人、完成與否）不屬於本技能的範疇：應由追蹤系統處理。若有相關 issue，其 ID 記錄在
issue:中。
行為
- 首先用一段話簡短總結該點子。
- 識別撰寫優良規格所需但遺漏的資訊，並提出最少且最有用的問題，先問阻礙性問題。
- 專注於「什麼」與「為什麼」，而非「怎麼做」：除非使用者要求，否則不涉入框架或架構。這部分屬於
spec-to-plan。 - 若
docs/ARCHITECTURE.md存在，請先讀取，以使用其詞彙表的用語，並避免與其原則衝突。
回合制問題
- 問題與預期成果。
- 使用者與參與者。
- 使用者故事（每位使用者需要什麼及其原因）。
- 範圍與非範圍。
- 行為與邊界案例：空資料、無效資料、大量資料、外部依賴失敗、並行操作。
- 非功能性限制。
- 安全性：若涉及資料、身分驗證或外部輸入，需確認資料敏感度、誰能做什麼、哪些輸入不可信任、以及需要哪些負面測試。
- 驗收標準（「Given…, when…, then…」）。
若某個回合後仍有不明確之處，僅針對該部分提問。
待解決問題
絕不預設答案。 對每個未解決的問題：
[問題]
- A) [你的預設提案（若有的話）]
- B) [明顯的替代方案]
- C) 留待規格中作為待解決問題
- D) 其他答案
只有在使用者回答或選擇留待解決時，問題才算獲得解決。
每次回覆的格式：我理解的內容 · 待解決的問題 · 下一步。
規模
根據變更的深度調整產出。建議路徑並讓使用者決定：
| 變更類型 | 產出物 |
|---|---|
| 一行程式碼的錯誤 | 無，或僅 tasks.md |
| 複雜的錯誤 | spec.md + tasks.md |
| 小型功能 | spec.md + plan.md + tasks.md |
| 生產功能或架構重構 | 全部，需進行規格與計畫審查 |
何時停止
當已足夠涵蓋以下內容時即停止：目標、問題、使用者、使用者故事、範圍與非範圍、功能與非功能性需求、邊界案例與驗收標準。
接著：
- 提議目錄名稱，並從
assets/spec-template.md草擬spec.md，狀態設為draft。刪除不適用的選用章節。 - 展示草稿，並在使用者核准後才正式寫入。
- 建議下一步：使用
review-spec進行審查。若變更規模小且使用者滿意，他們可以將狀態標記為approved，並進入spec-to-plan。