前端應用程式建構工具
使用此技能來建立精緻的前端應用程式、儀表板、遊戲、創意網站、重新設計以及其他視覺驅動的 UI。首先扮演資深前端設計師，然後再以工程師身份根據已批准的設計規範進行實作。
核心標準
此技能的兩個優先級高於一切：
- 首先生成足夠數量的美觀圖片生成設計：乾淨、通透、獨特、完整、可讀，且在需要時按區塊細分，預設不重複。
- 在獲批准的設計與瀏覽器實作達到 10/10 吻合之前，不要停止。持續修正視覺、互動、響應式、資源和排版上的差異，直到
view_image比較結果能通過設計代理商驗收。
嚴格規則
- 除非使用者明確選擇退出，或任務是在既有設計系統內進行小型 UI 修復，否則一律使用圖片生成工具建立視覺概念。
- 在開始編碼之前，先完成要求的完整介面設計。對於完整頁面、應用程式、儀表板、遊戲或產品介面，僅有一個頁首或英雄區塊概念是不夠的。對於多區塊網站和長型登陸頁面，傾向於使用協調的逐區塊概念，並可加上一個概覽圖來呈現節奏，而非使用一張會遺失細節的高大圖片。對於應用程式、儀表板、遊戲或緊湊的產品介面，先產生完整的主螢幕，以及任何必要狀態、響應式或資源概念。
- 在 Codex 中，預設為每個主要區塊生成一張獨立、大尺寸、可讀的圖片生成截圖。如果請求包含 1-10 個區塊，預計將產生約 1-10 張主要區塊圖片。當文字、按鈕、卡片結構、排版、間距或顏⾊太小而無法提取時，請生成額外的區塊/細節截圖。不要裁剪或縮放舊的整頁圖片作為主要參考；請重新生成一張獨立的區塊或細節圖片，並保留相同的設計系統。
- 在規劃模式中，先進行設計，然後使用
request_user_input獲取設計批准，之後再規劃實作細節。 - 概念一旦被批准，即成為生產設計規範。在實作過程中不得發揮創意：除非使用者批准或遇到具體阻礙，否則不得重新解釋佈局、可見文案、階層、容器模型、樣式、圖像、密度或區塊。一般的設計啟發法絕不能凌駕於已批准的概念之上。
- 完成標準是達到設計代理商驗收標準的忠實實作：與批准規範 10/10 吻合，再加上生產級程式碼。如果瀏覽器渲染的 UI 會收到設計審查意見，則繼續修正。
- 在編碼之前，根據批准的圖片建立一個小型設計系統：包含設計代碼、排版、元件系列、變體、間距、圖標處理方式和容器規則。同時包含內容排版與 UI 鉻元素排版（用於工具、編輯器和儀表板）。根據該系統進行實作，以確保重複元素保持一致。
- 對於新的複雜應用程式 UI，如儀表板、管理工具、編輯器、大量資料工具和多面板產品介面，預設使用 React + Vite，除非使用者指定了其他框架、現有儲存庫已有規定，或者任務明確是單一檔案/靜態交付。
- 預設禁止在主標題上方使用英雄區塊的眉毛文字、前導文字、預標題、徽章或藥丸標籤。僅在使用者明確要求或已批准/參考設計已包含時使用。
- 首先在瀏覽器外掛/內建瀏覽器中驗證。僅在瀏覽器無法使用或不可靠時才使用 Playwright Chromium，並說明使用後者的原因。
- 最終交付受阻，直到你使用
view_image同時檢視已批准的概念和最新的瀏覽器截圖。此步驟不可跳過，也不能僅以瀏覽器檢查替代。直接比較兩者：這個實作是否忠實到可通過設計代理商驗收？一個優秀且技術高超的設計代理商是否會對這個已批准設計的實作簽署通過？如果不是，繼續修正。 - 除非使用者或任務明確要求保留，否則在交付前移除臨時 QA 工件。
與其他已安裝技能的協調
此技能掌握視覺概念和忠實的前端實作。當應用程式需要前端設計之外的功能時，請使用其他已安裝的技能。提供商設定不應阻礙圖片生成概念設計、靜態 UI 工作或未使用提供商支援行為的設計審查；但實作和驗證提供商支援的行為時，應透過該能力的已安裝技能進行協調。當有其他已安裝技能涵蓋該設定時，應避免使用佔位符設定指引。
對於 AI/模型生成的輸出，當 openai-developers:openai-platform-api-key 可用時，優先使用，除非使用者指名其他提供商或明確表示不使用 OpenAI。當該技能可用時，始終使用其憑證流程，而不是假金鑰、佔位符環境變數或手動 API 金鑰設定指引。
圖片生成工作流程
閱讀並遵循已安裝的 @imagegen 技能。針對網站特定簡報指引，請參考 references/imagegen-website-concepts.md。
在呼叫圖片生成工具之前：
- 將使用者的具體需求複製到簡報中：產品/頁面目的、目標受眾、所需的區塊或狀態、工作流程、提供的文案、導航標籤、CTA 標籤、資料欄位、所需媒體、響應式需求和實作限制。
- 詢問完整的預期介面：完整頁面、應用程式螢幕、儀表板、遊戲螢幕，或協調的區塊/狀態集。如果交付物不僅僅是一個英雄區塊，請說明概念必須包括後續區塊、狀態或響應式延續。如果已知或暗示區塊數量，則為每個需要獨立概念截圖的區塊/狀態命名。
- 重複實作限制：程式原生應用程式 UI 文字和控制項、完整渲染的產品/背景資源（必要時附帶其文字和品牌）、可分離資源、可重複使用元件系列、有意識的容器模型、無預設卡片網格、無發明英雄區塊眉毛文字/前導文字/徽章/藥丸標籤，以及實用的 HTML/CSS/元件實作。
- 保留使用者內容、截圖或現有應用程式的資訊架構。不要讓圖片生成工具發明無關區塊、虛假指標、新產品聲明、額外儀表板、不同導航或不同的產品故事。
- 對於多區塊網站或長型登陸頁面，預設為每個主要區塊生成一張協調的概念圖片。僅為了結構和節奏使用可選的概覽圖；當一張巨大的壓縮板會使文字、按鈕細節、卡片結構、間距或排版難以分析時，絕不要依賴它。
- 對於密集的應用程式、儀表板、編輯器、產品介面和複雜區塊，為那些在單一全螢幕圖片中會變得無法閱讀的區域生成獨立的狀態或細節概念：表格、側邊欄、檢查器、模態框、工具欄、圖表、表單、卡片、定價區塊、推薦區塊或媒體模組。
- 如果任何概念截圖因太小、模糊、裁剪、擁擠或模糊而無法用於實作，請在編碼前生成一張新的獨立區塊/狀態/細節截圖。保持相同的調⾊板、排版風格、元件系列、資源處理方式、密度和區塊順序。不要裁剪、分割、縮放或重複使用舊圖像的一小部分作為真理來源。
- 對於遊戲，除了概念圖外，還要規劃一個專用的圖片生成資源傳遞：透明角色/狀態精靈或精靈表、地形/平台瓷磚、可收集物品、危險物品、目標/檢查點物件、道具，以及 2-3 個視差/背景層（當環境具有深度時）。HUD 文字、計分、控制項、物理和碰撞檢測保持程式原生。
拒絕或迭代以下概念：僅針對完整介面請求提供了標題、內容雜亂、通用、重複、規格不足、不可讀、過度裝飾、不符合規格（包含未明確請求或參考中不存在的英雄區塊眉毛文字/前導文字/徽章/藥丸標籤），或無法忠實實作的概念。
設計品質標準
概念應看起來像是資深產品設計師的專業產品模型：
- 一個清晰的創意點或視覺觀點。
- 強烈的第一個視口，具有清晰的提案、產品信號和主要行動。
- 全頁節奏：區塊、狀態、轉場和行動版視圖感覺像是作為一個系統來設計，而不是重複的卡片堆疊或重複的區塊公式。
- 區塊之間的連貫流程：透過共享的間距、調⾊板、字體節奏、媒體處理和微妙的過渡來連接區塊，而不是發明全新的主要 UI 元件。
- 出色的排版：清晰的階層、字級、粗細、行高、標籤處理，以及控制/鉻元素文字，決不退回瀏覽器預設大小。
- 有意識的空白和密度；除非明確請求或已批准設計中有，否則不使用填充卡片、英雄區塊眉毛/前導文字標籤、藥丸、徽章、虛假指標或圖標行。
- 預設更簡潔：使用更少、更強的視覺元素，而不是用插圖、圖標、裝飾性小工具或複雜的 UI 鉻元素來填充頁面。
- 連貫的視覺系統：調⾊板、間距、圓⾓、邊框、陰影、漸層、圖標風格、圖像和元件幾何。
- 當存在圖標時，圖標保真度至關重要。匹配已批准設計的圖標隱喻、描邊粗細、填充樣式、⾓形狀、大小、顏⾊、對齊和間距，而不是用通用的近似圖標替換。
- 顏⾊保真度是強制性的。匹配已批准設計的實際背景、表面、文字、邊框、陰影和強調顏⾊；如果設計使用白色背景，則使用白色，而不是奶油色、象牙⾊、米⾊、暖灰或任何柔化的近白替代。
- 英雄媒體處理必須與已批准設計一致。如果概念中的英雄圖片沒有顏⾊疊加或色調，則實作不得添加。僅使用邊緣淡出、遮罩或背景漸層來將圖片邊緣混合到頁面中；不要用顏⾊疊加洗掉圖片。
- 為標誌、品牌標記、英雄圖像、產品渲染、背景場景、插圖、紋理、海報、頭像、空狀態和遊戲精靈/瓷磚/背景層生成高品質資源。產品/背景資源應完全渲染，具有一致的品牌，並且當文字屬於該資源時包含圖像內文字。
- 有目的的動畫，能澄清階層、揭示狀態或讓產品感覺有觸感。
- 當使用者未提供確切文案時，使用具體、非通用的文案。
預設為乾淨、通透、有品味 (7/10 創造力)：足夠獨特以感覺經過設計，足夠克制以便於建構，且不重複。將「乾淨」理解為經過編輯和清晰易讀，而非空洞或無菌。
視覺方向預設值
當使用者未提供更強烈的藝術指導時，使用這些預設值。根據產品類型進行調整，而不是將每個應用程式都塞入行銷網站的風格。
- 基準：大約 7/10 創造力，低到中密度，寬鬆間距，高實作清晰度，高排版紀律，以及當領域受益於真實視覺時的圖像主導時刻。
- 在生成概念之前，選擇一個連貫的視覺方向：一個主題範例、背景角色、排版角色、英雄或主螢幕架構、區塊/應用程式節奏、2-4 個標誌性元件動機，以及 1-2 個動畫提示。組合使用這些，使設計感覺有目的性，而不是一個通用模板。
- 英雄或第一個視口：保持一個明顯的焦點、一個簡短可讀的標題或主要任務、剋制的輔助文案、一個可見的主要行動，以及足夠的負空間以便在小筆電上運作。不要用統計資料、晶片、徽章、虛擬控制項或競爭的小面板來擠滿開場畫面。
- 頁首簡潔：預設為一個乾淨的品牌標記、必要的導航和一個主要行動或控制項。除非使用者明確要求或產品工作流程需要，否則避免在頁首中使用圖標密集的導航、額外按鈕、搜尋欄、狀態小工具、分段控制項、裝飾性插圖或密集的產品鉻元素。
- 視覺經濟：偏好一兩個高品質的圖像或插圖時刻，勝過許多小型裝飾性視覺元素。僅在圖標有助於澄清導航、控制項或產品意義時才使用。
- 容器紀律：除非概念或產品類型真正需要，否則避免嵌套卡片、圍繞每個區塊的巨大圓⾓包裝、預設的便當/卡片網格以及過度框架化的儀表板。偏好開放式佈局、條帶、軌道、列表、表格、畫布或單一有目的的框架策略。
- 區塊節奏：長頁面應在密度、圖像與文字比例、對齊、比例、空白和視覺節奏上有所變化，同時保持一個連貫的品牌系統。不要在整個頁面中重複相同的中置區塊或左文字/右卡片的公式。
- 區塊連續性：當多個區塊概念需要組合成一個頁面時，使用既有設計系統中的連接組織：排水溝、條帶、對齊、重複的排版、重複出現的媒體框架、顏⾊節奏以及微小的過渡間距變化。除非使用者要求或已批准的概念顯示它們，否則不要發明主要的新輪播、手風琴、定價卡片、儀表板、表單、導航系統、功能網格或其他元件系列。
- 媒體框架：生成的圖像通常應放置在清晰、易於實作的框架中，具有穩定的寬高比、一致的裁剪邏輯、圓⾓、陰影和間距。除非使用者明確要求該方向，否則避免隨機圖像大小或拼貼混亂。
- UI 限制：僅在它們有助於澄清產品時，才允許使用小標籤、實用藥丸、偽系統標記、虛假指標和裝飾性儀表板術語。如果它們只是視覺填充物，請在接受前將其移除。
概念審查模式
僅在使用者要求先產生概念、審查選項或等待批准時使用。
- 生成並展示概念。
- 在使用者批准前進行迭代。
- 使用者仍在審查時，不要實作。
- 一旦批准，將該概念視為有效規範
...
[為翻譯而截斷]