🌿哪些 UI／UX Agent Skills 真正值得用？

📝 關於這份選用指南

GitHub Stars 查核時間為 2026 年 9 月 13 日（Asia/Taipei），數字會持續變動。

本文收錄 30 個來源，包含單一 Skill、repository、Registry、上游規則、安裝 wrapper 與可執行設計工具。Stars 採所屬 GitHub repository 的數字；合集裡的單一 Skill 沒有獨立 Stars，所以它只能代表社群規模，不能直接當成單一 Skill 的品質分數。

文中的推薦順序依 UI／UX 直接相關性、工作流完整度、驗證能力、跨工具相容性、維護狀態與授權清楚度所做的編輯判斷，不是實驗室 benchmark，也不是把不同類型工具硬算成一個總分。

前言：AI 會寫 React，不代表它會設計

如果你曾經叫 AI 幫你做 Landing Page，應該看過一種很熟悉的畫面：紫色漸層、三張一樣大的圓角卡片、一顆發光按鈕，再配上一句「重新定義你的工作流程」。

功能通常能跑，版面也不能說壞，但就是有一股濃濃的 AI 樣板味。

那種感覺很像建商附贈的樣品屋。沙發、茶几、盆栽都有，卻看不出究竟是誰要住在裡面。

問題不是模型不會 CSS，而是它不知道你的品牌個性、資訊層級、使用者任務與工程限制。沒有脈絡時，它只好回到訓練資料裡最常見、最安全，也最容易撞臉的答案。

UI／UX Agent Skills 的價值就在這裡。

它們不會讓 AI 瞬間長出一顆真正的設計師大腦，比較像是在動工前，先塞給它一份設計總監的方向、UX Researcher 的提醒、Design System 的合約、前端工程師的 checklist，以及一張「拜託不要再做紫色卡片牆」的警告紙條。

這篇文章不只找「最會做漂亮網頁」的 Skill，而是把完整產品流程拆開來看：

UX Research
    ↓
Information Architecture
    ↓
Visual Direction
    ↓
Design System
    ↓
Framework Implementation
    ↓
Motion
    ↓
Accessibility / UX Review
    ↓
Screenshot Comparison

你真正需要的通常不是一個包辦一切的神奇 Prompt，而是讓正確的 Skill 在正確階段接手。

我怎麼判斷「實用」？Stars 只算其中一小部分

這份指南主要看六個面向：

我沒有替這六項設定看似精密的百分比權重。不同專案真正重要的條件不一樣：品牌頁會更看重視覺方向，企業產品會更在意驗證、維護與授權，Screenshot Workflow 則需要可執行的影像比較能力。因此，後面的順序是同一功能情境內的推薦順序，不是跨類型的全球總榜。

閱讀時也要先分清楚它們到底是什麼：

這些東西能在同一條 UI 工作流裡合作，卻不代表它們是同一種產品。

因此，176,029 Stars 的 anthropics/skills 不會自動在所有分類第一；它的 frontend-design 很強，但 Stars 是整個 Anthropic Skills repository 的人氣。

同樣地，只有 10 Stars 的 hueyexe/frontend-agent-skills 也不等於沒價值。它對 UX Research、Information Architecture、Forms 與 UX Writing 的拆解，反而補上許多高星「漂亮前端」Skill 沒處理的真正 UX 問題。

Stars 很適合拿來找線索，不適合拿來替你做架構決策。

沒時間看完？先從這份情境推薦開始

如果只想記一件事：生成用的 Skill 與審查用的 Skill 要分開。 同一個 Agent 一邊愛上自己的設計、一邊負責審查，通常會像自己改自己的考卷一樣寬容。

表中的「第一選擇」只代表該功能情境最值得先評估，不代表它在授權、成本與資料治理上永遠最安全。尤其是標示缺少 LICENSE、混合授權或服務條款另計的項目，正式採用前仍要做個別審查。

先決定責任分工，再挑選個別 Skill

多裝 Skill 最常見的失敗，不只是 context window 不夠，而是責任不清楚。

