Geruyang/agent-skills-library

前端應用程式建置器

使用此技能來建立精美的前端應用程式、儀表板、遊戲、創意網站、重新設計及其他視覺驅動的 UI。先扮演資深前端設計師的角色，然後再擔任工程師來實作通過批准的設計規格。

核心標準

此技能的兩個優先事項凌駕於其他所有事項之上：

1. 先創建足夠美觀的圖片生成設計：乾淨、通透、獨特、完整、可讀，必要時按區段設計，且預設不重複。
2. 除非批准的設計與瀏覽器實作達到 10/10 完全吻合，否則不要停止。持續修正視覺、互動、響應式、素材與排版上的不匹配，直到 view_image 比較能夠通過設計機構的驗收標準。

嚴格的規則

1. 除非使用者明確選擇不使用，或者任務是現有設計系統內的小型 UI 修正，否則必須使用圖片生成工具建立視覺概念。
2. 在編碼之前，先設計完整的請求表面。對於完整頁面、應用程式、儀表板、遊戲或產品介面來說，僅有頁首或英雄區塊的概念是不夠的。對於多區段網站和長登陸頁，偏好協調的逐區段概念，以及一個可選的總覽來掌握節奏，而非使用一張會遺失細節的高大圖片。對於應用程式、儀表板、遊戲或緊湊的產品表面，請先生成完整的首屏畫面以及任何必要的狀態、響應式或素材概念。
3. 在 Codex 中，預設為多區段網站概念生成一張全新、大型且可讀的圖片截圖作為每個主要區段的設計。如果請求包含 1-10 個區段，預期大約有 1-10 張主要的區段圖片。每當文字、按鈕、卡片結構、排版、間距或顏色難以提取時，就生成額外的區段/細節截圖。不要從舊的全頁圖片中裁剪或放大作為主要參考；請重新生成一張保留相同設計系統的全新獨立區段或細節圖片。
4. 在 Plan 模式下，先生成設計，然後使用 request_user_input 獲得設計批准後，再規劃實作細節。
5. 一旦獲得批准，該概念就是生產設計規格。在實作過程中不得發揮創意：不要重新解釋佈局、可見文字、層級結構、容器模型、樣式、圖像、密度或區段，除非使用者批准或有具體障礙需要這麼做。一般的設計啟發法永遠不能凌駕於已批准的概念之上。
6. 完成的標準是達到設計機構驗收標準的忠實實作：與批准的規格達到 10/10 的擬真度，並產出高品質的程式碼。如果瀏覽器渲染的 UI 會收到設計審查意見，請繼續修正它。
7. 在編碼之前，從已批准的圖像中建立一個小型設計系統：設計權杖、排版、元件系列、變體、間距、圖示處理與容器規則。同時包含內容排版以及工具、編輯器和儀表板的 UI 框架排版。根據該系統進行實作，以確保重複的元素保持一致。
8. 對於新的複雜應用程式 UI，例如儀表板、管理工具、編輯器、資料密集型工具和多面板產品表面，預設使用 React + Vite，除非使用者指定了其他框架、現有儲存庫已指定框架，或者任務明確是單一檔案/靜態交付物。
9. 預設禁止在主標題上方使用英雄區塊的眉毛、前導文字、徽章或藥丸標籤。僅在使用者明確要求或已批准/參考設計中已包含時才使用。
10. 首先在 Browser 外掛程式/內建瀏覽器中驗證。僅在 Browser/IAB 不可用或不可靠時才使用 Playwright Chromium，並說明回退原因。
11. 最終交付受阻，直到你同時使用 view_image 檢視已批准的概念和最新的瀏覽器截圖。此步驟不可跳過，也不能僅透過瀏覽器檢查代替。直接判斷這兩者：這是否忠實地實作了設計機構可驗收的版本？一家優秀、技術高超的設計機構是否會批准這個對已批准設計的具體實作？如果不是，請繼續修正。
12. 在交付前移除臨時的 QA 工件，除非使用者或任務明確要求保留它們。

與其他已安裝技能協作

此技能負責視覺概念化與忠實的前端實作。當應用程式需要前端設計以外的功能時，請使用其他已安裝的技能。提供者的設定不應阻礙圖片生成概念化、靜態 UI 工作或未使用提供者支援行為的設計審查；但提供者支援行為的實作與驗證應透過該功能所屬的已安裝技能進行協調。當其他已安裝技能涵蓋了某項設定時，避免使用預留的設定說明。

