emilkowalski/skills徹底解説｜5本から13本に増えたセンスのSkill集を常駐コストまで実測

「AIにコードは書けても、“良いセンス（taste）”はない」——2026年3月に公開されたリポジトリ emilkowalski/skills は、この一点を出発点にしています。作者は、トースト通知ライブラリ sonner とドロワー（引き出し型）UIの vaul で知られるデザインエンジニア、Emil Kowalski 氏。Vercel と Linear で培った“UIを気持ちよくする”知見を、AIエージェントがそのまま参照できる Agent Skill の形に落とし込んだのがこのリポジトリです。

結論を先に言うと、emilkowalski/skills の本質は「一人の専門家の美的判断（デザインとアニメーションのセンス）を、AIが読み込める SKILL.md に落とし込んだ“センスの注入装置”」です。本記事では初出時に5本だったSkillが13本へ増えた現在地を、2026-10-01 に clone した main（最終コミット d16ebe6・2026-09-24）を1本ずつ計測し直して解説します。Skillを置く側の環境づくりはClaude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きに、Agent Skills 形式そのものの仕組みはClaude Skillsとは｜「スキル=フォルダ」の仕組みと作り方・使い方を徹底解説にまとめてあるので、必要なら併読してください。

1. emilkowalski/skillsとは — 13本に増えたデザインエンジニアのSkill集

emilkowalski/skills は、「デザイナーとエンジニアのためのSkill集」を掲げるリポジトリです。GitHub の説明は「Skills for Designers and Engineers.」だけ。ここで言う“Skill”は学習教材でもチュートリアルでもなく、Anthropic が定義する Agent Skills 形式のファイル群、つまり AIコーディングエージェントに読み込ませて振る舞いを変えるための知識パッケージ です。

作者の Emil Kowalski（@emilkowalski） 氏は、フロントエンド界隈では名の通ったデザインエンジニアです。トースト通知ライブラリの sonner、ドロワーUIの vaul という、実プロダクトで広く使われる2つのライブラリの作者として知られています。経歴には Vercel と Linear——“UIの気持ちよさ”への強いこだわりで知られる2社——での実務が含まれ、オンラインのアニメーション講座 animations.dev も運営しています。

数字で現在地を確認します。2026-10-01 時点で ⭐42,448・Fork 2,411。本記事の初出時（2026-07-12）は ⭐10,133、前回更新時（2026-09-07）は ⭐35,878 だったので、3か月で4倍を超えました。ライセンスは MIT、リポジトリ作成は2026年3月16日。導入は、コミュニティ製のインストーラ skills.sh 経由です。

npx skills@latest add emilkowalski/skills

最も大きく変わったのは中身の構成です。初出時に5本だったSKILL.mdは、いま13本あります。clone して1本ずつ測った結果がこちらです。

最大のSKILL.mdは write-swift の42,445バイトです。値型、Swift 6 の並行性、ジェネリクス、パフォーマンス、Swift Testing までを扱う、純然たるSwiftのコーディング規約でした。「デザインのセンスを注入するリポジトリ」という初出時の説明は、いまも間違いではありませんが、それだけでは足りなくなっています。

なおリポジトリはshallow cloneでしか取得できなかったため、どのSkillがいつ追加されたかの個別の日付は確認できていません（未検証）。本記事が初出時に扱った5本と、現在の13本の差分から「あとから増えた8本」として扱います。

2. なぜ「AIにセンスはない」のか — このリポジトリが解く問題

AIコーディングエージェントは、この数年で「動くコードを書く」能力を急速に高めました。しかし Emil 氏がエッセイ “Agents with Taste” で指摘するのは、コードが動くこととUIが良いことは別だ、という点です。氏の言葉を借りれば、エージェントには “良いセンス（taste）”がない。ここでの“センス”とは、天賦の美的感覚のことではなく、無数の小さな判断を正しい方向へ倒す力を指します。

READMEにある具体例が分かりやすい。要素が画面に現れる（enter）アニメーションでは、動きの終わりが滑らかに減速する ease-out が自然に感じられます。ところがエージェントに任せると、立ち上がりが遅く最後に急加速する ease-in を選んでしまうことがある——人間の目には“もたつき”として映る選択です。影も同様で、要素を浮かせたいとき、現実の光がつくる 半透明のやわらかい影 が正解の場面で、エージェントは ベタ塗りのボーダー（枠線） を置いてしまう。ひとつひとつは些細ですが、こうした「材料選びの外し」が積み重なると、UIは一目で“素人っぽい”印象になります。