frontend-design 可能要求大膽的排版，taste-skill 又根據密度旋鈕做另一套判斷，premium-frontend-ui 接著堅持 Hero 必須有 Preloader 和 Parallax。三位設計總監同時站在工地上，Agent 最後往往只會用最多字的規則蓋掉其他人。

挑選前先守住五條原則：

1. 每個階段只指定一個決策主責（Decision Owner）。 其他 Skills 只能提供參考或 Review。
2. 生成與審查分開。 先讓 Creator 完成，再用新的 context 或 Reviewer 檢查。
3. 上游與鏡像只留一份。 Anthropic 與 JetBrains snapshot、Vercel rules 與 wrapper 不要重複載入。
4. Framework Skill 晚一點進場。 先定方向與 tokens，再讓 shadcn、Vue 或 Angular 負責實作。
5. 把最後決策寫進 DESIGN.md。 不要讓每一次對話重新投票決定品牌顏色。

視覺設計與 Anti-Slop：推薦順序

首選：Anthropic frontend-design

這份官方 Skill 最值得學的不是「不要用 Inter」，而是要求 Agent 先從產品主題、受眾與任務建立設計方向。Typography、palette、layout、motion 與 copy 都必須服務 brief，而不是從固定模板裡抽卡。

它還會主動辨識近年 AI 常見套路：暖米色＋高對比 serif、酸綠黑底、報紙細線、相同圓角 SaaS 卡片、ALL CAPS eyebrow labels 等。這些風格不是原罪，問題是它們是否真的符合題目。

定位：Design Director。 適合新頁面或大改版的第一階段。frontend-design 自己的 LICENSE.txt 是 Apache-2.0，雖然 Anthropic 根 repository 採分技能授權。

第二選擇：ui-ux-pro-max-skill

它是最全面的設計智慧資料庫：79 種風格、192 組產品配色與推理設定、74 組字型搭配、119 條 UX 指引、105 種圖示、17 組 GSAP presets、25 種圖表與 22 個技術棧。

比起 frontend-design 偏設計方向，它更像一位同時熟悉產品類型、UX patterns、Accessibility 與前端 stack 的顧問。

定位：Generalist UI／UX Architect。 如果只能選一套，就選它。

第三選擇：taste-skill

它用三個旋鈕控制 DESIGN_VARIANCE、MOTION_INTENSITY 與 VISUAL_DENSITY。這個模型簡單但非常實用，因為政府服務、金融 Dashboard 與創意 Portfolio 本來就不該共用同一種「好看」。

定位：Art Director／Anti-Slop Critic。 適合品牌頁、Landing Page、Portfolio 與 redesign。

第四選擇：Microsoft frontend-design-review 的 Creative Mode

它不只有 Review Mode，也能從 purpose、tone、constraints 與 differentiation 建立創意前端。視覺規則帶有 Anthropic frontend-design 的影響，但多了 design system workflow 與品質分級。

定位：能創作也能審查的 Senior Reviewer。 若你已經用 Anthropic 原版做視覺方向，就把 Microsoft 留到最後 Review，不必兩套同時發號施令。

第五選擇：premium-frontend-ui

它走 Editorial Brutalism、Organic Fluidity、Cyber 與 Cinematic Pacing，擅長 Full-screen Hero、Parallax、磁吸按鈕、Custom Cursor 與 Scroll Storytelling。

定位：Immersive Marketing Specialist。 適合活動官網與作品集，不適合每一個後台表單。不是每扇門都需要在使用者靠近時旋轉三圈才打開。

第六選擇：ui-ux-design

它把 Landing Page、Dashboard、Pricing、Slide、Email 與 Report 等工件，拆成 Typography、OKLCH 色彩、非對稱布局、圖表、Pre-flight 與 Anti-Slop 模組。MIT 授權清楚，但目前 0 Stars，社群驗證有限。

定位：小型模組化設計工作流。 適合研究與試作，不宜因為規則完整就跳過輸出驗證。

Design System、Tokens 與元件實作：推薦順序

首選：DESIGN.md

