無縫設計 是做什麼的？
分為三個部分：該修什麼（checklist.md，每個修正附帶理由）、如何編排（process.md，審查員與開發者並行進行的回合制流程）以及案例與來源（references.md：催生此技能的五個前後對比案例，以及《重構 UI》的對應地圖）。每位審查員填寫的規範卡片位於 spec-card.md 中。各平台備註（SwiftUI、Compose、Web、小工具、手錶、車載系統）則放在 platforms.md 裡。只讀取你需要的部分，不必全部閱讀。
原則（不可協商）
- 修正是一條規則，而非調整。 每個變更都以 token 或元件（間距、字型大小、字重、色彩角色、圓角、陰影、按鈕）的形式出貨，絕不作為視圖中的字面值。如果 token 不存在，就在同一次變更中建立它。根據尺度內的 排除法 挑選數值（嘗試該數值及其兩個相鄰值；取中間值，否則重複），而非逐像素調整。
- 層級先於色彩。 畫面必須在 灰階 下就能運作：靠間距、大小、字重和對比度完成分層；色彩只是後來加上去，且僅表達某種意義。如果在灰階下不清楚什麼是重點，色彩也無法解決。
- 你讀到的第一個東西就是答案。 每個畫面只有一個主角數字（餘額、價格、今天的進度）；其他一切都要退居其次。透過 弱化競爭者 來強調主角，而非放大主角本身。每個畫面最多一個深色/主角表面，且 在半頁或模態視窗中完全不要有。
- 色彩只表達一件事。 一個品牌強調色用於行動按鈕或主角數字；其他一切都是有含義的角色（金錢/成功、上升/危險、狀態、獎勵），灰色用於只負責導航的元素。裝飾性色彩 = 冗飾。色彩絕不單獨使用：必須搭配形狀或文字。
- 量化的對比度，而非假設。 WCAG AA（一般文字 4.5:1，大型文字與圖示 3:1）根據實際十六進位數值與實際背景（淺色和深色）計算。白色文字放在綠色/黃色品牌色彩上幾乎從來不會通過；灰色文字放在彩色背景上也不會通過（應選用同一色調的深淺變化）。
- 畫面無法傳達的就不要放。 沒有虛構的數字、沒有偽裝成資料的預測、沒有暗示不存在功能、沒有說謊的空白狀態。設計你真正能出貨的最小版本。
- 一個源自領域的標誌性手勢。 來自應用程式所顯示內容的品牌細節（例如價格看板上的價格，最後一位數字較小；跑步應用上的點陣數字），而非新的字型或特效；並且在不需要的地方能優雅降級。其他一切皆為原生：不要對抗標籤列、開關或系統表單。
- 平台一起出貨。 如果專案同時有 iOS 和 Android（或 App 和 Web），則在同一個 PR 中將變更套用到兩個平台，並包含所有語言。
- 驗證使用者所見的內容。 截圖包含淺色和深色模式、最大文字大小、非預設貨幣/語言、真實資料（長名稱、空白、2000 個項目）。無法在你的環境中編譯的部分，透過閱讀程式碼進行審計，並在 PR 中說明。
任何代理（Claude Code、Codex、Cursor、Copilot、Gemini……）
規則到處都一樣。在提到「代理」的地方，請使用你的工具所提供的功能：如果有子代理（如 Claude Code、Codex……），則為每個開發者使用獨立的 git worktree。如果沒有子代理，則一個接一個地執行審查員，每次附上各自的簡報，並在陪審團步驟之前保持他們輸出的獨立性。在提到「發佈」的地方，Claude Code 會發佈一個 artifact；其他代理則撰寫一個讓使用者開啟的 HTML 檔案。在沒有程式碼庫的聊天應用程式中，請在前後對比提案之後停止。
工作約定（預設值）
- 審查員 = 資深產品設計師，開發者 = 資深開發者，以代理形式執行（使用使用者要求的模型）。協調者不負責建立各個領域：它負責共享工作、整合和審計。
- 每個決定都附帶一個 明確、可執行的建議。
- 實施之前，先發佈前後對比，並等待使用者的「是」。
- 每個回合也審查先前回合出貨的內容以及 所有 收到的影片/截圖，而不僅僅是最新的。
- 當 CI 通過後允許合併時：關閉時附上一份清單，說明編譯時應檢查的項目（具體風險），如果沒有 Mac/模擬器，則附上一個可在本地階段使用的自包含提示。
- 當被問到「一切都完成了嗎？」：已完成（附 PR）· 等待你處理 · 故意遺漏。
- 在最後一個回合之後，更新專案的設計系統。
簡短流程
- 盤點：從影片中提取幀（
process.md§ 1）、畫面與狀態，以及每個畫面在程式碼中的位置。 - 系統：檢查（或建立）間距、字型、色彩和高度尺度（
checklist.md§ 系統）。沒有尺度，審查員就只能憑感覺判斷。 - 灰階通過 + 並行審查員（3-4 位，每人負責一個領域）對照
checklist.md，一次只套用一個修正。 - 獲勝提案：一個 HTML 頁面，包含前後對比、規範卡片和決策清單；由使用者選擇。
- 每個領域的開發者在隔離的 worktree 中，附上封閉的簡報進行開發；整合、編譯、審計、PR、回覆審查機器人，待 CI 通過後合併。
- 最後：用新增的內容更新專案的設計系統（文件 + tokens + 其自身的技能）。
如果專案已有自己的設計技能
請使用它提供的具體 tokens 和元件；此技能負責提供方法和通用檢查清單。如果此處的規則與書面的專案決策衝突，則以專案為準，並在提案中標明。