Emil 氏の主張の核心は、これらの判断は運や才能ではなく 専門性（ドメイン知識） から来る、という点にあります。READMEにはこう書かれています——「ここにあるSkillはすべてドメイン専門性の副産物だ。AIはそうした専門性を置き換えない、増幅する」。凡庸な出力（slop）があふれる時代に、他と際立つための“センス”こそが差別化の要因であり、専門性を持つ人がそれをSkillに落とし込めば、AIはその人の判断を再現できる、という仮説です。

同じ問題意識を別の角度から扱ったSkillに taste-skillとは｜AIが量産する”そっくりUIスロップ”を止めるアンチスロップ・スキルの設計思想と使い方 があります。あちらが「AIが量産する似たようなUIを止める」方向から入るのに対し、emilkowalski/skills は「正しい材料の選び方を教える」方向から入る、という違いがあります。

3. 13本の中身 — Webの5本と、あとから増えた8本

13本は、守備範囲がはっきり分かれています。まず、本記事が初出時に扱った5本の系譜から。

① emil-design-eng（設計哲学の本体・675行／27,123バイト） は、13本の中で2番目に大きい本体格のSkillです。UIの磨き込み、コンポーネント設計、アニメーションの判断、そして「ソフトウェアを“気持ちよく”感じさせる、目に見えない細部」についての Emil 氏の哲学が詰まっています。中核の思想は3つ——「センスは訓練で身につく（Taste is trained, not innate）」、「見えない細部は積み重なる（Unseen details compound）」（ここで Paul Graham の「かろうじて聞こえる千の声が、すべて調和して歌う」が引かれます）、「美しさはレバレッジ（Beauty is leverage）」。実務的な作法として、UIコードをレビューするとき 必ず Before/After のMarkdown表 を使うよう定めています。

② review-animations（厳格なレビュアー・121行＋STANDARDS.md 187行） は、アニメーション専用の審判です。基本姿勢は 「デフォルトは指摘。合格は勝ち取るもの」。disable-model-invocation: true が設定されており、明示的に頼まれたときだけ起動します。10の揺るがない基準（The Ten Non-Negotiable Standards） は現在も健在で、内容も初出時から変わっていませんでした。

・①動く理由を正当化できること（「かっこいいから」は頻出要素ではブロック）
・②頻度に応じて強度を落とす（キーボード操作や1日100回超の操作にはアニメーションを付けない）
・③応答的なイージング（enter/exit は ease-out、UIでの ease-in はブロック）
・④UIのアニメーションは 300ms 未満
・⑤原点と物理的な正しさ（ポップオーバーはトリガー基点、scale(0) は禁止で 0.9〜0.97 と opacity から。モーダルは例外）
・⑥中断可能であること
・⑦GPUが扱えるプロパティ（transform / opacity）のみ
・⑧アクセシビリティ（prefers-reduced-motion を尊重、hover は hover:hover and pointer:fine でゲート）
・⑨enter と exit の非対称
・⑩全体の調和（迷ったら消すのが最も強い一手、とまで書かれています）

③ improve-animations（監査してから計画・110行＋AUDIT.md＋PLAN-TEMPLATE.md） は、監査してから計画を書くアドバイザーです。単一の差分ではなくコードベース全体を調べ、優先度をつけた発見の表として提示します。ユニークなのは出力の形で、このSkillは自身ではソースコードを一切改変しません。代わりに、正確なファイル、正確な cubic-bezier、正確な duration、“feel check（触り心地の確認）”まで含んだ自己完結した実装計画を plans/ に書き出します。文脈もセンスも持たない安いモデルがそのまま実行できる粒度で書く、という指定です。判断が効く工程は高性能モデルに、単純な実行は安いモデルに——役割分担でコストと品質を両立させる設計になっています。

④ animation-vocabulary（逆引き用語集・182行） は、動きの逆引きの用語集です。「あの弾む感じ」は Pop in、「iOSのゴムみたいに戻るスクロール」は Rubber-banding、「クリックしたボタンから生えてくるように開く」は Origin-aware animation。狙いは、AIやデザイナーに正しい言葉で指示できるようにすることで、効果を設計したり実装したりするものではありません。

⑤ apple-design（Apple流モーションの翻訳・291行） は、Apple のインターフェース設計と流体的なモーションの原則を Web に翻訳したSkillです。主な出典は WWDC のデザイン講演、とりわけ “Designing Fluid Interfaces”（WWDC 2018）。通底する考えは、インターフェースはモーションが画面上の現在値から始まり、ユーザーの速度を受け継ぎ、勢いを前へ投射し、いつでも掴んで逆転できるとき、はじめて“生きている”と感じられる、というもの。その道具が spring です。

ここからが、あとから増えた8本です。