google-labs-code/design.md 用 YAML front matter 保存 colors、typography、spacing、rounded 與 component tokens，再用 Markdown 解釋設計理由。CLI 可 lint、diff、驗證 token references 與部分 WCAG contrast。

它不負責替你發明漂亮畫面，而是防止第一個 Agent 做 8px 圓角、第二個改 24px、第三個又加玻璃效果。多人、多頁面、多代理協作時，這種可版控的設計合約非常重要。

第二選擇：官方 shadcn Skill

大家熟悉 shadcn/ui 元件庫，卻容易忽略官方 repository 已經有正式 skills/shadcn/SKILL.md。它會先讀取 components.json 與專案 context，要求 Agent 優先搜尋 registry、使用現有元件、compose instead of reinvent，並遵守 semantic colors、variants、forms、dark mode 與 component structure。

它不是通用美術指導，而是 shadcn/ui 的官方實作守門員。若專案根本不用 shadcn，就不用為了 123,663 Stars 硬裝。

第三選擇：ux-ui-agent-skills

這套內容很豪華：DTCG tokens、元件規格、138 種設計系統、跨框架 adapters、WCAG 2.2、Nielsen heuristics、UX writing，以及 contrast、axe、keyboard、focus trap、RTL 與 overflow 等驗證腳本。

問題在授權文件：README 與 package.json 宣告 MIT，repository 卻沒有完整 LICENSE 檔，GitHub API 因而回傳 license: null。作者意圖很明顯，但公司正式採用前，最好請作者把法律文件補完整。

第四選擇：frontend-ui-engineering

它位於 addyosmani/agent-skills，強項是讓 Design System 真的落到 production code：元件架構、狀態管理、響應式、語意 HTML、效能、keyboard 與 WCAG。它會追問 loading、error、empty、dense 等狀態，而不是只交一張理想世界的 happy-path 畫面。

第五選擇：antfu-design 與 UnoCSS 生態

antfu/skills 裡的 antfu-design 對 UnoCSS、semantic tokens 與 Anthony Fu 工具介面的設計偏好很有價值。它適合 Vue／Nuxt／Vite 團隊，不是跨框架設計系統的通用第一選擇。

UX、Accessibility 與 Design Review：推薦順序

首選：Vercel Web Interface Guidelines

這是一份 living guidelines，涵蓋鍵盤、focus、touch target、form、navigation、URL state、animation、typography、content、dark mode、i18n、hydration 與 accessibility。它的角色不是發明視覺，而是對已完成的 UI 做 100+ 條規則審查。

有兩個 repository 會出現在本文：

• vercel-labs/web-interface-guidelines：規則的上游來源。
• vercel-labs/agent-skills → web-design-guidelines：安裝用 wrapper，每次 Review 會抓取最新上游規則。

它們是同一套能力的 source 與 Skill 包裝，不要當成兩個 Reviewer 重複執行。

第二選擇：Microsoft frontend-design-review

它有 Design Review 與 Creative Frontend Design 兩種模式。Review 依 Frictionless → Quality Craft → Trustworthy 三個支柱檢查 user task、action hierarchy、Design System、Figma 差異、tokens、Accessibility、Responsive 與 Theme，再把問題分成 blocking、major、minor。

Vercel 適合做規則型 lint，Microsoft 更像最後一輪整體設計評審，兩者很適合前後串接。

第三選擇：frontend-ui-engineering

它同時具備生成與驗證思維，對 component architecture、states、keyboard、responsive、console errors 與 axe-core 都有具體要求。它比純 Reviewer 更接近實作者，所以適合放在 implementation 階段常駐。

第四選擇：hueyexe/frontend-agent-skills

Stars 只有 10，但它把 UX 拆成九個專業領域：Accessibility、Design Systems、Forms／Checkout、Information Architecture、Interaction Patterns、Visual Composition、UX Research、Usability Foundations 與 UX Writing。

真正 UX 的問題往往不是陰影夠不夠漂亮，而是使用者為什麼找不到功能、表單為什麼一直填錯、Empty State 有沒有下一步。這套 Skill 的方向很對，現階段則仍屬觀察級，使用時要自行驗證內容來源與效果。

第五選擇：ux-ui-agent-skills

