design-flow

此技能依序執行每個階段來協調完整的設計師工作流程。你是一位引導者，帶領設計師走過每個階段。不要急。每個階段必須完成並確認後，才能進入下一個階段。

範例提示

• 「執行完整的設計流程」
• 「帶我走過新專案的完整流程」
• 「從頭開始，帶我經歷所有步驟」
• 「儀表板應用程式的設計流程」

流程順序

1. 需求釐清（Grill Me）     → 釐清想法
2. 設計簡報（Design Brief）      → 記錄意圖
3. 資訊架構（Info Architecture）  → 定義結構
4. 設計標記（Design Tokens）     → 建立視覺系統
5. 簡報轉任務（Brief to Tasks）    → 規劃開發
6. 前端設計（Frontend Design）   → 建構
—
7. 設計審查（Design Review）     → 準備好時單獨執行

規則

1. 開始時，告知設計師完整的流程順序（階段 1-6，審查可單獨執行），並詢問他們是否想跳過任何階段。常見的跳過模式：

   • 已經有明確想法 → 跳過需求釐清
   • 單一元件，非完整頁面 → 跳過資訊架構
   • 已有標記的現有專案 → 跳過設計標記

2. 每個階段前，宣布你將進入哪個階段以及會產出什麼。例如：「階段 2：設計簡報。我將訪談你關於專案的內容，並產出 DESIGN_BRIEF.md 檔案。準備好了嗎？」

3. 每個階段中，讀取對應的 SKILL.md 檔案並遵循其完整指示。不要摘要或縮減技能內容。正確執行它。

4. 每個階段後，總結產出了什麼（檔案名稱、關鍵決策、任何未解決的問題），並詢問：「準備好進入下一個階段了嗎？」等待確認。

5. 階段之間，檢查前一個階段的輸出是否會改變下一個階段的內容。例如，如果簡報中提到了某種設計哲學，提醒設計師標記階段會使用它。

6. 設計師可以隨時停止。 如果他們說「這樣就夠了」，總結他們在流程中的位置，以及下次回來時的下一個階段是什麼。

階段細節

階段 1：需求釐清

讀取 grill-me 技能（grill-me/SKILL.md）並遵循其指示。
產出：對專案的共同理解。無檔案輸出。
過渡：「我們已經解決了關鍵決策。準備好將這些記錄成設計簡報了嗎？」

階段 2：設計簡報

讀取 design-brief 技能（design-brief/SKILL.md）並遵循其指示。
產出：.design/<feature-slug>/DESIGN_BRIEF.md。
過渡：「簡報已儲存。接下來是資訊架構，我們將定義頁面結構和導覽。如果你正在建構單一元件，可以跳過這個階段。要繼續嗎？」

階段 3：資訊架構

讀取 information-architecture 技能（information-architecture/SKILL.md）並遵循其指示。
產出：.design/<feature-slug>/INFORMATION_ARCHITECTURE.md。
過渡：「資訊架構已定義。接下來我們將根據簡報中的設計哲學產生設計標記（顏色、間距、字體）。要繼續嗎？」

階段 4：設計標記

讀取 design-tokens 技能（design-tokens/SKILL.md）並遵循其指示。
產出：標記檔案（CSS 變數、Tailwind 設定或主題檔案，取決於技術棧）。
過渡：「標記已設定。接下來我將把簡報拆解成任務清單，以便我們按順序建構。要繼續嗎？」

階段 5：簡報轉任務

讀取 brief-to-tasks 技能（brief-to-tasks/SKILL.md）並遵循其指示。
產出：.design/<feature-slug>/TASKS.md。
過渡：「任務已準備好。現在我們開始建構。我將從清單上的第一個任務開始。要繼續嗎？」

階段 6：前端設計

讀取 frontend-design 技能（frontend-design/SKILL.md）並遵循其指示。
依序處理 TASKS.md 中的任務。完成每個任務後，將其標記為完成，並在進入下一個任務前與設計師確認。
產出：建構好的元件和頁面。
過渡：「流程已完成。你的簡報、資訊架構、標記和任務都已儲存在專案中。當你準備好進行設計審查時，執行 /design-review，我會根據簡報來評析建構結果。」

流程在此結束。 階段 7 不會自動執行。

階段 7：設計審查（僅在要求時執行）

此階段不會自動執行。僅在以下情況執行：

• 設計師在流程中明確要求審查
• 設計師在建構後單獨執行 /design-review

審查需要檢查已建構的程式碼。如果尚未建構任何元件或頁面，請不要執行此階段。相反地，提醒設計師：「當你建構好一些內容後，執行 /design-review。它會根據簡報檢查輸出。」

當觸發時，讀取 design-review 技能（design-review/SKILL.md）並遵循其指示。審查將使用 Playwright MCP（首選）、Cursor IDE 瀏覽器（備用）來擷取執行中應用程式的螢幕截圖，如果沒有可用的瀏覽器工具，則要求使用者手動提供。

產出：.design/<feature-slug>/DESIGN_REVIEW.md + 螢幕截圖儲存在 .design/<feature-slug>/screenshots/。
過渡：「審查完成。螢幕截圖已儲存在 .design/<feature-slug>/screenshots/。如果有必須修正的項目，我現在可以處理它們。」

專案檔案結構

所有設計流程的產出都儲存在 .design/<feature-slug>/ 下，其中 <feature-slug> 是從正在設計的功能衍生出的簡短、小寫、連字號分隔的名稱。這確保多個功能可以獨立設計，而不會互相覆蓋。

.design/
└── <feature-slug>/
    ├── DESIGN_BRIEF.md              ← 階段 2：專案意圖、目標、美學方向
    ├── INFORMATION_ARCHITECTURE.md  ← 階段 3：導覽、頁面結構、使用者流程
    ├── DESIGN_TOKENS.*              ← 階段 4：顏色、間距、字體、陰影（CSS/Tailwind/主題）
    ├── TASKS.md                     ← 階段 5：根據簡報排序的建構檢查清單
    ├── DESIGN_REVIEW.md             ← 階段 7：根據簡報的優先評析
    └── screenshots/                 ← 階段 7：執行中應用程式的視覺證據
        ├── review-[page]-desktop-1280.png
        ├── review-[page]-tablet-768.png
        ├── review-[page]-mobile-375.png
        ├── review-[page]-dark-mode-*.png
        └── review-[component]-[state].png

screenshots/ 子資料夾在設計審查階段建立。所有審查的視覺證據（響應式斷點、互動狀態、深色模式）都儲存在這裡，並使用描述性檔名，以便 DESIGN_REVIEW.md 中的發現可以追溯。

如果設計師中途返回

檢查 .design/ 資料夾中是否存在現有的功能子資料夾。如果功能資料夾內有來自較早階段的檔案（DESIGN_BRIEF.md、INFORMATION_ARCHITECTURE.md、TASKS.md），讀取它們以了解設計師上次進度。如果有多個資料夾，詢問要繼續哪個功能。從下一個未完成的階段繼續。