⑥ write-swift（42,445バイト・397行） が最大。値型、Swift 6 の並行性、ジェネリクス、パフォーマンス、Swift Testing。⑦ animate-expo（17,891バイト＋RECIPES.md 385行） は React Native / Expo 向けで、ジェスチャー、シート、ハプティクス、画面遷移、そして「モーションをJSスレッドから外す」こと。⑧ mobile-native（16,838バイト） は、Webアプリをスマホでネイティブらしく見せるための実務的な修正集——張り付く hover 状態、タップハイライトの点滅、100vh のバグ、ページをズームさせる input、もたつくタップ、セーフエリア。

残りは実装と道具選びです。⑨ animate（11,860バイト＋RECIPES.md 324行） はアニメーションをゼロから作る側で、曲線・時間・プロパティを選ぶところまで面倒を見ます。⑩ find-animation-opportunities（9,808バイト） はUIを走査して「動かす価値のある場所」を探しますが、同時に「動かすな」も言うのが特徴。⑪ prototype（7,830バイト＋PICKER.md 197行） は、指定したUIの複数案を作って切替器で見比べさせます。⑫ pick-ui-library（4,790バイト） は最小のSkillで、19個のライブラリを5カテゴリで指名します（base-ui・cmdk・Sonner・input-otp・Leva、motion・NumberFlow・torph・Cobe・Satori・shiki、Liveline・recharts、dnd kit・Virtuoso、zustand・clsx・cva・next-themes）。AIに自前でトーストを書かせたり、放置されたパッケージを入れさせたりしないための歯止めです。⑬ ask-sonner（7,233バイト＋API.md） は、Emil 氏自身のライブラリ Sonner の取扱説明でした。

横断して見ると、初出時に見えた「哲学・審判・計画・語彙・他流派の原則」という役割分担の思想はそのまま残り、そこに「実装（animate）・発見（find-opportunities）・比較（prototype）・道具選び（pick-ui-library）」と「ネイティブ側（write-swift / animate-expo / mobile-native）」の2軸が足された形です。Webのアニメーションに閉じた小さなSkill集は、デザインエンジニアの仕事の全域をカバーしようとするSkill集に姿を変えつつあります。

似た方向のSkill集としては、designer-skillsとは｜9プラグイン96スキルをClaude Codeに入れるデザインOSS が96スキルという物量でデザイン全般を扱っています。emilkowalski/skills はその対極で、13本のまま1本ずつを厚くする方向に進んでいる、と整理できます。

4. どう動くのか — 入れっぱなしの常駐コストを測る

13本のSkillは、どれも SKILL.md という1枚のMarkdownファイルが本体です。この形式は Anthropic が定めた Agent Skills のオープン仕様に沿っています。各SKILL.mdの先頭に YAMLフロントマター があり、そこに name（Skillの名前）と description（何をするSkillか）を書きます。

肝は description の使われ方です。エージェントは、プロジェクトに置かれた全SKILL.mdの本文をいきなり全部読むわけではありません。まず各Skillの description だけを読み、いま取り組んでいるタスクに関係するかを判断します。関係すると判断したときにはじめて、そのSkillの本文を丸ごと読み込む——この仕組みが プログレッシブ・ディスクロージャ（段階的開示） です。

「13本も入れたらコンテキストを食うのでは」という疑問は当然出るので、実際に測りました。

トークン数はいずれも当サイトの tools/token_audit.py が使う heuristic 近似（CJK 1字=1・ASCII 4字=1）で数えたもので、tiktoken の cl100k_base はBPE辞書の取得がこの環境の外向き通信で遮断され使えませんでした。常駐ぶんは13本合わせて1,443トークン。Skill 1本あたり約111トークンで、入れっぱなしにしても実用上ほぼ無視できます。逆に、本文まで全部読み込むと約5万トークンに達するので、description が「起動スイッチ」を握っているという構図がよく分かります。

参照ファイルの分離も効いています。review-animations は本体121行に対して STANDARDS.md が187行、animate は208行に対して RECIPES.md が324行、animate-expo は264行に対して RECIPES.md が385行——本体より参照ファイルのほうが大きいSkillが3本あります。「まず本文で概要をつかみ、細かい数値やレシピが必要になったら参照表を開く」という二段構えです。人間がリファレンスを引くときの動きに近く、AIにとっても一度に読む量が減るぶん、判断が安定しやすくなります。

自動起動の扱いも見ておきます。disable-model-invocation: true が入っているのは13本中3本——review-animations・prototype・pick-ui-library でした。厳しく点検する、複数案を作る、ライブラリを指名する——どれも勝手に始まられると困る類の作業です。このフラグの挙動は当サイトで別途実測したとおりで、明示的に呼ぶまで起動しなくなります。

