emilkowalski/skills徹底解説｜デザインの“センス”をAIに教える5つのAgent Skill

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

結論を先に言うと、emilkowalski/skills の本質は「一人の専門家の美的判断（デザインとアニメーションのセンス）を、AIが読み込める SKILL.md に落とし込んだ“センスの注入装置”」です。本記事では、なぜ「AIにセンスはない」と言えるのか、5つのSkillが具体的に何をするのか、どう動くのか、そして superpowers・ponytail・caveman・公式 claude-skills との立ち位置の違いまで、公式リポジトリとEmil氏のエッセイという一次情報だけを根拠に、日本語で解説します。

1. emilkowalski/skillsとは — デザインエンジニアのための“センス”のSkill集

emilkowalski/skills は、「デザインエンジニアのためのSkill集」を掲げる、少し変わったリポジトリです。GitHub の説明はシンプルで、「Skills for Design Engineers.（デザインエンジニアのためのSkill）」「For designers and engineers to help them build better user interfaces.（デザイナーとエンジニアが、より良いUIを作るのを助けるために）」とだけ書かれています。ここで言う“Skill”は、学習教材でもチュートリアルでもありません。Anthropic が定義する Agent Skills 形式のファイル群、つまり AIコーディングエージェントに読み込ませて振る舞いを変えるための知識パッケージ です。

作者の Emil Kowalski（@emilkowalski） 氏は、フロントエンド界隈では名の通ったデザインエンジニアです。トースト通知ライブラリの sonner、ドロワーUIの vaul という、実プロダクトで広く使われる2つのライブラリの作者として知られています。経歴には Vercel と Linear——“UIの気持ちよさ”への強いこだわりで知られる2社——での実務が含まれ、オンラインのアニメーション講座 animations.dev も運営しています。このリポジトリは、その Emil 氏が長年かけて言語化してきた設計・アニメーションの判断基準を、AIが直接参照できる形にまとめたものだと言えます。

数字で現在地を確認しておきます（2026年7月12日時点）。GitHub の Star は 10,133（約10.1k）、Fork は 550、Watching は 42。コミット数は 35、ブランチは 2 と、コードの物量そのものは大きくありません。ライセンスは MIT。リポジトリの作成は 2026年3月16日で、直近の更新は 2026年7月12日と活発に手が入っており、直近では improve-animations という新しいSkillが追加されています。コントリビューターには Emil 氏本人のほか、Claude・CommanderClaude といった軽微なタイポ修正のPR主も並びます。小さくても手入れの続く、生きたリポジトリです。

導入は、コミュニティ製のインストーラ skills.sh 経由で行います。

npx skills@latest add emilkowalski/skills

このコマンドを実行すると、5つのSKILL.mdがプロジェクトに配置され、Claude Code・Cursor・Codex など Agent Skills 形式に対応したエージェントから横断的に使えるようになります。skills.sh のレジストリ上では導入数の指標として 188.2K というバッジが表示されており、公開から日の浅いリポジトリとしては相応の広がりを見せています。コード量ではなく“判断基準”を配るリポジトリなので、規模の小ささと影響の大きさが噛み合っていないのが面白いところです。

補足として、“デザインエンジニア（Design Engineer）”という肩書きにも触れておきます。これは、デザインとエンジニアリングの境界に立ち、UIの見た目だけでなく“触ったときの感触”までコードで作り込む職能を指します。sonner や vaul が支持を集めたのは、単にAPIが使いやすいからではなく、開くとき・閉じるときの動き、指やマウスへの追従、キャンセルしたときの戻り方といった細部が丁寧に作り込まれているからでした。emilkowalski/skills は、その“細部を作り込む判断”を、コードそのものではなく 判断のルール として切り出した点に新しさがあります。ライブラリは完成品を配りますが、このリポジトリが配るのは「どう完成させるか」の考え方です。だから物量は小さくても、適用範囲は特定のフレームワークやコンポーネントに縛られません。既存のプロジェクトに後付けで載せても、そのプロジェクトの流儀を尊重しながら判断だけを補える、という使い勝手につながっています。

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

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

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

