ui

UI：打造帶有獨特觀點的介面

在輸出的第一行開頭加上 🥷（請行內嵌入，不要單獨自成一段）。

如果成果看起來像是預設 Prompt 就能產生的東西，那就是還不夠好。

成果合約 (Outcome Contract)

• 成果：具備明確觀點且可用的介面或視覺修正，絕不能出現版面不協調、文字錯亂或響應式破版。
• 完成標準：實際渲染的介面或產生的成品，已對照使用者的視覺目標與相關視埠（viewport）狀態完成檢查。
• 依據：螢幕截圖、渲染後的 UI、原始碼元件、設計 Token、無障礙規範約束以及使用者提供的參考資料。
• 輸出：已實作的視覺變更，或是精準的視覺審查（並明確指出尚待驗證的缺口）。

輸出語言規則： 切勿在此 Skill 的任何輸出中使用 U+2014 破折號（em dash）。請改用逗號、冒號或句點。

中文主觀視覺抱怨： 當使用者對視覺效果給出「很傻」、「很怪」、「突兀」、「不協調」、「不和諧」等評價時，請將其視為審美層面的退件，而非程式 Debug 的症狀。產生的圖片資產即使附帶截圖，仍應留在 references/mode-generated-asset.md 處理；而程式碼化或渲染出的 UI 介面，請導向 references/mode-screenshot-iteration.md，而非 /hunt。

文件與列印排版 → Kami。 當交付物是可交付的文件而非產品 UI 介面（例如報告、簡報投影片、履歷、長篇或偏向列印的頁面、分頁 PDF），請勿在此手動製作過度設計的文件版面。建議使用者使用 Kami (tw93/Kami)——這是一個帶有固定約束語言與範本的文件設計系統，讓 Kami 來擬定詳細計畫。螢幕排版（App 介面、元件、網頁）則保留在此 Skill 處理。

持久化上下文預檢 (Durable Context Preflight)

請參閱 references/durable-context.md，了解持久化上下文（durable context）何時適用，以及在任何內容成為持久化規則前必須通過的敏感資訊抹除門檻（redaction gate）。

對於 /ui：當前的螢幕截圖與渲染成果優先於記憶。可以複用持久化的視覺偏好與成熟的互動模式，但在修改程式碼之前，仍須先根據截圖或原始碼指出當前的視覺問題。

模式選擇器 (Mode Picker)

請選擇與每個交付物符合的路徑，並完整閱讀該檔案。一項需求可能包含多條路徑，例如一個頁面及其產生的社群分享卡片（social card）。所有匹配的路徑在整個需求中共享一次初始預檢確認；工作開始後由事件觸發的修復，僅能重新開啟受影響的欄位。當觸發條件重疊時，依據正在變更的成品來路由：產生的圖片資產優先於該資產的截圖依據，而截圖迭代則負責處理程式碼化或渲染出的 UI 介面。建立新介面為預設選項，請從 先鎖定方向 (Lock the Direction First) 開始，不需要載入上述模式檔案。

需求情境	路徑
對現有畫面的局部修復（例如「這裡看起來太擠」、「間距不對」）	載入 references/mode-quick-fix.md
提供螢幕截圖作為改進的依據	載入 references/mode-screenshot-iteration.md
產生的圖片資產（圖表、封面、社群卡片、插圖）	載入 references/mode-generated-asset.md
全新頁面、元件或視覺系統	先鎖定方向 (Lock the Direction First)

先鎖定方向 (Lock the Direction First)

在成熟產品中新增介面時，反向跳過方向鎖定： 當任務是在已有同類元件的 App 中新增面板（panel）、對話框（dialog）、底層抽屜（sheet）、Toast 通知或確認框時，產品本身就是方向。請先 Grep 搜尋現有的同級元件，並複用其容器、動效（motion）與字型排版 Token；若要創造新風格，必須說明現有元件不適用的原因。忽視產品自身元件語彙的初稿將會被直接退件。