它的 WCAG、Nielsen heuristics 與 runnable gates 很完整；之所以列在後面，不是功能不足，而是授權文件不完整，以及大套件載入後可能佔用較多 Agent context。挑需要的 Skill 使用，比整包常駐有效。

Motion Design：推薦順序

首選：LottieFiles motion-design-skill

這是清單中最專注、重複性最低的一套。它從 emotional target、motion personality、timing、easing、choreography、micro-interaction、state feedback 到 brand motion 都有規則，並把 Disney animation principles 轉成 UI 可用的判斷方式。

它支援 CSS、Framer Motion、GSAP、Lottie、Spring 與其他 animation systems，也把 reduced motion 和 performance 放進流程。

taste-skill 告訴你「不要動得像廉價模板」，LottieFiles 則進一步回答「那到底要怎麼動，使用者才看得懂又感覺自然」。

第二選擇：premium-frontend-ui

適合 Scroll Storytelling、Hero Sequence、Parallax 與有舞台感的品牌體驗。動效野心較大，應由 LottieFiles 的 timing 與 choreography 原則收斂。

第三選擇：taste-skill

MOTION_INTENSITY 很適合在設計初期控制整體動態密度，但它不是完整 animation specification。

第四選擇：Vercel Web Interface Guidelines

它不是 Motion Creator，而是 Motion Safety Reviewer：檢查 prefers-reduced-motion、interruptible animation、compositor-friendly properties、transform origin、避免 transition: all 等問題。最後一定值得跑。

AI Design Environment、Design-to-Code 與 Screenshot Workflow：推薦順序

首選：nexu-io/open-design

在這個類別裡，OpenDesign 提供的範圍最完整。它不是單一 Skill，而是一個 local-first 的 AI Design 工作環境，能產出 Web、Desktop、Mobile prototype、Dashboard、Deck、Image、Video，並輸出 HTML、PDF、PPTX、MP4。

官方目前說明它能自動偵測 26 種 local CLI、載入 100+ functional skills 與 151 個 Design Systems，也能使用 BYOK 或 OpenAI-compatible endpoint。你的 Coding Agent 成為設計引擎，DESIGN.md 則成為品牌合約。

Repository 採 Apache-2.0；內含的第三方 Skills 與 templates 若有自己的 LICENSE，仍保留原授權。官方 Cloud 模型服務則是另一筆可能的付費成本。

第二選擇：google-labs-code/stitch-skills

若團隊已在用 Google Stitch，它能把 generate design、萃取 DESIGN.md、下載 HTML、轉 React／Angular／Vue／React Native 與截圖驗證串成端到端流程。

它列在第二選擇不是功能比較差，而是依賴 Stitch 生態；不使用 Stitch 的人，實用度會直接下降。

第三選擇：wandb/openui

OpenUI 能用文字或圖片描述介面、即時預覽，再轉成 HTML、React、Svelte 或 Web Components。它支援 OpenAI、Groq、Gemini、Anthropic、LiteLLM，也能接 Ollama 或 OpenAI-compatible 本機模型。

它的強項是開放、自架與模型選擇自由；缺點是產品完整度與設計治理不如 OpenDesign 的整合式工作台。

第四選擇：pascalorg/skills

這組 Skill 很適合把 Screenshot 工作拆成可驗證流程：

image-analysis
    ↓
image-to-text
    ↓
web-design
    ↓
image-compare
    ↓
contrast-check

它能抽色、OCR、做 pixel-by-pixel diff、計算 mismatch percentage 與檢查 WCAG contrast。README 宣告 MIT，但 repository 沒有標準 LICENSE 檔、GitHub API 顯示 license: null；正式商用前宜請作者補齊。

第五選擇：pic-2-code

它是 React＋TypeScript 前端工具，直接從瀏覽器呼叫 Gemini 或 OpenRouter，把圖片轉成 HTML＋Tailwind、React、Flutter 或 React Native。

README 雖自稱 free、open-source，repository 與 package.json 卻沒有 License。依預設著作權規則，目前不應直接 fork 後商用。功能有趣，授權卻是硬傷。