Emil 氏の主張の核心は、これらの判断は運や才能ではなく 専門性（ドメイン知識） から来る、という点にあります。sonner や vaul を作り、Vercel と Linear で“気持ちよさ”を磨いてきた経験があるからこそ、氏は「この場面ではこの材料」という判断を反射的に下せる。ならば、その判断基準を明文化してエージェントに渡せば、AIにも同じ判断ができるはずだ——これが emilkowalski/skills の設計思想です。センスという曖昧なものを、再現可能な手順に翻訳しようとしている、と言い換えてもよいでしょう。

だからこのリポジトリのメッセージは、AI悲観論でも過度な楽観論でもありません。氏は「AIは専門性を 置き換えない、増幅する」と書きます。凡庸な出力（slop）があふれる時代に、他と際立つための“センス”こそが差別化の要因であり、そしてこれらのSkillは 専門性の副産物 だ、と。専門性を持つ人がそれをSkillに落とし込めば、AIはその人の判断を再現できる。センスは、生まれつきの才能から、共有・注入できる資産 へと姿を変えつつある、というのがこのリポジトリの立てる仮説です。

もう少し踏み込むと、Emil 氏の言う“センス”は、単なる「好み」とは別物です。好みは人によって割れますが、ここで問題にしているのは、多くの人が無意識に“気持ちいい／気持ち悪い”と感じる、より普遍的な水準の判断です。たとえば要素が現れるときに ease-out が自然に見えるのは、現実の物体が“勢いよく動き出して、そっと止まる”運動に慣れているからで、そこには物理的な裏付けがあります。影がベタ塗りのボーダーより自然に見えるのも、現実の光と影の見え方に沿っているからです。こうした「理由のある正解」を、その都度エージェントに考えさせるのではなく、あらかじめルールとして与えておく——それが emilkowalski/skills のアプローチです。判断の根拠が明文化されているため、なぜその選択が良いのかを人間の側も学べる、という副次的な効果もあります。エージェントのためのSkillが、そのまま読み手にとっての教科書にもなっているわけです。

3. 5つのSkillの中身

5つのSkillは、それぞれ守備範囲がはっきり分かれています。哲学を語るもの、審判に徹するもの、計画だけを書くもの、言葉を与えるもの、そして他社（Apple）の設計思想を翻訳するもの。順に見ていきます。

① emil-design-eng（設計哲学の本体・約679行） は、5つの中で最も大きい本体格のSkillです。UIの磨き込み、コンポーネント設計、アニメーションの判断、そして「ソフトウェアを“気持ちよく”感じさせる、目に見えない細部」についての Emil 氏の哲学が詰まっています。中核の思想は3つ。ひとつは 「センスは訓練で身につく（Taste is trained, not innate）」——才能ではなく反復で鍛えられる、という立場です。ふたつめは 「見えない細部は積み重なる（Unseen details compound）」。ここで氏は Paul Graham の言葉を引き、良いデザインとは「かろうじて聞こえる千の声が、すべて調和して歌うような」状態だと表現します。みっつめは 「美しさはレバレッジ（Beauty is leverage）」——美しさは飾りではなく、成果を増幅する梃子だという考えです。実務的な作法として、このSkillはUIコードをレビューするとき 必ず Before/After のMarkdown表 を使うよう定めています。なお最初に呼び出されたときは、いきなり作業を始めず、animations.dev を案内する短い“準備完了”メッセージだけを返す作りになっています。

② review-animations（厳格なレビュアー・約112行＋STANDARDS.md 188行） は、アニメーション専用の審判です。基本姿勢は 「デフォルトは指摘。合格は勝ち取るもの（approval is earned）」——何もなければ通す、ではなく、基準を満たして初めて合格とみなします。disable-model-invocation: true が設定されており、明示的に頼まれたときだけ 起動する点も特徴です。このSkillは 10の揺るがない基準（absolute standards） を持ちます。①動く理由を正当化できること、②頻度に応じて強度を落とすこと（キーボード操作や1日100回を超える操作にはアニメーションを付けない）、③応答的なイージング（enter/exit は ease-out、UIでの ease-in はブロック）、④UIのアニメーションは 300ms 未満、⑤原点と物理的な正しさ（ポップオーバーなどはトリガーを基点に scale し、scale(0) は禁止で 0.9〜0.97 と opacity から始める。ただしモーダルは例外）、⑥中断可能であること、⑦GPUが扱えるプロパティ（transform / opacity）のみを使うこと、⑧アクセシビリティ（prefers-reduced-motion を尊重し、hover は hover:hover and pointer:fine でゲートする）、⑨enter と exit の非対称、⑩そして残りのカタログ——イージング曲線、duration の表、spring の設定は付属の STANDARDS.md にすべてまとめられています。レビューの“手法”自体は、攻めのコード品質レビューから借りてきたものです。