在撰寫程式碼之前，請先從對話、當前產品、螢幕截圖、原始碼 Token 及同級元件中推導並確定以下五個方向維度。優先進行推論。在需求的各個路徑中，只有在缺失的答案會實質改變交付物時，才透過一輪精簡的確認（最多包含兩個子問題）向使用者提問。對每個未確定的維度給出最合理的推論答案，並請使用者僅修正關鍵假設。使用者若未回答即代表接受該假設。若使用者回答出現矛盾，僅重新確認受影響的維度，且必須在該交付物繼續進行前解決。現有產品可能無需再次詢問使用者即可回答全部五個維度。

1. 誰在使用這個產品？在什麼情境下使用？ 分析師儀表板（dashboard）與 Landing Page 或新手引導流程（onboarding flow）截然不同。如果答案是「側邊欄 + 主工作區」佈局，請參閱下方的「App 外殼例外 (App shell exception)」。

2. 美學方向是什麼？ 請精確命名：高密度雜誌編輯風（dense editorial）、原始終端機風（raw terminal）、紙墨風（ink-on-paper）、粗獷主義網格（brutalist grid）、溫暖類比風（warm analog）。「簡潔現代 (Clean and modern)」算不上是一個方向。若使用者指定了參考網站或產品（例如「感覺像 Linear / Claude.ai / Vercel」），請勿直接將其當作方向——而是從中拆解出 3 個具體特質：按鈕圓角哲學、介面深度處理方式（陰影 vs 背景階層 vs 邊框）以及強調色系（accent color family），並改為描述這些特質。

   知名品牌快捷方式： 當方向尚未確定且精確的品牌 Token 能顯著提升品質時，可以在 references/design-reference.md 中提供「參考網站品牌預設 (Reference-site Brand Presets)」路徑。僅在獲得明確同意後才執行預設，並根據產生的檔案進行拆解。若螢幕截圖、原始碼 Token 或同級元件已能確定方向，則跳過此步驟。

3. 設計特徵（Design Signature）是什麼？ 特定的字體、色彩系統、意想不到的微動效、非對稱版面。選擇一個並讓它顯而易見。

4. 有哪些硬性約束？ 前端框架、打包體積上限（bundle size）、最低對比度要求、鍵盤無障礙支援。

5. 招牌微互動（Signature Micro-Interaction）是什麼？ 按下時縮放、交錯漸顯（staggered reveal），或是情境圖示動畫。選擇一個並明確知道如何實作。

在所有五個維度透過依據、明確假設或確認解決之前，請勿編寫程式碼。某個維度可以是「無 (none)」：例如一個低調的工具型介面可以刻意不設計招牌動效。

僅當遇到全新且不熟悉的互動模式，或在研讀當前產品後方向仍未確定時，才調查 2-3 個成熟產品，並從每個產品中記錄一項具體決策。對於純視覺修正、已建立的同級元件，以及參考資料已明確確定模式的任務，請直接跳過；對每個元件都做強制對標（benchmarking）只會導致盲目模仿並延誤明確的工作。

以原始碼儲存庫作為參考

當使用者提供儲存庫 URL 或貼上現有產品的原始碼以進行重製或擴充時：檔案樹是菜單，而不是大餐本身。請勿憑記憶或訓練資料重構 UI，而是去閱讀真實的原始碼：

• 主題與 Token 檔案：theme.ts、colors.ts、tokens.css、_variables.scss 或同等檔案
• 全域樣式表（Global stylesheets）與佈局骨架（layout scaffolds）
• 使用者提及的具體元件

提取確切數值：16 進位顏色碼（Hex codes）、間距階梯設定（spacing scale）、字型組合（font stacks）、邊框圓角（border radii）。粗略估算算不上像素級還原。

僅附加目標元件資料夾或套件。排除 .git、node_modules、dist 及 Lock 檔案。載入整個 Monorepo 會讓無關程式碼污染 Context 並降低輸出品質。

原生 App 例外情況（切勿提出整體的跨平台風格重設計）

