元件與 UI 設計技能 (component-design)
一套結構化的 UX/UI 探索與規格制訂工作流程，適用於設計網頁與應用程式的元件、區塊及頁面。產出可被視覺原型工具（如 stitch-design）及程式碼實作工作流程消耗的生產級設計規格書 (design-spec.md)。
守則與核心原則
[!IMPORTANT] 1. 零編碼守則（純設計範疇）：此技能嚴格專注於 UX、UI、佈局架構、字體排版與視覺記號。絕不產出 React 元件、Next.js 指令、TypeScript prop 介面或套件安裝指令（無 shadcn/Radix CLI 指令）。程式碼實作由下游開發流程處理。
[!CAUTION] 2. 設計記號前置閘門（記號優先規則）：在未驗證
docs/project.json中有正規的設計記號之前，無法設計任何元件。遺漏的記號必須先透過訪談補齊並持久化，然後才能起草元件設計。請參閱 token-verification-matrix.md。
[!TIP] 3. 記號節省規則（禁止在技能內直接產生圖片）：絕不直接呼叫
generate_image。應為使用者制定結構化的圖片生成提示，讓使用者自行產生並放入專案目錄中。
[!NOTE] 4. 選擇性模式查閱（記號節省）：檢查
references/component-design-patterns.md中的路由表，僅載入references/patterns/下相符的元件檔案（例如hero.md）。若相符，在適應性訪談中明確詢問使用者是否希望實作該模式。
工作流程概述
flowchart TD
Start["觸發 /component-design<br/>(頁面 + 元件名稱)"] --> Step1["步驟 1：動態內容與記號閘門<br/>(掃描 docs/**、CONTEXT.md、記號與目標模式)"]
Step1 --> CheckTokens{"設計記號在<br/>docs/project.json 中是否完整？"}
CheckTokens -- "缺少記號" --> GrillTokens["訪談缺少的記號<br/>(提供 3 個與情境相關的選項)"]
GrillTokens --> SaveTokens["持久化至 docs/project.json"]
SaveTokens --> Step2
CheckTokens -- "已驗證" --> Step2["步驟 2：多輪適應性訪談<br/>(第 1–3 輪 + 目標模式訪談)"]
Step2 --> Step3["步驟 3：視覺資產提示制訂<br/>(提供可直接使用的圖片提示)"]
Step3 --> Step4["步驟 4：建立並撰寫 design-spec.md<br/>(docs/design/components/[page]/[component]/)"]
Step4 --> Step5["步驟 5：子代理稽核與自動修復<br/>(invoke_subagent 檢查守則與記號)"]
Step5 --> Finish["規格書準備就緒，可交付下游<br/>(視覺原型 / 實作)"]
執行手冊
步驟 1：動態內容探索與設計記號驗證閘門
- 掃描專案內容：動態檢查
docs/目錄下所有檔案以及根目錄的CONTEXT.md，以提取目標角色、商業目標與現有設計書籤。 - 掃描支援的地區設定：讀取
docs/project.json中的project_context_and_metadata.supported_languages。 - 驗證設計記號：根據 token-verification-matrix.md 稽核
docs/project.json中的"design_system"。 - 訪談缺少的記號：若記號遺失，制定 3 個針對專案的選項（標記一個為
(推薦)），詢問使用者後將結果持久化至"design_system"下。 - 目標設計模式查閱：掃描
references/component-design-patterns.md中的路由表，僅查看references/patterns/下與正在設計的元件相符的特定元件模式檔案。
步驟 2：漸進式多輪元件訪談
使用 ask_question（或互動式聊天）執行適應性的三回合訪談，在回合之間暫停以吸收使用者回答。請參閱 adaptive-grilling-rounds.md 以了解完整的問題格式：
- 若在
references/patterns/中找到相符的模式，將其問卷整合到第 1 輪或第 2 輪，明確詢問使用者是否希望實作該模式。 - 第 1 輪（意圖與故事）：釐清元件目的、使用者待辦工作與情感基調。
- 第 2 輪（空間層次與網格）：根據第 1 輪的回應，調整多欄佈局、密度規模與焦點視線流。
- 第 3 輪（互動與強調色）：根據第 1 輪與第 2 輪的結果，建立懸停/焦點狀態動態、媒體資產與 BiDi / RTL 細微差別。
步驟 3：主動式視覺資產提示制訂
若元件需要客製圖形、背景或圖示，為使用者制定結構化的生成提示，而非直接呼叫 generate_image。請參閱 adaptive-grilling-rounds.md 中的提示區塊格式。
步驟 4：建立元件資料夾與 design-spec.md
- 建立目錄：
docs/design/components/[page name]/[component name]/ - 使用 design-spec.template.md 中的標準九段佈局建立
design-spec.md：- §1 執行摘要與故事
- §2 視覺層次與空間流程
- §3 佈局網格與回應式中斷點（手機、平板、桌面）
- §4 設計記號與色彩對應（淺色與深色）
- §5 字體排版比例（每個支援的地區設定）
- §6 互動狀態矩陣（預設、懸停、啟用、焦點、停用、骨架載入）
- §7 雙向（RTL）適應
- §8 無障礙與人體工學（WCAG AA/AAA、$\ge 44\text{px}$ 觸控目標）
- §9 建議的視覺資產與提示
步驟 5：獨立子代理品質稽核 (invoke_subagent)
為確保無偏差的品質，在將結果呈現給使用者之前，呼叫一個獨立的審查子代理：
- 啟動稽核子代理（
TypeName: "self"、Role: "Independent Design & UX Auditor"、Model: "inherit"）。 - 使用 subagent-audit-protocol.md 中的結構化稽核提示。
- 若發現
ISSUES_FOUND，在結束前立即解決design-spec.md中所有被標記的問題。
下游交付
一旦 design-spec.md 獲得批准並驗證：
- 視覺原型：觸發
stitch-design以在 Google Stitch 中產出 UI 畫面與佈局變體。 - 程式碼實作：將
design-spec.md提供給元件實作技能（例如nextjs-component-dev/nextjs-create-component）。
執行驗證檢查清單
在完成執行前，請確認：
- 交付物中不含任何程式碼或函式庫安裝指令（無 React、Next.js、shadcn CLI）。
-
docs/project.json中的正規設計記號已驗證且完整。 - 輸出目錄結構為
docs/design/components/[page]/[component]/。 - 訪談選項是動態合成的，沒有任何硬編碼的儲存庫假設。
- 元件訪談遵循漸進式適應性回合。
- 未直接呼叫
generate_image；已向使用者提供資產提示。 -
design-spec.md包含所有 9 個必要章節。 - 已透過
invoke_subagent呼叫獨立子代理稽核，且所有問題均已解決。