對於 AI/模型生成的輸出，當可用時使用 openai-developers:openai-platform-api-key，除非使用者指定其他提供者或明確表示不使用 OpenAI。當該技能可用時，始終使用其憑證流程，而不是虛假金鑰、預留的環境變數或手動的 API 金鑰設定說明。

圖片生成工作流程

閱讀並遵循已安裝的 @imagegen 技能。如需網站專屬的簡報指導，請使用 references/imagegen-website-concepts.md。

在呼叫圖片生成之前：

• 將使用者的具體需求複製到簡報中：產品/頁面目的、受眾、所需區段或狀態、工作流程、提供的文案、導覽標籤、行動呼籲標籤、資料欄位、所需媒體、響應式需求與實作限制。
• 詢問完整的請求表面：完整頁面、應用程式畫面、儀表板、遊戲畫面或協調的區段/狀態集合。如果交付物不僅僅是英雄區塊，請說明概念必須包含後續區段、狀態或響應式延續。如果區段數量已知或暗示，請為每個需要自己概念截圖的區段/狀態命名。
• 重複實作限制：以程式碼為主的應用程式 UI 文字與控制項、完整渲染的產品/背景素材及其自己的文字與品牌形象（在適當情況下）、可分離的素材、可重複使用的元件系列、有意的容器模型、非預設的卡片網格、非發明的英雄區塊眉毛/前導文字/徽章/藥丸，以及實用的 HTML/CSS/元件實作。
• 保護使用者內容、截圖或現有應用程式的資訊架構。不要讓圖片生成發明無關的區段、虛假指標、新的產品聲明、額外儀表板、新導覽或不同的產品故事。
• 對於多區段網站或長登陸頁，預設為每個主要區段提供一張協調的概念圖像。僅在需要時使用可選的總覽來了解結構和節奏；當圖像難以分析文字、按鈕細節、卡片結構、間距或排版時，絕不依賴一張巨大的壓縮圖板。
• 對於密集的應用程式、儀表板、編輯器、產品表面和複雜區段，為那些在單一全螢幕圖像中會變得難以辨識的區域生成單獨的狀態或細節概念：表格、側邊欄、檢查器、模態框、工具列、圖表、表單、卡片、定價區塊、推薦或媒體模組。
• 如果任何概念截圖對於實作來說太小、模糊、被裁切、擁擠或模稜兩可，請在編碼前生成一個全新的獨立區段/狀態/細節截圖。保留相同的色板、排版風格、元件系列、素材處理、密度與區段順序。不要裁切、切片、放大或重複使用舊圖像的一小部分作為事實來源。
• 對於遊戲，除了概念之外，還要規劃一個專用的圖片生成素材流程：透明角色/狀態精靈或精靈表、地形/平台磚塊、收集品、障礙物、目標/檢查點物件、道具，以及 2-3 個視差/背景圖層（當環境具有深度時）。HUD 文字、計分、控制、物理與碰撞偵測仍應以程式碼原生實作。

拒絕或迭代那些僅有頁首而無完整表面請求、雜亂、通用、重複、規格不足、難以辨識、裝飾過度、規格不符（包含未明確要求或參考中未出現的英雄區塊眉毛/前導文字/徽章/藥丸），或無法忠實實作的概念。

設計品質標準

概念看起來應像是由資深產品設計師製作的專業產品模型：

• 一個清晰的創意想法或視覺觀點。
• 強烈的首屏視野，包含明確的價值主張、產品信號與主要行動。
• 全頁節奏：區段、狀態、轉場和行動版檢視感覺像是同一個系統的設計，沒有重複的卡片堆疊或重複的區段公式。
• 連貫的區段間流程：透過共享的間距、色板、排版節奏、媒體處理和微妙的轉場來連接區段，而不是發明主要的新 UI 元件。
• 優秀的排版：清晰的層級結構、字級、字重、行高、標籤處理，以及永遠不會回退到瀏覽器預設大小的控制/框架文字。
• 有意的空白與密度；沒有填充用的卡片、英雄區塊眉毛/前導文字標籤、藥丸、徽章、虛假指標或圖示列，除非在已批准的設計中明確要求或出現。
• 預設更簡潔：使用更少、更強烈的視覺元素，而不是用插圖、圖示、裝飾性小工具或複雜的 UI 框架來填滿頁面。
• 連貫的視覺系統：色板、間距、圓角、邊框、陰影、漸層、圖示風格、圖像與元件幾何。
• 當圖示存在時，圖示的精準度至關重要。匹配已批准設計的圖示隱喻、筆畫粗細、填充樣式、邊角形狀、大小、顏色、對齊與間距，而不是替換為通用的近似圖示。
• 顏色的精準度是強制性的。匹配已批准設計的實際背景、表面、文字、邊框、陰影與強調色；如果設計使用白色背景，則使用白色，而不是奶油色、象牙白、米色、暖灰色或任何淡化的近白色替代品。
• 英雄區塊媒體的處理方式必須與已批准的設計一致。如果概念圖中的英雄圖片沒有顏色疊加或色調，則實作不得添加。僅使用邊緣淡出、遮罩或背景漸層來將圖片邊緣與頁面混合；不要用顏色疊加來沖刷圖片。
• 高品質的生成素材，用於標誌、品牌標記、英雄圖像、產品渲染、背景場景、插圖、紋理、海報、頭像、空狀態以及遊戲精靈/磚塊/背景圖層。產品/背景素材應完全渲染，具有一致的品牌形象，並且當該文字屬於素材時，應包含圖片中的文字。
• 有目的的動畫，用於釐清層級結構、揭示狀態或讓產品感覺更真實。
• 當使用者未提供確切文案時，使用具體、非通用的文案。

