brief-to-tasks

此技能將設計簡報轉換為有序且可建置的任務清單。每個任務都是一個垂直切片：一個可以獨立建置、審查和驗證的 UI 片段。

範例提示

• 「將簡報拆解為任務」
• 「我應該先建置什麼？」
• 「從設計簡報建立任務清單」
• 「規劃此功能的建置順序」

流程

1. 讀取設計簡報。尋找 .design/*/DESIGN_BRIEF.md。如果存在多個子資料夾，則使用最近修改的那個，或詢問使用者正在處理哪個功能。同時檢查同一子資料夾中是否有 INFORMATION_ARCHITECTURE.md 和 tokens 檔案。如果都不存在，請使用者描述他們正在建置的內容。

2. 探索現有程式碼庫，了解已建置的內容。特別掃描以下項目：

   • 元件目錄：components/、ui/、shared/，並列出每個元件的名稱
   • 現有頁面/檢視：已建置哪些內容，此功能必須與之共存
   • Token/主題檔案：tokens.css、globals.css、Tailwind 設定、主題提供者
   • 檔案命名慣例：kebab-case、PascalCase，檔案如何組織（依功能、依類型）
   • 測試檔案：如果測試與元件並存，新任務應包含測試預期
   • Package.json 相依套件：已安裝哪些 UI 函式庫、動畫函式庫和圖示集
   • 將每個相關元件分類為：將原樣重複使用、需要修改、或尚不存在。只有需要修改或建立的元件才會獲得自己的任務。

3. 將工作拆解為垂直切片。每個任務應：

   • 可獨立建置（除非另有說明，否則不應有任務阻擋其他任務）。
   • 在單一任務中包含結構、樣式和互動（不要將「建立 HTML」、「加入 CSS」、「加入 JS」分為不同任務）。
   • 可驗證：你可以查看結果並確認其符合簡報。
   • 足夠小，可在單次工作階段中完成。

4. 依以下順序排列任務：

   • 相依性優先：基礎元素（tokens、佈局外殼、共用元件）先於頁面特定工作。
   • 視覺優先：最突出的 UI 元素先做，讓使用者能在投入細節前驗證美學方向。
   • 風險優先：最困難或不確定的部分先做，以便在圍繞它們建置其他所有內容之前發現問題。

5. 將任務清單儲存為 TASKS.md，放在與設計簡報相同的 .design/<feature-slug>/ 子資料夾中。

任務清單範本

# 建置任務：[功能/頁面名稱]

產生自：.design/<feature-slug>/DESIGN_BRIEF.md
日期：[日期]

## 基礎
- [ ] **[任務名稱]**：[一句話描述要建置什麼以及「完成」的樣貌]。_重複使用：[現有元件/tokens，如果有的話]。_
- [ ] **[任務名稱]**：[描述]。_新元件。_

## 核心 UI
- [ ] **[任務名稱]**：[描述]。_依賴於：[任務名稱，如果有的話]。_
- [ ] **[任務名稱]**：[描述]。

## 互動與狀態
- [ ] **[任務名稱]**：[描述]。涵蓋：[狀態列表，例如 hover、loading、error、empty]。
- [ ] **[任務名稱]**：[描述]。

## 響應式與打磨
- [ ] **[任務名稱]**：[描述]。斷點：[哪些斷點]。
- [ ] **[任務名稱]**：無障礙檢查。[簡報中指定的具體檢查項目]。

## 審查
- [ ] **設計審查**：執行 /design-review 與簡報比對。

規則

• 每個任務必須說明是重複使用、修改還是建立元件。
• 絕不要建立僅為「設定專案」或「建立檔案結構」的任務。這些不是垂直切片。
• 如果簡報指定了美學理念，請在第一個建置任務中註明，以便立即確立視覺方向。
• 將相關任務分組，但不要嵌套超過一層。扁平清單更容易處理。