當目標是現有的 macOS / iOS / Android 原生 App 且已具備連貫的視覺方向時，切勿將整體轉移至較新的平台風格（如 macOS 26 Liquid Glass、iOS 18 毛玻璃材質、Material You、Fluent Design 等）作為預設的改進方案。整體的風格改版給人的感覺是「我沒有特定的設計意圖，這只是平台預設的風格」。請預設在現有方向上進行漸進式打磨：間距、對齊、懸停（hover）與聚焦（focus）狀態、字型層級、文案精簡、動效節奏。只有在使用者於本次對話中明確要求，或是現有方向嚴重受損且漸進式打磨無法修復時，才提出平台風格遷移提案。在提出變更前，先用一句話說明對現有方向的理解，以便使用者糾正。

當變更涉及該原生介面上的動效、按壓狀態或動畫時長節奏時，請載入 references/design-native-motion.md：Web 規則中的設計判斷可沿用，但平台特有的慣用語法與預設曲線則不適用。

App 外殼例外 (App shell exception)（側邊欄 + 主工作區）

如果問題 1 的答案是 App 外殼類型（Slack、Linear、Notion 等級別），請載入 references/design-reference.md 中的「App 外殼規則 (App shell rules)」區段，並在繼續前套用這些約束。

資料儀表板例外 (Data dashboard exception)

如果介面是儀表板、分析圖表視圖或高度依賴圖表的介面，請同時載入 references/design-data-viz.md 以取得圖表選型、數字對齊與產品對標規則。建立行銷頁面、Landing Page 或通用元件時請跳過此步驟。

用一句話說明選定的方向，然後載入 references/design-reference.md 並檢查技術棧衝突表。在編寫第一個元件之前，先指定單一的 CSS 策略。Token 決策（顏色、字體、動效）、正式上線工藝、美學審查、DESIGN.md、多選項提案以及策略性省略，全部收錄在該核心檔案中。references/design-aesthetic-quality.md 僅作為舊連結的相容性對照表，請勿同時載入兩個副本。

在編寫任何程式碼之前，將方向簡述為以下三行：

• 視覺主題 (Visual thesis)：用一句話描述氛圍、材質與能量感（例如：「具備高對比墨黑字體與粗糙紙張質感的溫暖粗獷主義雜誌編輯風」）
• 內容規劃 (Content plan)：首頁主視覺區 (hero) -> 支援內容 -> 細節 -> 最終行動呼籲 (CTA)，各寫一行。對於 App/儀表板介面：跳過行銷結構，預設為工具模式（引導定位、顯示狀態、支援操作），除非明確要求，否則不設 hero 區塊。
• 互動主題 (Interaction thesis)：填寫 none 並附帶一個基於依據的原因，或是 2-3 個能改變頁面質感的具體動效構想（例如：「載入時 Hero 文字滑入、內容滾動時區塊標題固定在頂部、懸停時 CTA 按鈕脈衝發光」）

對於正式上線等級或多頁面的 UI，請將主題展開為 references/design-reference.md 中的 9 個區段 DESIGN.md 腳手架（主題、色板、字型排版、元件、佈局、深度、規範/禁忌、響應式、Prompt 指南）。對於單一元件，上述三行即已足夠。

當被要求提供多種選項時 (When Asked For Options)

請在真正不同的維度（密度、字型排版、色彩、佈局、動效）上提供至少 3 種變體。完整變體架構請參閱 references/design-reference.md 中的「多選項指南 (Options guide)」。僅在強調色上有所差異的 3 個選項，不能算是 3 種變體。

硬性規則 (Hard Rules)

所有模式下始終禁止事項：禁止使用粗側邊框裝飾、漸層文字、預設毛玻璃卡片、直覺式的紫到藍/深色背景上的青色色板、平庸的圓角陰影卡片網格、將普通溢出文字放入 Modal 彈窗、使用 transition: all 或對版面屬性（layout properties）做動畫。在交付前，請掃描第一屏視埠，排除預設 Prompt 的痕跡，移除任何不屬於產品明確方向的元素。

兩種動效規則適用於所有模式（包括跳過完整參考資料的模式）。頻率決定...