Framework Implementation Skills：依技術棧選擇

shadcn／React 首選：shadcn-ui/ui → shadcn

如果專案使用 shadcn/ui，它幾乎是必裝：官方 source code、registry、semantic tokens、component composition、forms、icons、dark mode 與 debug workflow 全部對得上當前工具。

Angular 首選：官方 angular/skills

官方目前提供 angular-developer 與 angular-new-app。前者涵蓋 Signals、Signal Forms、DI、Routing、SSR、ARIA、Animations、Styling、Testing 與 CLI；它還要求先分析 Angular 版本，完成後執行 ng build。

這是 analogjs/angular-skills 的正式替代品。Skill front matter 明確標示 MIT。

Vue／Nuxt 綜合首選：antfu/skills

適合 Vue／Nuxt／Vite 為核心的現代前端：包含 Vue、Nuxt、Pinia、Vite、Vitest、VitePress、UnoCSS 與 Anthony Fu 自己的偏好。

根 repository 的自有 Skills 與 scripts 是 MIT；vendored Skills 保留各自上游授權，不能看見根目錄 MIT 就一概而論。

Vue 專項補充：vuejs-ai/skills

它聚焦 Vue 3、Composition API、Options API、Vue Router、Pinia、JSX、Vitest、Vue Test Utils、Playwright、SSR hydration 與 composables。內容更專一，但官方 README 仍稱它為 early experiment／community project。

Angular 舊版來源：analogjs/angular-skills

MIT 授權、591 Stars，但已明確標示 deprecated，也不再積極維護。知道它存在即可，新專案直接使用官方 angular/skills。

Skills Registry、Curated Collection 與 Discovery：推薦順序

首選：ibelick/ui-skills

它本身就是為 Design Engineers 建立的 UI Skill Registry，可用 CLI 依 category 搜尋與取得 Skill：

npx ui-skills categories
npx ui-skills list --category motion
npx ui-skills get baseline-ui

它也提供 MCP 的 list_skills、get_skill。如果你想讓 Codex 動態挑選 UI Skills，而不是把一整座圖書館塞進 context，這個方向非常合理。

第二選擇：JetBrains/skills

這是 JetBrains-filtered、JetBrains-verified 的 upstream snapshot，目前 README 列出 129 Skills、15 個上游 repositories，並用 skill scanner 做安全掃描。

它的重點是 curated 與 verified，不是原創所有內容。每份 Skill 保留 metadata.source 與各自上游授權，例如裡面的 Anthropic frontend-design 仍依 Apache-2.0。不要同時從 JetBrains 與上游安裝同一份 Skill。

第三選擇：vercel-labs/agent-skills

Vercel 官方合集包含 React／Next.js performance、composition patterns 與 web-design-guidelines 等能力。本文的 UI Review 重點是後者，它是 standalone web-interface-guidelines 的安裝 wrapper。

README 宣告 MIT，但根目錄沒有標準 LICENSE 檔，GitHub API 顯示 license: null。使用單一 Skill 時也應確認該 Skill 的來源與授權。

第四選擇：anthropics/skills

這是 Anthropic 官方 Skills 展示 repository，從 Creative／Design 到 Development、Enterprise 與 Documents 都有。它採分技能授權：許多 Skills 是 Apache-2.0，部分 document Skills 是 source-available 而非 open source，因此不能把整個 repository 統稱為 Apache 或完全可商用。

本文推薦的是 frontend-design，其資料夾內有完整 Apache-2.0 LICENSE.txt。

第五選擇：seb1n/awesome-ai-agent-skills

它不是連結清單，而是 103 份可直接使用的 SKILL.md workflows，涵蓋 Agent Engineering、Security、Coding、Research、Documents 與 Design。MIT 授權清楚，適合找跨領域 Skill；UI／UX 深度則不如專用 Registry。

第六選擇：anbeime/skill

它有 6,611 Stars，是大型通用 Skills 商店與聚合器，但不是 UI／UX 專案。Repository 沒有被 GitHub 偵測到 License，還聚合大量外部來源；適合 Discovery，不適合整包直接帶進商業專案。挑到 Skill 後應回到原始 repository 檢查版本、內容與授權。

