Frontend autoral
使用繁體中文（zh-TW）回覆，直接了當。交付一個在螢幕上正常運作並經確認的介面，而非草稿。
此技能解決的問題：AI 生成的網站因為源自模糊的計畫，缺乏真實內容，且沒有人檢查結果，所以看起來都很相似。在這裡，每個專案在撰寫程式碼之前，都會先根據主題發展出一個獨特的藝術方向；它會在真實瀏覽器中進行測量，並且只有在看到實際渲染結果並與陳腔濫調清單進行比對後才會交付。
這裡整合了四個來源，且已協調一致：
- taste-skill (leonxlnx)：主題盤點、論證、從 247 個獲獎網站中抽選經過研究的構圖、概念陳述、活的互動元素、來自開放典藏的圖片、lint 檢查器與真實瀏覽器檢查器、分回合的評論與分數上限。工具位於
vendor/taste-skill/。 - Emil Kowalski (emilkowalski/skills)：動畫決策、曲線、持續時間、物理效果、手機上的應用程式感、最差情況資料、以「之前/之後」表格進行的審查。
- UX 法則 (lawsofux.com)：30 條法則轉化為可在螢幕上檢查的問題。
- logo-design (kaankiziltug)：標誌、應用程式圖示與 favicon 的設計流程，包含 SVG 審計與網頁套件匯出。工具位於
vendor/logo-design/。
當來源有衝突時： 當前請求優先於 "Igor 的品味" 和 references/cliches.md，後者優先於此檔案，此檔案優先於 references/movimento.md（關於動畫的部分），後者優先於 vendor/ 中的英文參考資料。特別注意：此處的動畫僅具功能性，沒有動畫元素的配額，也沒有每個區塊的進場動畫；滾動場景的抽選僅在使用者要求時才加入。
<skill> 在指令中代表此技能的資料夾。這些腳本需要 Node 22+（lint 需要 18+）和一個 Chrome、Edge 或 Chromium 瀏覽器（Playwright 自帶的即可；scripts/achar-chrome.mjs 會自動尋找）。圖示相關腳本需要 Python 3（在 Windows 上，使用 python）。
使用時機
- 建立網站、登陸頁面、作品集、企業頁面、應用程式畫面、儀表板、表單。
- 重新設計或「美化」現有介面。
- 審查畫面的 UI/UX：層級結構、無障礙性、狀態、文案、響應式設計、動畫。
- 為產品建立具有識別度（不僅是功能性）的元件。
- 為專案建立標誌、符號、應用程式圖示或 favicon，或為現有標誌生成變體。
不適用於：GitHub 的 README 與個人資料圖片（使用 readme-designer 技能）、圖表與資料視覺化（使用 dataviz 技能）、簡報與文件。
選擇模式
- 建立頁面（網站、登陸頁面、作品集；新專案或完整重新設計）：執行完整流程。
- 應用程式畫面（儀表板、管理後台、設定、收件匣、含篩選器的列表、編輯器）：開始前請先完整閱讀
vendor/taste-skill/references/app-screens.md。它有自己的流程、抽選方式（draw.mjs --app --kind <類型>）和規則（離散邊框、小標籤和重複面板在此是正常的；漸層、發光、彩色方塊中的圖示、彩虹圖表以及虛構的虛榮數字則不適用）。使用下方流程，但在檢查器階段加上--app；活的互動元素和圖片基底不適用。展示應用程式的產品頁面屬於「頁面」類別；頁面內的應用程式片段則遵循應用程式規則，並帶有data-ui屬性。 - 演進（已有視覺系統、
DESIGN.md、BRAND.md、token、Tailwind 主題、元件庫）：以現有方向為主。開始前先閱讀，重複使用 token 和元件，僅在使用者要求時才提出變更識別。跳過抽選（或使用--keep palette,type僅抽取構圖），但需通過檢查器和陳腔濫調清單。 - 審查（稽核、「這裡哪裡不好？」、「檢查動畫」）：僅執行步驟 1 和 5，針對當前狀態。發現的問題以 位置 | 之前 | 之後 | 原因 的表格呈現，並按嚴重性分組，無須前言（
references/revisao.md第 11 節）。 - 局部調整（「更大膽一點」、「更平靜一點」、「更換字體」、「讓這個動起來」）：僅更改要求的項目，維持現有方向。請參閱
references/oficio.md中的「調整」部分，動畫部分請參閱references/movimento.md。 - 圖示或標誌（標誌、品牌標記、應用程式圖示、favicon）：請參閱
references/icones.md。在每個網站或應用程式專案中，該文件中的輕量模式會在步驟 4 中執行，確保專案帶有自訂圖示。
流程
每個步驟只有在其完成標準滿足後才算完成。
-
理解主題。 閱讀請求與現有程式碼。為自己回答以下問題，每個問題一行：產品是什麼、目標受眾是誰、主要任務是什麼、這是頁面還是應用程式畫面、有哪些真實內容存在（文字、圖片、資料、標誌、品牌），以及實際存在哪些圖片。完成 8 到 12 項只有這個客戶才有的獨特清單（
references/direcao.md第 1 節）。如果缺少核心要素（產品是什麼或目標受眾是誰），則進行一輪最多 4 個問題的批次提問。如果只缺少個人品味，則自行決定並告知您的決定。- 完成標準：產品、受眾、任務、類型、獨特清單和圖片清單都已清楚，且任何缺口都已獲得答案或已記錄決定。
-
在撰寫任何 CSS 之前，先撰寫藝術方向，儲存在專案根目錄的
DESIGN.md中（範本位於assets/DESIGN.template.md；只需一個檔案，放在回覆頂部）。方法見references/direcao.md：- 論證：將頁面視為帶有證據的主張，每個區塊一個；沒有主張的區塊則移除；
- 構圖抽選（
vendor/taste-skill/scripts/draw.mjs ... --options 3），建議用於頁面：選擇能體現獨特清單中某個項目的選項，而不是最熟悉的那個，並根據主題和陳腔濫調清單過濾色板與類型； - 一句話的場景概念，以及「看起來像 / 不像」的清單；
- 概念陳述（「在此頁面中，[獨特清單中的某物] 轉變為 [某種資源]」）、競爭者測試以及活的互動元素（基於概念並使用真實內容的互動）；
- 簽名元素；4 到 6 種具命名角色和對比度的顏色；1 或 2 個字體家族，搭配最多 5 種大小的比例系統；具有等距邊距、節奏和形狀規則的網格；動畫規則；圖片來源；圖示的靈感來源；
- 每個區塊的 ASCII 線框圖，相鄰區塊形狀不同。
然後執行互換測試：「如果我更改產品名稱，這個方向是否適用於任何競爭對手？」如果是，則進行修改並說明更改了什麼。對照
references/cliches.md進行檢查，包括第 11 節（移除陳腔濫調不能留下空白）。- 完成標準：每個選擇都有與產品、受眾或內容相關的理由；概念陳述通過競爭者測試；沒有任何項目在沒有正當理由的情況下落入陳腔濫調。
-
在撰寫標記語言之前，先撰寫純文字內容腳本，使用
references/copy.md：在各種螢幕寬度下都能容納在兩行內的標題（請自行計算）、緊接在下的支持性陳述、一個含有動詞和受詞的主要行動按鈕，以及每個區塊的完整內容。如果缺少證據（數字、見證、客戶、評價），請使用[此處為真實見證]之類的明顯標記，而不是虛構內容；如果只缺少內容細節（菜名、房型名稱），則使用合理的範例並列出以供確認。- 完成標準：沒有任何文字可能出現在其他公司的網站上；沒有虛構的證據；範例已列出。
-
建構，不包含動畫。 在心中關閉動畫：需要動畫才能看起來完整的頁面，實際上並不完整。順序：token（顏色、字體、間距、形狀、曲線）、依照桌機和手機設計的 Hero 區塊、每個區塊根據其線框圖呈現概念，直到價格、常見問題和頁尾、圖片（
references/imagens.md：自有、生成、來自開放典藏並使用assets.mjs的圖片、根據主題繪製）、活的互動元素、框架（等距邊距、每個區塊都有標題、無空白片段）、狀態與語意、favicon 與圖示（references/icones.md，輕量模式）。遵循references/oficio.md、references/ux.md和references/leis-ux.md。vendor/taste-skill/assets/base.css是可選的基礎樣式。- 使用專案既有的技術棧。沒有功能性理由時，不引入新的視覺依賴。
- 完成標準：頁面運行無控制台錯誤、在手機上無水平滾動、所有相關狀態都存在（hover、focus-visible、active、disabled、loading、錯誤、空白）、最差情況資料已測試（
references/ux.md第 9 節），且已放置自訂圖示。
-
測量、檢查、修正。 運行檢查器：
node <skill>/scripts/inspecionar.mjs <url-或-index.html> --src <程式碼資料夾>（應用程式畫面加上--app）。它會執行 lint 檢查並在 1440、768 和 390 像素寬度下進行檢查，並將螢幕截圖儲存在.taste-skill/inspect/中。修正所有 FAIL。然後打開所有螢幕截圖，使用references/revisao.md進行評論：AI 測試、15 輪檢查、帶有分數上限的評分、以回合格式撰寫評論。修正最嚴重的 3 個問題，重新測量並再次檢查；最多 3 輪。- 完成標準：0 個 FAIL、平均分數 ≥ 8、無標準低於 7、問題清單為空。如果無法達到，請說明遺留問題和實際分數。
-
加入動畫，僅具功能。 現在加入動畫，由
references/movimento.md決定：頻率（鍵盤操作和整天可見的內容不應動畫化）、目的、曲線（強ease-out，永遠不要用ease-in）、持續時間（介面中 < 300 毫秒）、按壓效果（scale(0.97)）、從觸發點開始的變形原點、僅限滑鼠的 hover 效果、prefers-reduced-motion。每頁最多一個編排好的動畫時刻，通常是活的互動元素或簽名元素。再次運行檢查器，並在螢幕截圖中確認沒有任何元素消失。- 完成標準：每個動畫都能回答「為了什麼？」，且檢查器仍維持 0 個 FAIL。
-
確認並報告。 最終檢查清單與報告，格式見
references/revisao.md第 9 和 10 節。
如果無法渲染（沒有瀏覽器也無法安裝任何瀏覽器）？只運行 lint 檢查，在報告中說明這一點，並透過對照檢查清單閱讀程式碼來進行審查。不要聲稱已在螢幕上檢查過。
單螢幕設計
詳細資訊請見 references/oficio.md、references/cliches.md 和 references/leis-ux.md。
- 每個視覺決策都必須有理由，與產品、品牌、內容或使用方式相關。在添加任何元素之前，問問它是否改善了理解、功能、美學或體驗。如果沒有改善，就不要加入。
- 身份源於主題，絕非潮流。未來感、科技感或極簡風格不是預設值；它們只應在主題需要時出現。極簡主義不等於缺乏個性。
- 視覺風格獨特，互動機制常規（Jakob 法則）。大膽的設計體現在字體、顏色、圖片和構圖上；選單、連結、按鈕和表單則應與任何網站相同。
- 大膽只放在一個地方，也就是概念簽名元素。其餘部分保持嚴謹。在交付前，移除一個裝飾。但移除裝飾不等於留下空白：空間應用於放大比例、完整內容、主題相關圖片或色塊。
- 構圖跟隨內容。 每個區塊根據其展示內容選擇形狀：列表、序列、比較、大圖、引言、表格。相鄰區塊不重複形狀。並非一切都是卡片，並非一切都是置中，並非一切都是 3 欄網格。
- 層級優先於對稱。 每螢幕一個主要元素；2 或 3 種尺寸即可完成任務，總共最多 5 種；標題最多兩行。網格內允許不對稱，外部邊距始終相等。
- 顏色要有角色。 一個背景色、一個文字色、1 或 2 種帶色調的中性色、用於 1 到 3 處的強調色（Von Restorff 效應）。表面透過色調層級區分，靜止狀態下無漸層、發光、模糊、玻璃效果或陰影。
- 字體就是聲音。 根據產品特性選擇 1 或 2 個字體家族，正文尺寸可讀（≥ 16 像素，每行 45 到 75 個字符），使用全強度文字色。
- 圖片要有內容。 專案實際圖片、生成圖片、來自開放典藏並附帶出處的圖片，或根據主題繪製的圖片；一張主圖勝過六張小圖；永遠不要使用灰色佔位符或通用庫存照片。
- 動畫僅具功能，快速、可中斷、使用
ease-out並從正確原點開始。始終尊重prefers-reduced-motion。 - 無障礙性不可妥協：AA 對比度、可見的焦點、鍵盤導航、正確的語意、內容圖片的
alt屬性、點擊目標 ≥ 44 像素、允許縮放。
Igor 的品味
這是起點，不是食譜。當前請求永遠優先。
- 主題隨每個專案而變。未經要求，絕不重複使用先前專案的色板、字體、主題或文案。（taste-skill 的抽選會記住之前的專案，有助於避免重複。）
- 偏好明確且執行到位的主題，貫穿整個作品，而非微弱的裝飾。
- 一致性高於一切：一個「原始」的區塊放在一系列精心設計的區塊中會顯得很突兀。如果某個區塊不協調，請以相同標準重新設計。
- 動畫要微妙。禁止物件橫跨螢幕移動。
- 文案要自然，避免勉強的標語、免責聲明或未經要求的頁尾。
- 「改進」一個區塊是在維持內容的前提下重新設計視覺效果，而非移除內容。
- 當他否決一個元素時，只移除那個元素。不要重新解釋其餘部分。
陷阱
- 第一個想到的就是陳腔濫調。 置中的 Hero 加上標題、副標題、兩個按鈕和漸層；三個帶有彩色方塊圖示的卡片；數字區塊；見證區塊。如果第一個想法來得太快，它很可能是預設模式。回去重新審視獨特清單。
- 為了避免一個陳腔濫調而落入另一個。 逃離紫色，改用奶油色背景 + 襯線字體 + 陶土色，或黑色 + 螢光綠，只是換了一種 AI 的預設模式。請參閱
references/cliches.md中的「五種預設視覺風格」。 - 乾淨但空洞的頁面。 沒有裝飾也沒有內容的頁面，會比充滿陳腔濫調的頁面更糟糕。完整的內容、大字體、真實的圖片。
- 類別層級的想法。 「麵包」適用於任何麵包店。如果概念陳述對競爭對手也適用，請回去重新審視獨特清單。
- 為填充而虛構的內容。 無來源的數字、虛構客戶的標誌、虛假的見證、隨機的大頭貼、通用的儀表板模型。請使用標記或直接刪除該區塊。
- 三行的標題。