RoyalMilkteaMaster Milktea Skills To Spec
把已核准內容整理成唯一規格來源。全程使用繁體中文；程式識別字保留原文。
前提
下列內容必須已核准：
docs/planning/requirements.md的需求與驗收結果。docs/planning/architecture.md的架構、資料流與測試接縫。
需求或架構缺少或互相衝突時停止，指出應回到哪個階段；不得自行補問或猜測。
儲存位置
- 固定使用本機 Markdown：
docs/work/<功能名稱>/spec.md。 <功能名稱>使用簡短、可辨識的 kebab-case；同一工作沿用既有目錄，不同工作撞名時追加-02、-03。- 不為了儲存或交接執行
git add、Commit、Push、建立 Repository 或修改 Git 設定。
流程
- 讀取
docs/planning/requirements.md、docs/planning/architecture.md、專案指令、CONTEXT.md、相關 ADR 與程式庫現況。 - 依下方格式撰寫規格，不加入未確認內容。
- 建立工作目錄並寫入固定路徑。
- 顯示完整規格與實際路徑，等待使用者核准；修改後更新同一來源，不建立副本。
規格格式
# 〈規格名稱〉
## 問題
## 目標
## User Stories
1. 身為〈角色〉，我希望〈能力或行為〉，以便〈價值〉。
## 需求與行為
## 實作決策
- 資料與所有權
- 模組責任與公開介面
- Schema、API contract 與系統互動
- 相容、遷移與技術限制
## 驗收條件
- 使用可觀察、可判定的結果。
## 測試決策
- 公開行為
- 測試接縫
- 既有測試模式
- 不應耦合的實作細節
## 使用情境 QA
- 本次啟用：是／否。
- 判斷理由：
## 本次採納的既有 QA 問題
- 無，或列出問題 ID、來源文件與本次應成立的改善結果。
## 不在範圍內
## 補充
規則
- User Stories 描述誰需要什麼及原因；驗收條件描述怎樣才算完成。
- 使用專案術語並遵守 ADR。
- 寫模組與介面名稱；省略易過期的檔案路徑、行號與大段程式碼。
- 原型已驗證的狀態機、Schema 或型別只保留決策所需片段並標記來源。
- 不實作、不拆 Ticket、不修改來源碼。
- 使用情境 QA 的開關沿用 Planner 或使用者的決定，不重新詢問；未提供時記錄為否。既有 QA 問題只納入本次已採納的項目。
完成條件
- 規格只包含核准內容。
- User Stories 與驗收條件完整。
- 架構與測試決策可供拆票。
- 規格已寫入本機固定路徑。
- 使用者核准規格。