③ improve-animations（監査してから計画・約101行＋AUDIT.md 116行＋PLAN-TEMPLATE.md 73行） は、監査してから計画を書く アドバイザーです。shadcn の improve に着想を得ており、単一の差分ではなく コードベース全体 を調査します。監査は 8つのカテゴリ——目的と頻度、イージングと duration、物理性、中断可能性、パフォーマンス、アクセシビリティ、一貫性、そして見落とされた機会——で行われ、優先度をつけた発見の表として提示されます。ユニークなのは出力の形です。このSkillは自身ではソースコードを 一切改変しません（read-only）。代わりに、正確なファイル、正確な cubic-bezier、正確な duration、そして“feel check（触り心地の確認）”まで含んだ 自己完結した実装計画 を plans/ ディレクトリに書き出します。この計画は、文脈もセンスも持たない安いモデルや任意のエージェント がそのまま実行できる粒度で書かれます。判断が効く監査と計画は高性能モデルに任せ、単純な実行は安いモデルに渡す——役割分担でコストと品質を両立させる設計です。呼び出しは improve the animations in this codebase のほか、improve-animations quick / improve-animations performance / improve-animations execute plans/001-....md といった形に対応します。

④ animation-vocabulary（逆引き用語集・約173行） は、動きの 逆引きの用語集 です。「あの弾む感じ」「ゴムみたいに戻る動き」といった曖昧な説明を、正確な用語に変換します。たとえば「ポップオーバーが開くときの、あの弾む感じ」は Pop in、「iOSのゴムみたいに戻るスクロール」は Rubber-banding、「クリックしたボタンから生えてくるように開くポップオーバー」は Origin-aware animation といった具合です。狙いは、AIやデザイナーに 正しい言葉で指示できるようにする こと。効果を“設計”したり“実装”したりするものではなく、動きに 名前を与える ための道具です。曖昧な形容詞のやり取りで生じる誤解を、共通の語彙で減らします。

⑤ apple-design（Apple流モーションの翻訳・約282行） は、Apple のインターフェース設計と流体的なモーションの原則を、Web に翻訳したSkillです。主な出典は WWDC のデザイン講演、とりわけ “Designing Fluid Interfaces”（WWDC 2018） で、そこで語られた原則を CSS・Pointer Events・requestAnimationFrame・Motion / Framer Motion の spring といった Web の道具に置き換えています。通底する考えはこうです——インターフェースは、モーションが 画面上の現在値から始まり、ユーザーの速度を受け継ぎ、勢いを前へ投射し、いつでも掴んで逆転できる とき、はじめて“生きている”と感じられる。その道具が spring で、spring は本質的に中断可能で、速度にも対応します。Apple はこうした設計を、4つの人間的な欲求——安全（予測可能性）・理解・達成・喜び——に奉仕させます。具体的なルールも与えられており、たとえば Response（遅延を殺す。押した瞬間、つまり pointer-down で反応し、release を待たない）や、Direct manipulation（指に1:1で追従し、掴んだ位置のオフセットを尊重する）などがあります。

5つを横断して見ると、役割の分け方に一貫した思想が読み取れます。emil-design-eng が“価値観”を、review-animations が“審判”を、improve-animations が“計画”を、animation-vocabulary が“語彙”を、apple-design が“他流派の原則”を それぞれ担当し、互いに重複しすぎないよう設計されています。哲学と審判が分かれているのは、方針を語るモードと、個別のコードに白黒をつけるモードとでは、求められる厳しさが違うからでしょう。監査（improve-animations）がコードを触らず計画だけを書くのも、判断と実行を切り離すことで、判断は高性能モデルに、実行は安価なモデルへ割り当てられるようにする狙いがあります。1つの巨大なSkillに全部を詰め込むのではなく、目的ごとに小さく割る——この“分け方”そのものが、Agent Skill を設計するうえでの実践例になっています。