30 個來源、Skill 與工具：採用分級總表

以下保留 30 個不同類型的來源，並以「實際採用價值」分層，而不是把 Stars 當成總排名。S、A、B 代表採用優先度；Discovery 與 C 級則說明哪些項目比較適合查找、比對或避開。

S 級：可以成為主工作流核心

A 級：功能很強，依專案情境加入

B 級：有明確用途，按需使用或先試驗

Discovery／鏡像：拿來找 Skill，不要全部重複安裝

C 級／排除：重複、棄用或授權不足

這份分級的目的，是讓主力 Skill、特化工具、Registry、低星 remix、已棄用與無授權專案出現在正確的位置。收錄不等於推薦，GitHub 上找得到也不等於應該安裝。

七套可直接套用的組合工作流

前面的責任分工原則落到實際專案後，可以組成以下七條流程。箭頭代表交接順序，不代表所有 Skills 都要同時常駐在同一個 context window。

組合一：通用產品／SaaS 新案

Anthropic frontend-design（定義主題與視覺方向）
    ↓
ui-ux-pro-max（補 UX、配色、字型、layout 規則）
    ↓
DESIGN.md（凍結 tokens 與設計理由）
    ↓
frontend-ui-engineering（實作 production UI）
    ↓
Vercel Web Interface Guidelines（規則型 Audit）
    ↓
Microsoft frontend-design-review（最後整體 Review）

taste-skill 不必預設加入。只有第一輪結果仍然太模板化時，才讓它擔任一次 Anti-Slop Critic，提出修改方向後退出。

組合二：shadcn／React 專案

frontend-design
    ↓
DESIGN.md
    ↓
shadcn Skill（registry、components、semantic tokens、forms）
    ↓
frontend-ui-engineering
    ↓
web-design-guidelines

不要叫 frontend-design 自己發明 Button API，再叫 shadcn 把它改回官方元件。視覺 Skill 決定外觀與層級；shadcn Skill 決定元件怎麼組。

組合三：Vue／Nuxt 專案

ui-ux-pro-max 或 frontend-design（二選一當 Creator）
    ↓
DESIGN.md
    ↓
antfu/skills（Nuxt、Vite、UnoCSS、Pinia）
    +
vuejs-ai/skills（只載入當下需要的 Vue 專項）
    ↓
web-design-guidelines

antfu/skills 與 vuejs-ai/skills 有重疊，不要整包同時常駐。遇到 Router、Pinia 或 SSR hydration 問題，再按需載入專項 Skill。

組合四：Angular 專案

frontend-design
    ↓
DESIGN.md
    ↓
angular/skills → angular-developer
    ↓
ng build
    ↓
web-design-guidelines + frontend-design-review

analogjs/angular-skills 直接退出流程。官方 Skill 會先辨識 Angular 版本，這對 Signals、Signal Forms 與新舊 API 差異特別重要。

組合五：Screenshot 重製與視覺回歸

pascalorg/image-analysis + image-to-text（拆 Screenshot）
    ↓
frontend-design 或 ui-ux-pro-max（決定哪些要保留、哪些要改善）
    ↓
DESIGN.md（萃取 tokens）
    ↓
Framework Skill（實作）
    ↓
pascalorg/image-compare（Pixel Diff）
    ↓
contrast-check + web-design-guidelines（Accessibility）

這裡要小心：Pixel Perfect 不等於 UX 正確。如果原圖本來就有低對比、難操作或侵權問題，忠實複製只是在高精度重製錯誤。

組合六：需要大量 Motion 的品牌頁

taste-skill 或 premium-frontend-ui（決定動態氣質）
    ↓
LottieFiles motion-design-skill（Timing、Easing、Choreography）
    ↓
Framework Implementation
    ↓
Web Interface Guidelines（Reduced Motion、Performance、Input Safety）

premium-frontend-ui 負責野心，LottieFiles 負責動得合理，Vercel Guidelines 負責不讓野心傷害使用者。

