AI コーディングエージェントに UI を作らせると、機能としては動くのに、仕上がりがどこか安っぽくなることがあります。入場アニメーションに ease-in が選ばれる、要素が scale(0) から現れる、半透明のシャドウではなく実線のボーダーが使われる。ひとつひとつは小さなズレですが、画面全体で積み上がると「なんとなく既製品らしくない」印象になります。
やりにくいのは、この種のズレが指摘しづらいことです。アニメーションやデザインの良し悪しは言語化が難しく、レビューで「もう少し自然に」と書いても再現性がありません。エージェントに「いい感じにしてほしい」と頼んでも、判断基準そのものを渡していないため、結果が安定しません。
emilkowalski/skills は、この判断基準を Markdown のルールとしてエージェントに読ませるスキル集です。「どのイージングを使うか」より前に「そもそも動かすべきか」を決めさせ、カーブや継続時間は表から選ばせる、という形で意思決定の順序ごと固定しています。2026年10月13日時点でスター 45,759 を集めており、UI 領域のエージェントスキルとしては大きな規模です。
本記事では、公開ドキュメントをもとにリポジトリの構成、ルールの中身、類似スキル集との違い、導入判断の材料を整理します。なお本記事は GitHub 上の README・各 SKILL.md・著者の公式ブログ・配布サイトの記載に基づくドキュメントベースの調査であり、インストールや実行による動作検証は行っていません。各スキルがエージェント上でどう振る舞うかは、読者側の環境で確認する前提でお読みください。
emilkowalski/skills とは｜AIエージェントにUIアニメーションの基準を渡すOSS
emilkowalski/skills は、GitHub リポジトリの README で「Skills For Designers and Engineers」と題され、「デザイナーとエンジニアがより良いユーザーインターフェースを作る手助けをするため」のスキル集として説明されています。リポジトリの description は「Skills for Designers and Engineers.」です。
README が設定している課題は明快です。アニメーションやデザイン全般において、自分の選択が正しかったかを判断するのは難しい。これらのスキルは、その正しい判断に早くたどり着くためのものだ、という立ち位置です。内容は著者 Emil Kowalski が Vercel や Linear といった企業で働いた経験に基づくと記載されています。
「Why use it?」の節では、エージェントの具体的な失敗が挙げられています。入場アニメーションに本来 ease-out を使うべき場面で ease-in を選んでしまう、UI に半透明のシャドウではなく実線のボーダーを選んでしまう、といった例です。README はこうした小さな要素が積み上がってインターフェースの印象を決めると述べ、スキル群はエージェントが起こしうる細かなミスを列挙し、その直し方を説明するものだと位置づけています。
注目したいのは、著者が AI の役割をどう捉えているかです。README には「ここにあるスキルはすべてドメイン専門性の副産物であり、AI は専門性を置き換えるのではなく、専門性から引き出せるものを増幅する」という趣旨の記述があります。エージェントに判断を委ねるのではなく、人間側が持つ判断基準を明文化してエージェントに渡す、という設計思想です。この前提を押さえておくと、後述するルールの書き方が理解しやすくなります。
リポジトリ基本情報とメンテナンス状況
採用を検討するうえで最初に確認したいのは、プロジェクトが生きているかどうかです。
基本メタデータ
以下はいずれも 2026年10月13日時点の GitHub API 実測値です。
項目 | 値 |
|---|---|
リポジトリ | emilkowalski/skills |
description | Skills for Designers and Engineers. |
主要言語 | Markdown |
スター数 | 45,759 |
フォーク数 | 2,604 |
ライセンス | MIT |
最終 push | 2026-10-11 |
公開状態 | public |
アーカイブ / フォーク | いずれも該当なし（アーカイブされておらず、他リポジトリのフォークでもありません） |
最終 push が調査日の 2 日前であり、アーカイブもされていないため、更新が止まったプロジェクトではありません。ライセンスは MIT で、商用利用を含めて利用可能ですが、著作権表示とライセンス文の保持が条件になります。
主要言語が Markdown である点は重要です。リポジトリのルートには README.md、LICENSE、performance-cheatsheet.md などがあり、skills/ ディレクトリ配下に 15 個のスキルディレクトリが並びます。各ディレクトリの中身は SKILL.md などの Markdown ファイルで、実行コードは含まれていません。つまり導入時にビルド構成や依存関係へ手を入れる必要がなく、影響範囲は「エージェントが読むドキュメントが増える」ことに限定されます。この性質は、後述する注意点の裏返しでもあります。
利用の広がり（skills.sh のインストール実績）
配布サイトのskills.sh 掲載ページでは、掲載スキル数 15、合計インストール数が約 220 万件と表示されています（2026年10月13日時点）。スキル別の上位は以下のとおりです。
スキル | インストール数 |
|---|---|
emil-design-eng | 346.8K |
review-animations | 220.7K |
apple-design | 206.2K |
animation-vocabulary | 206.2K |
improve-animations | 190.0K |
find-animation-opportunities | 175.8K |
pick-ui-library | 154.5K |
全体方針を担う emil-design-eng が最も多く、次に既存アニメーションのレビュー・改善系が続いています。新規にアニメーションを実装する animate（137.4K）より、既存コードを診断する側のスキルに関心が集まっている構図です。「すでに書かれた UI の品質をどう上げるか」が、多くの利用者の関心事であることが読み取れます。
なお、第三者のスキルディレクトリサイトでは、本リポジトリのスキル数やスター数が実際と食い違っている例が見られます。本記事の数値は GitHub API の実測値と skills.sh の表示値のみを採用しています。
15スキルの構成と役割分担
README の Reference 節には 15 スキルの一覧と 1 行説明が並んでいます。すべてを入れるかどうかの前に、どの作業フェーズに効くスキルなのかを整理しておくと判断しやすくなります。
カテゴリ別の15スキル一覧
カテゴリ | スキル | 役割（README の説明より） |
|---|---|---|
全体方針 | emil-design-eng | アニメーションを中心に、デザイン助言も含むメインスキル |
新規作成 | animate | カーブ・継続時間・プロパティを選びながらアニメーションをゼロから実装する |
新規作成 | animate-expo | 同じ基準を React Native / Expo 向けに適用（ジェスチャ・シート・ハプティクス・JS スレッド回避） |
診断・改善 | review-animations | 著者のルールに基づいて既存アニメーションを厳格にレビューする |
診断・改善 | improve-animations | コードベース全体のアニメーションを監査し、優先度付きの実行計画を出力する |
診断・改善 | find-animation-opportunities | モーションが本当に有効な箇所を探し、同時に「動かすべきでない箇所」も指摘する |
診断・改善 | animation-performance | フレーム落ちを修正する（見落とされがちな問題を含む） |
対話補助 | animation-vocabulary | 曖昧な動きの指示を正しい用語に変換するための語彙集 |
デザイン原則 | apple-design | Apple の WWDC デザイントークを Web 向けに翻案した原則 |
実装支援 | write-swift | モダンな Swift（値型・Swift 6 並行性・ジェネリクス・Swift Testing） |
技術選定 | pick-ui-library | 著者が信頼するライブラリから適切なものを選ばせ、自前実装や放棄されたパッケージを避ける |
試作 | prototype | 指定した UI の複数バージョンを作り、切り替えて比較する |
モバイル Web | mobile-native | sticky hover・tap highlight・100vh バグ・入力ズーム・セーフエリアなどを修正する |
堅牢性 | break-ui | 長い名前・空リスト・巨大な数値といった最悪ケースのデータで UI を壊してみる |
ライブラリ | ask-sonner | 著者製トーストライブラリ Sonner の設定・スタイリング・よくある問題への対処 |
加えて、ルート直下の performance-cheatsheet.md が「症状 → 対処」の 1 枚表として用意されています。スキルディレクトリの外にあるため見落としやすいものの、アニメーションのパフォーマンス問題を切り分ける入口として参照しやすい資料です。
アニメーション系4スキルの責務分離
一覧を見ると、アニメーション関連のスキルが複数あり、役割が重複しているように見えます。しかし animate の SKILL.md には、責務の切り分けが明示されています。animate は「構築のためのスキル」であり、コードベースの監査は improve-animations、差分の批評は review-animations、動かせる箇所の探索は find-animation-opportunities、React Native 向けは animate-expo が担当する、という記述です。
この分離は、実際の開発フローにそのまま対応します。
- 新規実装するときは
animate - プルリクエストのモーションを批評するときは
review-animations - 既存プロダクト全体を棚卸しするときは
improve-animations - どこにモーションを足すべきか決めるときは
find-animation-opportunities
したがって「15 スキルすべてを入れるか」という二択で考える必要はありません。たとえば既存プロダクトのアニメーション品質を上げたいだけなら、監査系とレビュー系に絞る選択ができます。Swift や Expo を使っていないチームが write-swift や animate-expo を入れる理由はありません。
スキルの中身｜UIアニメーション改善を支える判断ルール
ここが本リポジトリの核心です。ドキュメントを読んで分かるのは、これらのスキルが「助言集」ではなく「決定表」として書かれていることです。エージェントに裁量を残さず、判断の順序・採用値・出力形式までを指定しています。
「動かすかどうか」を先に決めるゲート
animate の SKILL.md は、アニメーションを書く前に答えるべき質問を順番に並べ、最初の質問を「そもそも動かすべきか」に置いています。判断材料はユーザーがその動きを見る頻度で、以下の表が示されています。
| Frequency | Decision |
| --- | --- |
| 100+ times/day (keyboard shortcuts, command palette toggle) | **No animation. Ever.** Stop here. |
| Tens of times/day (hover effects, list navigation) | Near-imperceptible only — fast and subtle, or nothing |
| Occasional (modals, drawers, toasts) | Standard animation |
| Rare / first-time (onboarding, success, celebration) | The delight budget lives here |
出典: https://github.com/emilkowalski/skills/blob/main/skills/ani…
1 日に 100 回以上見る要素には「アニメーションなし。絶対に。ここで止まれ」と書かれています。SKILL.md はこれを判断の余地がある話ではなく失格条件だとし、Raycast に開閉アニメーションがないのは 1 日に何百回も開くものとして正しい、という具体例を添えています。
次の質問は目的の言語化です。Feedback（インターフェースが入力を受け取ったことの確認）、Spatial consistency（どこから来てどこへ行ったかの提示）、State indication（状態変化を読み取れるようにする）、Preventing a jarring change（突然の切り替わりを和らげる）、Explanation（仕組みの説明。マーケティングやオンボーディングのみ）、Delight（まれにしか見ない階層でのみ許可）のいずれかで名付けられない動きは作らない、と規定されています。「見栄えが良いから」は、頻繁に見られる要素においては中止の理由になる、とまで書かれています。
このゲートが効くのは、エージェントが「依頼されたから動かす」方向に傾きやすいからです。SKILL.md 自身が、このゲートはときにゼロ行のコードを生むために存在し、それは逃げではなく成功だと明記しています。
値を近似させないハードルール
animate には Hard Rules として 5 項目が置かれています。
1. **Run the sequence in order.** Steps 1 and 2 gate everything. Don't reach for a curve before you know whether it animates at all.
2. **No approximated values.** Every curve, duration, and spring config comes from the tables below. Never invent `cubic-bezier(0.4, 0, 0.2, 1)` because it looks familiar.
3. **Extend the codebase's tokens, don't fork them.** If `--ease-out` or a duration scale already exists, use it. Adding a parallel system is a defect.
4. **Reduced motion and hover gating ship with the animation**, not as a follow-up.
5. **Cheapest tool that works.** Don't install a motion library for a fade.
出典: https://github.com/emilkowalski/skills/blob/main/skills/ani…
2 番目の「値を近似しない」が、エージェント特有の失敗に対する処方になっています。cubic-bezier(0.4, 0, 0.2, 1) は学習データに大量に含まれる値であり、見覚えがあるから使われやすい。それを明示的に禁じ、スキル内の表から取ることを強制しています。3 番目は既存のデザイントークンを拡張する指示で、並行システムを作ることを「欠陥」と呼んでいます。4 番目は prefers-reduced-motion とホバー制御を後追いにせず同時に出荷させるもので、アクセシビリティ対応が実装の一部として組み込まれています。
プロパティの選択についても具体的です。SKILL.md は transform と opacity のみを使うこと（レイアウトとペイントを飛ばして GPU で動くため）、scale(0) は決して使わず scale(0.9〜0.97) と opacity: 0 から始めること（現実世界で何かが無から現れることはないため）、ポップオーバーやドロップダウンは transform-origin をトリガー位置に置くこと（モーダルは例外で中央のまま）を指示しています。
ツール選定も「動くもののうち最も安価な手段」から順に降りていく表になっており、ホバーや状態トグルは CSS トランジション、マウント時の入場は CSS の @starting-style、ページが読み込みで忙しい間も滑らかに動かす必要がある決まった動きは CSS アニメーション（メインスレッド外で動くため）、プログラム制御は WAAPI、スプリングやレイアウトアニメーション・ジェスチャ駆動は Motion、という順序です。フェードのためにモーションライブラリを入れる、という判断は最初から排除されます。
パフォーマンス面では、ルート直下の performance-cheatsheet.md が症状別の対処を並べています。
| Problem | Solution |
| ----------------------------------- | --------------------------------------------------------- |
| Animation stutters | Animate `transform`/`opacity`, not `width`/`top` |
| Long list scrolls slowly | Virtualize — only render what's visible |
| Blur causes perf issues | Keep animated `blur()` under 20px |
出典: https://github.com/emilkowalski/skills/blob/main/performanc…
これらの数値基準の背景は、著者の公式ブログ記事Agents with Tasteで説明されています。同記事では、テイストの判断には多くの場合よく見れば論理的な理由があり、だからこそルール化できるという主張が示され、具体的な基準として、入退場は ease-out、画面上の移動や変形は ease-in-out、ホバーは ease、等速は linear、マイクロインタラクションは 100〜150ms、ツールチップは 150〜250ms、モーダルは 200〜300ms、UI アニメーションは 300ms 未満、といった値が挙げられています。スキル側のハードルールは、この記事の内容をエージェントが参照できる形に落としたものと位置づけられます。
出力形式まで固定するレビュー規約
メインスキルの emil-design-eng/SKILL.md は、UI コードをレビューする際の出力形式そのものを規定しています。「Review Format (Required)」という節で、Before / After / Why の 3 列を持つ Markdown テーブルを必ず使うこと、「Before:」「After:」を別行に書いたリスト形式は使わないことを指示し、実例として次のテーブルを置いています。
| Before | After | Why |
| --- | --- | --- |
| `transition: all 300ms` | `transition: transform 200ms ease-out` | Specify exact properties; avoid `all` |
| `transform: scale(0)` | `transform: scale(0.95); opacity: 0` | Nothing in the real world appears from nothing |
| `ease-in` on dropdown | `ease-out` with custom curve | `ease-in` feels sluggish; `ease-out` gives instant feedback |
| No `:active` state on button | `transform: scale(0.97)` on `:active` | Buttons must feel responsive to press |
| `transform-origin: center` on popover | `transform-origin: var(--transform-origin)` | Popovers should scale from their trigger (not modals — modals stay centered) |
出典: https://github.com/emilkowalski/skills/blob/main/skills/emi…
同じ SKILL.md には、スキルが具体的な質問なしに呼び出された場合の応答文を固定する節や、「テイストは訓練されるもので生得的なものではない」「見えない細部が積み上がる」「美しさはレバレッジになる」という Core Philosophy の記述もあります。エージェントの初動から出力形式までを揃える設計です。
animate 側にも「モーションの選択肢をメニューとして提示するな。判断を下し、理由を 1 行で述べ、コードを書け」という記述があります。エージェントが選択肢を並べて判断を利用者に戻す振る舞いを、明示的に禁じている点が特徴的です。レビューの出力が毎回同じ形で返ってくるなら、差分の比較や指摘の蓄積がしやすくなります。この「形式の固定」が、ルールの中身と並ぶもう一つの価値だと読み取れます。
類似スキル集との違い｜anthropics/skills・ibelick/ui-skills・pbakaus/impeccable
エージェント向けスキル集は複数公開されており、「どれを入れるか」が実際の論点になります。代表的な 3 件と比較します。数値はいずれも 2026年10月13日時点の GitHub API 実測値です。
リポジトリ | description | 言語 | スター | ライセンス | 最終 push |
|---|---|---|---|---|---|
Skills for Designers and Engineers. | Markdown | 45,759 | MIT | 2026-10-11 | |
Public repository for Agent Skills | Python | 180,767 | 未設定 | 2026-10-09 | |
Skills for Design Engineers | TypeScript | 9,647 | MIT | 2026-10-12 | |
The design language that makes your AI harness better at design. | JavaScript | 80,359 | Apache-2.0 | 2026-10-12 |
anthropics/skills は Agent Skills の公式リポジトリで、対象領域が汎用です。ドキュメント処理などを含み、スキルそのものを作るための支援（skill-creator）側に重心があります。emilkowalski/skills は UI とモーションの領域に特化し、判断基準の「値」まで固定している点が差分です。両者は競合というより土台と応用の関係に近く、著者ブログにはこのスキル群の作成に Anthropic の skill-creator を使ったという記述があります。なお anthropics/skills はライセンスが未設定であり、社内利用の可否を判断する際には注意が必要です。
ibelick/ui-skills は「Skills for Design Engineers」を掲げ、対象領域が最も近い存在です。差分は配布形態にあります。ui-skills は独自 CLI に加えて MCP エンドポイント（list_skills / get_skill）でレジストリを提供し、複数著者のスキルを横断して引けるカタログ型です。対して emilkowalski/skills は、単一著者の見解を一貫したルールとして固定し、CLI でファイルを配置する形を取ります。「幅広く引けること」を優先するか、「基準が一貫していること」を優先するかの違いです。
pbakaus/impeccable は「AI ハーネスのデザイン力を上げるデザイン言語」を掲げ、AI 生成物に特有の既視感あるデザインを検出するルール群を備えます。スキル数は少なく、コマンドとアンチパターンのルールを束ねた構成で、JavaScript の実装を含みます。emilkowalski/skills との差分は粒度で、継続時間やイージングといったモーションの意思決定まで踏み込んでいるのは後者です。ライセンスは Apache-2.0 です。
これらは排他的な選択肢ではありません。カタログ型と単一著者型は性質が異なるため併用も成立します。ただし複数のスキル集を同時に入れると、エージェントが参照する基準が競合する可能性があります。モーションの継続時間やイージングのように値まで指定されている領域では、どのスキルを正とするかを決めておくほうが結果は安定しやすいと考えられます。
導入手順と前提条件
README の「Install」節には、インストールコマンドが次のように記載されています。
npx skills@latest add emilkowalski/skills
出典: https://github.com/emilkowalski/skills
この skills CLI は、配布サイトである skills.sh と同じく Vercel の提供によるもので、実装は vercel-labs/skills で公開されています（MIT ライセンス）。スキルはエージェントが読み込む Markdown ファイルとして配置される形式で、リポジトリ側に実行コードは含まれません。
skills.sh のナビゲーションには Claude Code・Cursor・Codex・GitHub Copilot・Windsurf・Gemini・Cline などのエージェント名が並んでいますが、本リポジトリの掲載ページ自体に固有の対応エージェント表記はありません。どのエージェントでどう読み込まれるかは CLI 側の対応状況に依存するため、利用中のエージェントでの挙動は各自の環境で確認する前提になります。本記事では動作検証を行っていないため、個別エージェントでの動作保証については言及しません。
更新の追跡手段も用意されています。README からは著者の公式サイトaiforui.devがリンクされており、ニュースレターに登録することで各スキルの使い方や新規公開の通知が得られると案内されています（受付状況は時点により変わります）。15 スキルすべてを常時追う必要はありませんが、ルールの値が更新されるタイプのリポジトリであるため、更新経路を押さえておくと運用しやすくなります。
導入前に確認したい注意点
採用判断にはリスク側の確認も必要です。公開ドキュメントから読み取れる範囲で、事前に見ておきたい点を挙げます。
- 単一著者の基準であること。README は内容が著者の長年の経験に基づくと明記しています。これは一貫性の源である一方、普遍的な正解ではなく一つの基準です。既存のデザインガイドラインを持つチームでは、方針が衝突する箇所が出る可能性があります。
- 既存トークンの存在が前提になっている箇所がある。
animateのハードルールは「コードベースのトークンを拡張し、並行システムを作るな」と指示しますが、イージングや継続時間のトークンを持たないコードベースでは、拡張対象がありません。その場合はスキルの値をそのまま新規トークンとして導入するかどうかの判断が先に必要です。 - スタック依存のスキルが混在する。
write-swift（Swift）、animate-expo（React Native / Expo）、ask-sonner（Sonner）のように前提技術が限定されるスキルが含まれます。必要なものだけを選ぶ運用が前提になります。 - 実装コードを含まないため、成果はエージェント側の読み込み挙動に依存する。主要言語が Markdown であることの裏返しで、ルールが参照されるかどうかはエージェントの仕様や設定に左右されます。
- ライセンスは MIT。商用利用は可能ですが、著作権表示とライセンス文の保持が条件です。比較対象のうち anthropics/skills はライセンス未設定、pbakaus/impeccable は Apache-2.0 で条件が異なります。
- 繰り返しになりますが、本記事は公開ドキュメントのみに基づく調査です。導入の最終判断は、自チームのエージェント環境での確認を経て行うことをおすすめします。
どんなチームに向くか｜採用判断のチェックポイント
ここまでの内容を、採用判断の形に整理します。
向いているケース
- エージェントに UI 実装を任せているが、アニメーションの仕上がりにばらつきがあり、レビューで同じ指摘を繰り返している
- モーションのレビュー観点をチームで言語化できておらず、指摘が属人的になっている
- 既存プロダクトのアニメーション品質を棚卸ししたいが、どこから手をつけるかの基準がない（監査系・レビュー系のスキルが該当します）
- レビュー出力の形式を揃え、差分を追跡できる状態にしたい
優先度が下がるケース
- デザインシステムとモーショントークンが整備済みで、継続時間やイージングの基準がすでにチームで共有されている
- Web フロントエンドが主戦場ではなく、UI モーションの改善が優先課題になっていない
- 既存のデザインガイドラインが確立しており、単一著者の基準に合わせることで方針が揺れる懸念がある
判断の入口としては、「15 スキルを入れるか」ではなく「どの作業フェーズに基準が足りていないか」から考えるほうが現実的です。新規実装の品質を上げたいなら animate、既存コードの棚卸しなら improve-animations、プルリクエストのレビュー基準を揃えたいなら review-animations、動かす箇所の判断から迷っているなら find-animation-opportunities が対応します。まずは該当するスキルの SKILL.md を読み、そこに書かれた判断基準が自チームの方針と矛盾しないかを確認するのが、もっとも低コストな検討の進め方です。
ルールの中身は公開されているため、導入せずに読むだけでもレビュー観点として使えます。エージェントに渡すかどうかは、その次の判断で構いません。
関連情報
AI コーディングエージェントを前提とした開発体制の設計や、UI 実装の品質基準づくりについてご相談がある場合は、お問い合わせフォームよりご連絡ください。要件の整理段階からご相談いただけます。
