emil-design-engは、Emil Kowalski氏が公開しているコーディングエージェント向けのデザインエンジニアリングスキルです。実体は27,226バイトのSKILL.mdが1ファイルだけ。最初の指示は質問が来るまで何も言わないこと、アニメーション判断フレームワークの大半は「動かすな」、CSS標準のイージングは弱いとして独自のcubic-bezierを3本同梱し、コードレビューはBefore/After/Whyの表を強制します。インストール数は2026年9月2日時点で243,573件（Skillselionカタログ）です。
この記事を書いた2026年9月2日、Googleトレンドで「emil kowalski design skill」が急上昇クエリ（過去30日、全世界）に入りました。説明文を繰り返すページは多いので、私たちはファイルそのものを節ごとに読みました。英語の全文読解はemil-design-engのディープダイブにあり、この記事はエージェントの挙動が変わる箇所に絞った日本語版です。
開示: 私たちはSkillselionを運営しています。skills.sh、GitHub、MCPレジストリから毎日更新される独立系のスキルカタログで、実インストール数でランキングしています。Anthropic、OpenAI、Cursor、Emil Kowalski氏とは無関係です。emilkowalski/skillsでこのファイルの最終コミットは2026年7月21日なので、以下の引用は今インストールされる内容と一致します。
最初の指示は「黙っていろ」
冒頭の「Initial Response」節は、質問なしでスキルが呼ばれたときの返答を1行に固定しています。書き出しは "I'm ready to help you build interfaces that feel right, my knowledge comes from Emil Kowalski's design engineering philosophy." で、末尾で作者の講座animations.devを案内します。その直後に、こうあります。
Do not provide any other information until the user asks a question.
Source: SKILL.md, "Initial Response"
27KBの本文を当てる対象がない状態で吐き出さない待機ルールとしては妥当です。一方で講座への誘導は、命令文の形をしたマーケティングです。コストは素の呼び出し1回につき1文ですが、エージェントの出力が顧客の目に触れるなら知っておくべき点です。
フレームワークの半分は「動かすな」
本体は4つの問いを順に答えさせる構成で、最初の問いは「そもそも動かすべきか」です。答えは表示頻度の表で決まり、最上段のキーボードショートカットとコマンドパレットの開閉は "No animation. Ever." です。
Never animate keyboard-initiated actions. These actions are repeated hundreds of times daily. Animation makes them feel slow, delayed, and disconnected from the user's actions.
Source: SKILL.md, "Should this animate at all?"
2つ目の問いは目的を5つから言わせるもので、「かっこいいから」が目的で、しかもユーザーが頻繁に見るものなら答えは「動かさない」です。ポリッシュ系のスキルなのに導入部の半分がブレーキで、エージェントは「生き生きさせて」と言われると全部動かしがちなので、ここが一番効きます。逆に足りないモーションを探す仕事は、同じリポジトリのfind-animation-opportunitiesスキルの担当です。
CSS標準のイージングを「弱い」と切り捨てる
3つ目の問いは分岐木で、出入りはease-out、画面内の移動はease-in-out、ホバーや色変化はease、等速運動はlinearに振り分けたうえで、標準キーワードの形そのものを退けます。
Critical: use custom easing curves. The built-in CSS easings are too weak. They lack the punch that makes animations feel intentional.
Source: SKILL.md, "What easing should it use?"
代わりの定数は次の3本です。
/* Strong ease-out for UI interactions */
--ease-out: cubic-bezier(0.23, 1, 0.32, 1);
/* Strong ease-in-out for on-screen movement */
--ease-in-out: cubic-bezier(0.77, 0, 0.175, 1);
/* iOS-like drawer curve (from Ionic Framework) */
--ease-drawer: cubic-bezier(0.32, 0.72, 0, 1);
Source: SKILL.md, "What easing should it use?"
UI用途のease-inは "Never use ease-in for UI animations." と全面禁止です。理由は機構で書かれていて、ease-inは動き出しを遅らせる、そしてユーザーが一番注視しているのはその瞬間だから、というものです。この3本の値は私たちが読んだコミット時点で兄弟スキルの少なくとも4ファイルにも同じ値で入っているので、兄弟と一緒に入れると同じ定数がコンテキストに2回載ります。
300msルールとdurationテーブルの矛盾
4つ目の問いは5行のdurationテーブルで、ボタンの押下フィードバックが100〜160ms、モーダルとドロワーが200〜500msです。その直下にこうあります。
Rule: UI animations should stay under 300ms. A 180ms dropdown feels more responsive than a 400ms one.
Source: SKILL.md, "How fast should it be?"
ドロワーはUI要素で、3行上の表は500msまで許しています。人間なら300msを既定値、500msを大型面の許容値と読み分けますが、ファイルはそう書いていません。そして末尾のチェックリストが300msを欠陥に変えます。
| Duration > 300ms on UI element | Reduce to 150-250ms |
Source: SKILL.md, "Review Checklist"
つまり4つ目の問いが許した400msのドロワーは、同じスキルでレビューすると指摘対象になり、修正案の150〜250msはdurationテーブルがドロワーに一度も示していない帯です。エージェントは両方を書かれたとおりに適用します。
レビューはBefore/After/Whyの表で
When reviewing UI code, you MUST use a markdown table with Before/After columns. Do NOT use a list with "Before:" and "After:" on separate lines.
Source: SKILL.md, "Review Format (Required)"
5行のサンプル表に続いて、やってはいけないリスト形式の例までフェンスで載せています。出してほしくない出力をわざわざ描くのは、作者が何度も見た癖への矯正でしょう。3列目のWhyは1行ごとに理由を強制し、末尾には11行の「問題と修正」チェックリストもあります。レビューそのものが仕事なら、レビュー専用のreview-animationsスキルが小さいファイルで受け持ちます。
ルールが尽きる場所も書いてある
パフォーマンス節はインシデントメモのようです。Framer Motionのx、y、scaleショートハンドはメインスレッドのrequestAnimationFrameで動くのでtransform文字列を書け、と述べ、根拠に実例を挙げます。
At Vercel, the dashboard tab animation used Shared Layout Animations and dropped frames during page loads. Switching to CSS animations (off main thread) fixed it.
Source: SKILL.md, "Framer Motion hardware acceleration caveat"
バージョンの記載はなく、ライブラリ内部は変わります。opacityとheightの組み合わせでは "This is often trial and error." と公式がないことを認め、実機をUSBでつないで確認しろという節もあります。エージェントには実行不能ですが、人間が参照する資料としては有効です。
同じリポジトリの兄弟スキル（インストール数順）
リポジトリのスター数は2026年9月2日時点で34,182、以下のインストール数も同日時点のSkillselionカタログの値です。
- emil-design-engスキル、243,573件、この記事の本体（GitHub）
- review-animations、133,796件、既存モーションの監査（上でリンク済み、GitHub）
- animation-vocabularyスキル、121,235件、曖昧な表現を正確な用語に対応づける（GitHub）
- apple-designスキル、114,701件、ジェスチャー、スプリング、シートUI(GitHub)
- improve-animationsスキル、106,122件、既存アニメーションコードの読み取り専用監査と修正プラン（GitHub）
- find-animation-opportunities、93,723件、足りないモーションの発見（上でリンク済み、GitHub）
- pick-ui-libraryスキル、77,984件、タスクごとに1つのコンポーネントライブラリを推薦（GitHub）
- prototypeスキル、66,855件、同じUI部品の複数バージョンをピッカーで比較して採用（GitHub）
入れるべきか
インタラクション実装のとき、意見のはっきりした参照資料を1つコンテキストに置いておきたい人には向いています。ブレーキの部分が最も強く、パフォーマンス周りのルールはスタイルガイドより出荷済みライブラリの実装メモに近く、ファイル内ではSonnerとVaulの名前が挙がっています。
コンテキスト予算が厳しい人には向きません。リポジトリ内で最大のファイル（次点のapple-designは22,715バイトなので約20%大きい）で、しかもモデルが自動で呼べるスキルの中で唯一、descriptionに "Use when" の句がありません。デザインシステムを期待している人にも向きません。色、余白、レイアウトの指針はゼロで、その方面はフロントエンドデザイン向けスキルのランキングにあるAnthropic公式のfrontend-designスキルやdesign-taste-frontendスキルが受け持ちます。
インストールコマンド（掲載ページの表記のまま）:
npx skills add https://github.com/emilkowalski/skills --skill emil-design-eng
ほかのスキルも同じ方法で読んだ記事はSkillselionのディープダイブ一覧にあります。
よくある質問
他のEmil Kowalskiスキルと同じもの? 違います。READMEが最初に挙げる参照コーパスがこれで、タスク別の兄弟スキルは必要な定数と頻度フレームワークを自分の言葉で再掲しています。
コンテキストをどれだけ使う? 私たちが読んだコミットで27,226バイト、リポジトリ内で最大のSKILL.mdで、同梱ファイルはありません。
React以外でも使える? 判断ロジックは使えます。サンプルはCSS、React、Motion前提なので、VueやSvelteではルールは得られてもコピペは効きません。
最終更新は2026年9月2日です。引用はすべてemilkowalski/skillsのskills/emil-design-eng/SKILL.md（最終コミット2026年7月21日）と照合済みです。