組合七：OpenDesign 或 Stitch 已經是主工作台

如果使用 OpenDesign，就讓它負責 orchestration、preview 與 export，只在缺少某種專業判斷時掛入外部 Skill。不要一邊使用 OpenDesign 內建的 100+ Skills，一邊又把所有 Registry 整包灌進 context。

如果使用 Stitch，則讓 stitch-skills 負責 Design-to-Code 主流程，外部只保留一套 Visual Director、一套 Framework Skill 與一套 Reviewer。

正式安裝前：License 之外還要檢查什麼？

Skill 本質上是給 Agent 的操作說明，有些還會附帶 CLI、scripts、MCP 或外部下載。授權清楚只代表取得了一部分法律許可，不代表執行內容、安全邊界與資料流向已經通過審查。

正式帶進公司或客戶專案前，我會再檢查六件事：

最穩妥的採用方式，是先在隔離的測試專案閱讀指令、限制權限、固定版本，再用一個可重現的小任務觀察它實際讀了什麼、改了什麼、呼叫了什麼。Stars 和漂亮 README 都不能替代這一步。

商用授權：GitHub 可以 Clone，不代表法務可以 Approve

MIT

MIT 允許使用、修改、合併、發布、散布、再授權與販售副本。主要義務是保留 copyright 與 license notice，而且軟體不附保固。完整條款見 Open Source Initiative：MIT License。

Apache-2.0

Apache-2.0 同樣允許商用、修改與散布，並提供明確的貢獻者專利授權。再散布時要附授權、保留適用 notices、標示修改；若上游有 NOTICE，也要依條款處理。它不授予商標權。完整條款見 Apache Software Foundation：Apache License 2.0。

README 寫 MIT，但沒有 LICENSE 檔

ux-ui-agent-skills、pascalorg/skills 與 vercel-labs/agent-skills 都有不同程度的這種情況。作者的授權意圖看得出來，但完整 license text、copyright notice 或標準檔案不足，會增加公司法遵與再散布時的不確定性。正式採用前，最好請作者補檔或由法務判斷。

沒有 License

沒有 License 時適用預設著作權，其他人通常沒有任意重製、散布或製作衍生作品的權利。GitHub 官方說明見 Licensing a repository。

因此 pic-2-code 不能因為 README 寫 free、open-source 就直接商用；anbeime/skill 這類聚合器也必須回到每個上游來源確認。

Repository 免費，不等於整條工作流零成本

結語：最強的不是某一套 Skill，而是責任清楚的 Pipeline

整理完 30 個專案後，我的結論反而不是「再多裝幾套」。

一套好的 UI Agent 工作流，應該知道誰負責提出方向、誰負責把方向固定成 tokens、誰負責 framework implementation、誰負責 Motion，又由誰在最後找問題。

如果只需要一個最短版本，我會這樣組：

用 frontend-design 決定視覺主題，用 ui-ux-pro-max 補足 UX，用 DESIGN.md 保存共識，用正確的 Framework Skill 實作，再讓 Vercel Guidelines 與 Microsoft Review 負責挑錯。

需要 Motion 才加入 LottieFiles，需要 Screenshot 才加入 Pascal，需要完整工作台才評估 OpenDesign 或 Stitch。Registry 用來找工具，不是整座搬進 context。

AI 的確可以在幾分鐘內寫出一個網站。真正的工程，不是讓它寫得更多，而是讓每一次決策都有來源、每一個輸出都有驗證、每一份拿進公司的內容都有清楚 License。

Stars 幫你找到人多的地方；功能分類告訴你該拿什麼工具；而清楚的責任邊界，才不會讓二十位 AI 設計總監在同一個按鈕上開會。

• 初版日期：2026-09-13

這是一份還在成長中的文章，GitHub Stars、功能、維護狀態與授權可能隨版本變動，歡迎訂閱追蹤後續更新！

本文依各專案查核當下的 GitHub repository、README、SKILL、LICENSE 與 package metadata 整理，不構成法律意見。正式商業發行前，仍應以實際版本的 LICENSE、NOTICE、第三方依賴與公司法務判斷為準。