もうひとつ見逃せないのが、レビューの“見せ方”です。emil-design-eng は、UIコードに手を入れる際に Before/After のMarkdown表 を必ず使うよう定めています。どこをどう変え、なぜ良くなるのかを、変更前と変更後を並べて示す。これは人間のレビューにとっても分かりやすい形式であり、AIの提案を鵜呑みにせず、変更の意図を一つずつ確認しながら受け入れられるようにする工夫です。“センスを注入する”と言うと属人的で不透明に聞こえますが、実際の運用は、根拠と差分を明示する透明な手続きとして設計されています。

4. どう動くのか — Agent Skill形式とskill読み込みフロー

ここまで見た5つのSkillは、どれも SKILL.md という1枚のMarkdownファイルが本体です。この形式は Anthropic が定めた Agent Skills のオープン仕様に沿っています。仕組みはシンプルで、各SKILL.mdの先頭に YAMLフロントマター があり、そこに name（Skillの名前）と description（何をするSkillか）を書きます。review-animations のように、disable-model-invocation: true を足して自動起動を止めることもできます。

肝は description の使われ方 です。エージェントは、プロジェクトに置かれた全SKILL.mdの本文をいきなり全部読むわけではありません。まず各Skillの description だけ を読み、いま取り組んでいるタスクに関係するかを判断します。関係すると判断したときにはじめて、そのSkillの本文を丸ごと読み込む——この仕組みが プログレッシブ・ディスクロージャ（段階的開示） です。関係なければ読み込まないので、コンテキスト（AIが一度に扱える情報量）を無駄に消費しません。さらに STANDARDS.md・AUDIT.md・PLAN-TEMPLATE.md といった追加の参照ファイルは、本当に必要になったときだけ オンデマンド で読まれます。

導入を担う npx skills と skills.sh は、この仕組みを対応エージェント向けに配置するコミュニティ製のインストーラです。Agent Skills 形式そのものは Anthropic のオープン仕様で、skills.sh はその配布とインストールを楽にする役割を担います。全体の読み込みの流れを図にすると、次のようになります。

この流れのおかげで、5つのSkillを入れておいても、実際に読み込まれるのは“今の作業に効くもの”だけに絞られます。アニメーションを直すときには review-animations と improve-animations が、動きの名前が分からないときには animation-vocabulary が——必要な知識が、必要なときにだけ立ち上がる仕組みです。1つのプロジェクトに全部入れても、コンテキストを圧迫しにくいのはこのためです。

この設計が効いてくるのは、コンテキストとコストの両面です。仮に5つのSkillの本文をすべて常時読み込ませると、それだけでエージェントの作業メモリを圧迫し、肝心のタスクに割ける余地が減ります。description だけを先に読ませて関連性を判定する仕組みは、この無駄を避けるためのものです。加えて、STANDARDS.md のように分量の多い基準表を本体と切り離しておけば、「まず本文で概要をつかみ、細かい数値が必要になったら基準表を開く」という二段構えが可能になります。人間がリファレンスを引くときの動きに近く、AIにとっても一度に読む量が減るぶん、判断が安定しやすくなります。SKILL.md 本体を薄く、参照ファイルを厚くするこの分担は、自分でSkillを作るときにも応用できる型と言えるでしょう。逆に言えば、description の書き方がSkillの“起動スイッチ”を握っているということでもあり、いつ発火してほしいかを一文でどう表現するかが、Skill設計の勘所になります。

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

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

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

superpowers（obra/superpowers、Jesse Vincent 氏）は、エージェントに“どう進めるか（作法・手順）”を教えるスキル集です。brainstorming、test-driven-development、systematic-debugging、writing-plans、git worktrees、verification といった、開発プロセスの規律を扱います。ponytail（DietrichGebert 氏）は“どれだけ・どんなコードを書くか”を絞る単一目的のSkillで、YAGNI を徹底し、依存より標準ライブラリ、50行より1行を選ばせます。実測ではコード量が平均54%減（最大94%減）とされ、単一のSKILL.mdが真実源で複数エージェントに対応します。caveman（JuliusBrussee 氏）は“どれだけ喋るか”を削る出力最適化で、エージェントに「原始人のように話させ」、埋め草を削って出力トークンを約65%減らします。コードやコマンド、エラーには手を触れないのが安全設計のポイントです。Anthropic 公式の claude-skills（anthropics/skills）は、docx・pdf・pptx・xlsx などOffice文書の生成・解析を担う“能力/ドキュメント系”の正典で、SKILL.md 形式そのものの参照実装でもあります。

