Taste Skill 的作用是為 AI 前端生成增加佈局、字體、密度和互動上的美感約束。安裝它時，最重要的是讓客戶端能發現 SKILL.md，並讓專案任務真正觸發該 Skill，而不是只把檔案下載到任意目錄。
安裝前先讀 SKILL.md
先查看 Skill 的名稱、說明、適用任務和引用資源。把它當作工作流程說明，不是可以隨意複製到頁面裡的提示字。完整背景可看 Taste Skill 怎麼用。
放置位置的原則
Claude Code、Codex 與不同桌面/CLI 版本的 Skills 發現目錄可能不同，因此應以你正在使用的客戶端文件和設定為準。一般有兩種範圍：
- 使用者級目錄：多個項目都能重複使用，適合通用設計限制。
- 專案級目錄：只對目前倉庫生效，適合品牌、元件庫和設計系統相關限制。
複製時保留完整 Skill 目錄結構，包括 SKILL.md 和它引用的 references、模板或腳本。只複製一個 Markdown 文件，可能導致引用資源找不到。
如何驗證已被發現
重新啟動或重新開啟用戶端後，檢查其可用 Skills 清單、啟動日誌或任務說明。接著用一個小頁面測試，例如“為已有表單調整資訊層級和間距”，並明確要求遵循 Taste Skill。若輸出仍完全忽略設計約束，先檢查名稱、目錄和前置條件，而不是立即擴大提示詞。
一個安全的迭代方式
- 用現有頁面或小元件做試驗，不直接重寫整站 UI。
- 先約束一個維度，例如排版密度或按鈕層級。
- 透過截圖、設計規格或現有組件驗收結果。
- 確認穩定後再擴展到動畫、色彩和響應式細節。
Taste Skill 不能取代產品需求、無障礙需求和真實設計審核。它負責減少“模板感”，不保證頁面自動符合品牌或業務目標。
若你準備好要寫自己的團隊 Skill，可結合 Codex Skills 工作流程寫法整理可重複使用的觸發條件和驗收清單。
總結
安裝 Taste Skill 的關鍵是正確目錄、完整資源和可驗證呼叫。先小範圍試用，再把穩定的設計約束沉澱到專案級工作流程，效果通常更可靠。
安裝前檢查清單
在複製之前，確認該 Skill 的來源可信賴、許可證符合專案要求、引用資源都能讀取。一個可用的 Skill 至少應有清晰的名稱與用途說明；如果它要求圖片、模板或腳本，目錄結構必須一起保留。不要只把 README 內容複製到專案裡，就假設客戶端能發現它。
對於使用者級安裝，適用於「所有前端專案都希望減少模板感」的一般限制；對於專案級安裝，適合綁定已有設計系統、顏色 token、元件目錄和驗收方式。團隊專案優先使用專案級版本，並透過 Git 評審變更。
讓任務真正觸發 Taste Skill
Skill 被發現不代表每個任務都會使用它。寫入任務時應同時給予頁面目標、保留範圍和視覺約束，例如「保留現有元件 API，只調整資訊層級、間距和行動端密度」。如果只說“做得好看”，模型缺少可驗證標準，任何 Skill 都難以穩定發揮。
還可以把驗收條件寫入任務：
- 不改變關鍵互動和表單欄位；
- 標題、內文、輔助資訊的層級可區分；
- 窄螢幕下不出現橫向溢出；
- 顏色對比、焦點狀態和按鈕文字仍可存取；
- 不新增未經審查的大型依賴。
一個前端改造範例
假設頁面有標題、兩段說明、一個搜尋框和一組結果卡。第一輪只要求調整閱讀順序和留白；第二輪再處理卡片密度和狀態色；第三輪檢查 320px 到桌面寬度。每輪只改一小塊，並使用實際內容而不是空白佔位符截圖驗收。
這種做法比「把整頁重做成進階設計」更適合生產專案：差異小、回滾容易，也能看出 Taste Skill 的規則是否與現有元件庫衝突。
常見失敗原因
| 現象 | 可能原因 | 處理方式 |
|---|---|---|
| 客戶端看不到 Skill | 目錄或元資料不符合發現規則 | 核對客戶端設定和 SKILL.md |
| 輸出變化很小 | 任務沒有觸發條件或約束不明確 | 明確要求採用該 Skill 與驗收項 |
| 輸出破壞元件 | Skill 與專案規格衝突 | 增加「保留 API/僅改樣式」限制 |
| 每次風格不同 | 缺少設計 token 和參考 | 在專案級資源中補充規範 |
FAQ：Taste Skill 能取代設計師嗎？
不能。它可以讓 AI 更遵守美感和版式約束，但品牌策略、內容優先順序、無障礙和使用者研究仍需由團隊判斷。
FAQ：可以跟其他 Skill 一起用嗎？
可以，但職責要分開：一個負責設計約束，一個負責測試、可訪問性或框架規格。避免多個 Skill 同時重寫同一層規則。