預設為乾淨、通透、有品味的 7/10 創意度：足夠獨特以感覺經過設計，足夠克制以便於建構，並且不重複。將「乾淨」解釋為經過編輯且易於閱讀，而不是空洞或無菌。

視覺方向預設值

當使用者未提供更強的藝術指導時，使用這些預設值。根據產品類型進行調整，而不是將每個應用程式強制轉換為行銷網站風格。

• 基準線：大約 7/10 的創意度、低到中密度、寬敞的間距、高實作清晰度、高排版紀律，以及當領域受益於真實視覺效果時，以圖像為主導的時刻。
• 在生成概念之前，選擇一個連貫的視覺方向：一個主題範例、背景角色、排版角色、英雄或首屏架構、區段/應用程式節奏、2-4 個標誌性元件主題，以及 1-2 個動畫提示。致力於這個組合，使設計感覺有目的性，而不是一個通用模板。
• 英雄或首屏視野：保持一個明顯的焦點、一個簡短可讀的標題或主要任務、克制的輔助文案、一個可見的主要行動，以及足夠的負空間以在小型筆記型電腦上運作。不要用統計資料、晶片、徽章、虛假控制項或競爭的小面板來擁擠開場視圖。
• 頁首簡潔：預設為一個乾淨的品牌標記、必要的導覽，以及一個主要行動或控制項。避免在頁首中使用圖示密集的導覽、額外的按鈕、搜尋列、狀態小工具、分段控制項、裝飾性插圖或密集的產品框架，除非使用者明確要求或產品工作流程需要。
• 視覺經濟：偏好一或兩個高品質的圖像或插圖時刻，而不是許多小的裝飾性視覺元素。僅在圖示能釐清導覽、控制項或產品意義時才使用圖示。
• 容器紀律：避免巢狀卡片、每個區段周圍的巨大圓角包裝器、預設的便當/卡片網格，以及過度框架化的儀表板，除非概念或產品類型確實需要它們。偏好開放式佈局、帶狀區域、軌道、列表、表格、畫布或一個單一有目的的框架動作。
• 區段節奏：長頁面應在保持一個連貫品牌系統的同時，變化密度、圖文比例、對齊方式、字級、空白與視覺節奏。不要在整個頁面中重複相同的居中區塊或左文右卡公式。
• 區段連續性：當多個區段概念需要組合成一個頁面時，使用現有設計系統中的連接元素：間距條、帶狀區域、對齊、重複的排版、重複出現的媒體框架、顏色節奏和微小的過渡間距變化。不要發明主要的新輪播、手風琴、定價卡片、儀表板、表單、導覽系統、功能網格或其他元件系列，除非使用者已請求或已接受的概念顯示它們。
• 媒體框架：生成的圖像通常應放置在清晰、易於實作的框架中，具有穩定的寬高比、一致的裁切邏輯、圓角半徑、陰影和間距。避免隨機的圖像大小或拼貼混亂，除非使用者明確要求該方向。
• UI 限制：僅在它們能釐清產品時，才允許使用小標籤、實用藥丸、偽系統標記、虛假指標和裝飾性儀表板術語。如果它們只是視覺填充物，請在接受前移除它們。

概念審查模式

僅在使用者要求先生成概念、審查選項或等待批准時使用。

• 生成並顯示概念。
• 迭代直到使用者批准。
• 在使用者批准之前，不要實施該概念。

簡報結構