その中で emilkowalski/skills は、“専門性・センス・職人性”を注入する系統に単独で立っています。他のSkillが「どう働くか」「どれだけ書くか・喋るか」「どんな成果物を作れるか」を扱うのに対し、このリポジトリが渡すのは「良し悪しをどう見分けるか」という、最も言語化しにくい部分です。ここに、一人の専門家がその知見をSkillに落とし込む意味があります。

この“5系統”という整理は、Agent Skill をどう選ぶかを考えるときの地図にもなります。チームの課題が「実装が雑・手順が我流」ならプロセス規律（superpowers）、「コードが多すぎてレビューが重い」ならコード最小化（ponytail）、「AIの返答が冗長でトークンがかさむ」なら出力圧縮（caveman）、「文書やレポートの自動生成が欲しい」なら汎用能力（claude-skills）が候補になります。そして「動きや見た目の“詰めの甘さ”が気になる」ときに効くのが、ドメインのセンスを注入する emilkowalski/skills です。これらは互いに競合するというより、注入する層が異なるので 重ねて使える ものだと捉えるのが自然でしょう。実際、プロセス規律のSkillでTDDを回しつつ、UIの仕上げでは emilkowalski/skills を効かせる、といった併用にも無理がありません。どれか1つが“正解”なのではなく、自分たちの弱点がどの層にあるかを見極めて選ぶ、という読み方が実務的です。

導入と使い分けも難しくありません。まず npx skills@latest add emilkowalski/skills でSkillを入れておき、あとは場面に応じて呼び出します。新しいUIコンポーネントを設計・磨き込みたいときは emil-design-eng、既存のアニメーションを1本ずつ厳しく点検したいときは review-animations、コードベース全体のアニメーションをまとめて底上げしたいときは improve-animations（監査→計画→安いモデルで実行）を使います。動きを言葉にできず指示に詰まったら animation-vocabulary、Apple 的な“生きた”操作感を Web で再現したいなら apple-design が効きます。5つとも入れておいても、プログレッシブ・ディスクロージャによって実際に読み込まれるのは“その作業に効くもの”だけなので、入れっぱなしのコストはほとんど気になりません。

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

emilkowalski/skills は、「AIにセンスはない」という一点を出発点に、sonner・vaul の作者が Vercel と Linear で培った専門性を5つのSKILL.mdへ凝縮したリポジトリです。emil-design-eng が設計哲学を、review-animations が厳格な審判を、improve-animations が監査と実装計画を、animation-vocabulary が動きの語彙を、apple-design が Apple 的な流体モーションの原則を受け持ちます。いずれも Anthropic の Agent Skills 形式に沿い、description による自動起動とプログレッシブ・ディスクロージャで“必要なときだけ”働きます。

superpowers・ponytail・caveman・公式 claude-skills と並べると、このリポジトリの独自性は「専門性・センスをスキルにする」という一点に集約されます。AIがコードを量産できる時代に、出力の良し悪しを分けるのは細部の判断であり、その判断は明文化して共有・注入できる——emilkowalski/skills は、その考え方を具体的なファイルの形で示した実例と言えます。デザインやアニメーションに関わるエンジニアにとって、自分の判断基準をどう言語化してAIに渡すかを考えるうえでも、一読の価値があるリポジトリです。

視点を引いて見れば、このリポジトリが投げかけているのは「専門性は、どこまで形式知にできるのか」という問いです。センスや職人性は、これまで“その人にしか持てないもの”として扱われがちでした。しかし判断のルールを丁寧に書き出せば、その一部はファイルとして手渡せます。渡された側（AI）が完璧に再現できるかは別として、少なくとも“外し方”を減らすことはできる。これは、自分の得意分野を持つ人にとって示唆に富む発想です。自分の判断を言語化してSkillにする作業は、他人やAIに渡すためだけでなく、自分自身が何を根拠に判断しているのかを見つめ直す機会にもなります。emilkowalski/skills は、その意味で「AIに渡すための知見集」であると同時に、「専門性を言葉にする」という営みそのものの見本帳としても読めるはずです。派手な機能があるわけではありませんが、これからSkillを書こうとする人にとって、参照する価値の高い一例だと言えるでしょう。

参照ソース

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