5. superpowers / ponytail / caveman / claude-skills との違い — スキルの“5系統”

emilkowalski/skills の位置づけは、他のAgent Skillと並べると際立ちます。「エージェントに何を注入するか」という切り口で並べてみましょう。

こう並べると、Agent Skill は「何を注入するか」で少なくとも 5つの系統に分けられることが見えてきます。プロセスの規律（superpowers）、コードを最小化する振る舞い（ponytail）、出力の圧縮（caveman）、文書を生産する汎用能力（公式の claude-skills）、そして ドメインのセンス（emilkowalski/skills）です。前の4つが“働き方”や“能力”に関わるのに対し、emilkowalski/skills だけは 一人の専門家の美的判断そのものを注入しようとしている点で毛色が違います。

この“5系統”という整理は、Agent Skill をどう選ぶかを考えるときの地図にもなります。チームの課題が「実装が雑・手順が我流」ならプロセス規律、「コードが多すぎてレビューが重い」ならコード最小化、「AIの返答が冗長でトークンがかさむ」なら出力圧縮、「文書やレポートの自動生成が欲しい」なら汎用能力が候補になります。そして「動きや見た目の“詰めの甘さ”が気になる」ときに効くのが、ドメインのセンスを注入する emilkowalski/skills です。注入する層が異なるので、これらは競合というより重ねて使えるものだと捉えるのが自然でしょう。

13本に増えたいま、使い分けはこう整理できます。

・新しいUIコンポーネントを設計・磨き込みたい → emil-design-eng
・アニメーションをゼロから作る → animate（React Native なら animate-expo）
・既存のアニメーションを1本ずつ厳しく点検 → review-animations
・コードベース全体をまとめて底上げ → improve-animations（監査→計画→安いモデルで実行）
・そもそもどこを動かすべきか分からない → find-animation-opportunities
・動きを言葉にできず指示に詰まった → animation-vocabulary
・Apple 的な“生きた”操作感をWebで再現 → apple-design
・Webアプリをスマホでネイティブらしく → mobile-native
・Swift を書く → write-swift
・ライブラリ選びをAIに任せたくない → pick-ui-library
・複数案を並べて決めたい → prototype

13本とも入れておいても、常駐は1,443トークン。入れっぱなしのコストは実測で無視できる水準なので、迷ったら全部入れて、呼ぶときに選ぶ運用で構いません。

まとめ — emilkowalski/skills が指し示すもの

emilkowalski/skills は、「AIにセンスはない」という一点を出発点に、sonner・vaul の作者が Vercel と Linear で培った専門性をSKILL.mdへ凝縮したリポジトリです。初出時の5本（哲学・審判・計画・語彙・Apple流モーション）はいまも中核として残り、そこへ実装・発見・比較・道具選び、そしてSwiftとReact Nativeというネイティブ側の8本が加わって、合計13本・198,894バイトになりました。最大のSKILL.mdがSwiftになったという事実は、このリポジトリが「Webアニメーションの心得集」から「デザインエンジニアの仕事全域の判断基準」へ広がったことを端的に示しています。

運用面では、13本入れても常駐は1,443トークン。description だけを先に読ませて関連性を判定するプログレッシブ・ディスクロージャと、本体より大きい参照ファイルを外に出す構成、そして自動起動を切る3本——この設計のおかげで、物量が増えても入れっぱなしのコストはほとんど増えません。Skill集を設計する側にとっても、この「薄い本体＋厚い参照＋起動スイッチとしての description」という型はそのまま応用できます。

視点を引いて見れば、このリポジトリが投げかけているのは「専門性は、どこまで形式知にできるのか」という問いです。センスや職人性は、これまで“その人にしか持てないもの”として扱われがちでした。しかし判断のルールを丁寧に書き出せば、その一部はファイルとして手渡せます。渡された側（AI）が完璧に再現できるかは別として、少なくとも“外し方”を減らすことはできる。自分の判断を言語化してSkillにする作業は、他人やAIに渡すためだけでなく、自分自身が何を根拠に判断しているのかを見つめ直す機会にもなります。3か月で⭐が4倍に増えたのは、その手応えを多くの人が共有したからでしょう。

参照ソース

• emilkowalski/skills — GitHub リポジトリ（2026-10-01 に main を clone して計測）
• Emil Kowalski — Skills（skill 紹介ページ）
• Agents with Taste — Emil Kowalski のエッセイ
• animations.dev — Emil Kowalski のアニメーション講座
• skills.sh — Agent Skills のコミュニティ・レジストリ / インストーラ