接近任何新的圖片生成請求作為一次簡報，而不僅僅是提示詞。結構如下：

1. 任務：你正在建立什麼？一個應用程式、儀表板、遊戲、網站或重新設計？描述其目的、受眾和提供的文案。
2. 範圍：交付物需要多少個區段、狀態或畫面？列出每個需要其自己概念截圖的區段/狀態。
3. 視覺方向：你想要哪種設計風格、排版個性、調色板和素材處理？陳述你的選擇背後的創意理由。
4. 實施限制：哪些技術限制（例如 React、可重用元件）和設計限制（例如無英雄眉毛、卡片網格、虛假指標）適用？
5. 需要避免的事項：明確說明概念不應做什麼（例如，發明無關的區段、添加未經授權的 UI 框架、使其難以實施）。

響應式實作

• 預設為具有典型中斷點的響應式佈局：行動裝置（320px）、平板電腦（768px）、桌上型電腦（1280px+）。
• 從已批准的概念和行動優先設計原則推導出行動版設計。行動版應感覺像是相同設計系統的精簡版本，而不是不同的應用程式。
• 實施時，使用 CSS Grid 和 Flexbox 進行佈局。
• 確保所有可點擊元素（按鈕、連結、輸入）在觸控裝置上具有至少 44x44px 的觸控目標大小。
• 在 Browser 外掛程式/內建瀏覽器中測試所有三個中斷點。

動畫與互動

• 使用 CSS 轉場和動畫進行效能良好的 UI 動畫。
• 對於更複雜的動畫（路徑動畫、手勢、基於滾動的觸發），使用 Framer Motion。
• 預設使用微妙的動畫：懸停效果、焦點指示器、頁面載入淡入、平滑滾動到區段。
• 僅在設計明確呼叫時使用基於滾動的動畫。

資產管理

• 將生成的素材（圖像、圖示、精靈）保存在 public/ 目錄或適當的資產資料夾中。
• 對圖像使用 WebP 格式，並對較舊的瀏覽器提供 PNG/JPEG 回退支援。
• 使用 <picture> 元素或 <img> 上的 srcSet 進行響應式圖像。
• 壓縮素材以獲得最佳效能。

瀏覽器測試

• 使用 Browser 外掛程式進行主要測試。
• 測試佈局、互動性、響應式設計和資產載入。
• 使用 Playwright Chromium 作為回退選項（當 Browser 外掛程式不可用時）。
• 比較已批准的概念與瀏覽器截圖：使用 view_image 並排比較。
• 持續修正差異，直到達到 10/10 的擬真度。

交付清單

在最終交付前，驗證以下事項：

• 瀏覽器 UI 與已批准的概念在佈局、顏色、排版、間距、圖像和互動方面完全匹配。
• 所有區段/狀態/畫面均已實施。
• 響應式設計在行動裝置、平板電腦和桌上型電腦上正常運作。
• 所有互動（懸停、點擊、焦點、導覽）均按預期運作。
• 素材已正確嵌入、最佳化並提供正確格式。
• 動畫順暢且不會降低頁面效能。
• 程式碼已重構、註解得當，並遵循專案的編碼風格。
• 已移除臨時的 QA 工件（例如測試用的控制台日誌、備用程式碼）。
• 最終的瀏覽器截圖已與已批准的概念進行視覺比較。

常見問題排除

概念無法完美實施： 重新檢查概念圖以獲取可操作的細節。必要時，生成新的、更清晰的區段特定概念圖。

使用者不喜歡概念： 與使用者澄清他們具體不喜歡什麼。調整視覺方向並生成新的概念。

響應式困難： 重新構想行動版佈局，而不是強制將桌上型版結構壓縮到小螢幕上。優先考慮內容層級結構並重新安排元素。

動畫問題： 簡化動畫。使用 CSS 轉場而非 JavaScript 實現更簡單的觸發方式。

瀏覽器不一致： 在 Chrome、Firefox 和 Safari 中測試。使用 CSS 前綴和 Normalize.css 以確保一致性。

術語說明

• 英雄區塊眉毛： 位於主標題上方的小標籤或徽章。根據預設規則 #9 禁止使用。
• 概念： 圖片生成工具產生的視覺設計，作為實施的規格。
• 10/10 擬真度： 瀏覽器實施與批准的設計概念之間的精確匹配。
• 設計機構驗收標準： 一個經驗豐富的設計機構會對這個實施感到滿意的品質水準。
• 圖片生成： 此技能使用的 AI 圖像生成工具（例如 Midjourney、DALL-E）來創建視覺概念。