emilkowalski/skills 是設計工程師 Emil Kowalski 開源的技能集,取材自他在 Vercel、Linear 等公司累積的經驗。收錄三個技能——動畫與設計哲學、嚴格的動畫程式碼審查、精準動畫詞彙表——目標是把「什麼樣的緩動曲線、時長、觸發時機才算對」這種難以言傳的判斷,變成 Agent 能照著執行的具體規則。
emilkowalski/skills 的 repo 描述只有一句話:「Skills for Design Engineers.」作者 Emil Kowalski 在 README 裡說明,這些技能取材自他在 Vercel、Linear 等公司累積的經驗。核心問題很直接:AI 生成的介面能動、能跑,但緩動曲線選錯、陰影疊錯、時長抓錯這些小地方會不斷累積,決定一個介面是「令人驚艷」還是「就那樣」。SKILL.md 把這句話寫得更白:Agent 沒有品味(Agents don't have great taste)。
技能的哲學核心有三條:品味是練出來的——透過研究優秀作品、逆向拆解互動、反覆練習養成,不是個人喜好;看不見的細節會疊加——大部分使用者不會意識到的微調,加總起來才是真正的質感;美感是槓桿——在功能同質化的軟體市場,打磨過的動效是少數還能拉開差距的地方。
三個技能分工明確:emil-design-eng 是主要的設計哲學與判斷框架,review-animations 是專門審查動畫程式碼的嚴格審查員,animation-vocabulary 是把模糊描述翻成精準術語的反查詞彙表。
安裝透過官方的 skills CLI 完成,不需要手動 clone 或複製資料夾。在專案根目錄執行:
這條指令會把 emil-design-eng、review-animations、animation-vocabulary 三個技能一次裝好。前兩者(哲學框架、詞彙表)會在合適情境下自動載入;review-animations 的 frontmatter 明確標了 disable-model-invocation: true——也就是說審查技能不會自動觸發,必須明確呼叫。
三個技能各司其職,不重疊。emil-design-eng 提供判斷框架,平常會自動載入;animation-vocabulary 是反查詞典,把你模糊的描述翻成精準術語;review-animations 是嚴格的守門員,frontmatter 寫明 disable-model-invocation: true,預設不觸發,只在你明確要求審查動畫時介入。
disable-model-invocation: true,必須明確呼叫。以下數字直接取自 SKILL.md,是判斷框架裡最常被引用的一組具體規則。
| 元素 | 建議時長 | 建議緩動 |
|---|---|---|
| 按鈕按壓 | 100–160ms |
hover / 顏色變化用 ease |
| Tooltip、popover | 125–200ms |
進場用 ease-out |
| 下拉選單、select | 150–250ms |
螢幕內移動用 ease-in-out |
| Modal、drawer | 200–500ms |
持續運動用 linear |
ease-in——它會延後動作一開始的移動,偏偏那正是使用者盯得最緊的時刻,即使總時長相同也會顯得遲鈍。
review-animations 的 frontmatter 寫著「Default to flagging; approval is earned.」——預設攔下,核准要靠爭取。以下是它逐條檢查的十條標準,以及 SKILL.md 裡標記為「立即攔下」的具體觸發條件。
動畫必須服務於空間一致性、狀態指示、回饋或說明。對高頻出現的元素,「看起來很酷」不算理由。
來源 · review-animations SKILL.md一天觸發 100 次以上的操作(如鍵盤快捷鍵)不該有動畫;偶爾出現的互動可以用標準動畫;稀有事件才容許加驚喜感。
來源 · emil-design-eng SKILL.md進場、離場用 ease-out 或自訂曲線;CSS 內建的 easing 太弱,預期要用自訂的 cubic-bezier。
沒有正當理由,UI 動畫時長不該超過 300 毫秒。這是攔下審查最常見的原因之一。
來源 · review-animations SKILL.mdPopover 該用 transform-origin 從觸發元件展開,絕不從 scale(0) 開始(modal 例外,永遠置中)。
由手勢驅動的動畫必須從目前狀態重新定向,而不是用 keyframes 從頭重播。
來源 · review-animations SKILL.md只能對 transform 跟 opacity 做動畫;動 padding、margin、height、width 這些排版屬性會拖垮效能。
x、y、scale 這些簡寫屬性不會被硬體加速。要用完整的 transform 字串,例如 animate={{ transform: "translateX(100px)" }}。
prefers-reduced-motion 開啟時,保留有助理解的 opacity、顏色轉場,移除位移與位置動畫。手機觸控裝置的 hover 動畫要用 @media (hover: hover) and (pointer: fine) 隔開,避免點擊誤觸發。
刻意的動作放慢(如按住兩秒刪除用 2s linear),系統的即時回應要快(放開時用 200ms ease-out)。
transition: all、進場用 scale(0)、UI 上用 ease-in、鍵盤觸發的動畫、時長超過 300ms、缺少 reduced-motion 支援,以及對排版屬性做動畫。
以下是示意情境:你寫了一個 dropdown 選單的進場動畫,想請 Agent 依這套標準審查。review-animations 不會自動觸發(disable-model-invocation: true),所以你要明確點名它。輸出格式固定兩段:findings 表格,再加分級後的 Block / Approve 判決——這是 SKILL.md 規定的格式,不是自由發揮。
同一段 CSS 換了四個地方,理由各自對應到第 04 節不同的標準編號——不是模糊的「感覺不太好」,而是可以逐條指認、逐條核對的具體規則。這正是三個技能分工的意義:哲學框架定義什麼是對的,審查技能負責把守門檻,而不是讓「品味」停留在只能意會的階段。
review-animations 的 disable-model-invocation: true 是刻意設計。你不點名要求審查,它就不會介入——這代表團隊得養成主動呼叫的習慣,而不是預期它像 lint 一樣自動攔截。
x、y、scale)不會被硬體加速——這類細節容易在審查時被忽略,值得每次都刻意檢查一次。
每個 SKILL.md 都是純 Markdown,可以直接打開改。以下是幾條可行的下一步。
1. 把你團隊的規則加進 review-animations。打開 skills/review-animations/SKILL.md,在十條標準之外補上你產品特有的限制(例如特定元件庫的緩動慣例),連同觸發條件與 Block 理由一起寫進去。
2. 用 animation-vocabulary 統一團隊用語。把設計師常用但不夠精準的說法,對照到詞彙表裡的正式術語,寫進你的設計交接文件,減少「那個彈一下的效果」這類來回確認。
3. 決定審查要不要卡進流程。因為 review-animations 預設不自動觸發,團隊可以自行決定:是每次 PR 手動呼叫,還是寫進 CI 腳本強制執行,兩種都合理,取決於團隊規模。
4. 直接讀官方網站的示範。emilkowal.ski/skill 通常會比 README 有更即時的示範與說明,適合定期回頭確認規則是否更新。
① skills/emil-design-eng/SKILL.md——完整的判斷框架、元件原則與效能規則。
② skills/review-animations/SKILL.md——十條硬性標準與立即攔下的觸發條件。
③ skills/animation-vocabulary/SKILL.md——完整動畫詞彙分類。
④ emilkowal.ski/skill——作者的官方介紹頁面。