attrip. Search
音楽

LATEST BEAT

emilkowalski/skillsをCodexとClaude Codeで使う方法|AIっぽいUIをデザインレビューする

2026.07.10 · 10 MIN READ · 理解の記録

RECORD / 2026

emilkowalski/skills は、CodexやClaude Codeに「デザインをどう判断するか」を渡すスキル集です。

画面を一発で完成させる魔法ではありません。既存のLPやWebサイトを見せて、余白、文字、CTA、モーションの違和感を先に洗い出す。その判断基準をAIへ足すためのものです。

「機能は動く。でも少しAIが作ったように見える」を直したいときに効きます。

emilkowalski/skillsで増えるのはデザインの判断基準

このリポジトリは、Emil Kowalski氏がVercelやLinearで得た経験をもとにした、デザインエンジニア向けのスキル集です。READMEでは、アニメーションやデザインの正解を早く判断するためのものだと説明されています。

たとえばAIは、動きさえすればよいと判断しがちです。

  • 表示アニメーションに ease-in を使う
  • 境界線を濃くしすぎる
  • 影を均一に足してカードを重くする
  • すべての要素を同じ強さで動かす
  • 文字、余白、CTAの優先順位を均す

人が一つずつ見ると小さな差です。でも積み重なると、画面の完成度が下がります。

emilkowalski/skills は、こうした細部をレビュー対象にします。余白、タイポグラフィ、情報の優先順位、見やすさ、操作への反応、モーション、イージング、境界線と影。AIが出しがちな不自然さを、コード変更の前に言語化させるためのものです。

現在公開されている4つのスキル

2026年7月10日時点で、リポジトリの skills/ には4つあります。

  • emil-design-eng:UIの磨き込み、コンポーネント、アニメーション、細部の判断を扱う中心スキル
  • review-animations:モーションコードを厳しくレビューする専用スキル
  • animation-vocabulary:曖昧な動きを、AIやデザイナーに伝えられる名前へ置き換える用語集
  • apple-design:Appleのデザイン原則と、流体的で操作を妨げないモーションをWeb向けに整理したスキル

いきなり全部を使う必要はありません。最初は emil-design-eng でLPをレビューし、動きに課題が出たときだけ review-animations を使うと迷いません。

なお、リポジトリは7月9日にも更新されています。apple-design の追加やREADME更新が続いているため、実行前に必ず公式READMEを確認してください。

CodexとClaude Codeへの導入はREADMEのコマンドから始める

作者がREADMEで案内しているインストールコマンドは、次の1つです。

npx skills@latest add emilkowalski/skills

このコマンド以外の専用インストールコマンドは、2026年7月10日時点のREADMEには書かれていません。

そのため、記事や社内手順に「Codexではこのオプション」「Claude Codeではこのパスへコピー」と推測で固定するのは避けましょう。コマンドを実行したときの案内と、最新READMEを正本にしてください。

Codexで使うとき

Codexは、リポジトリの .agents/skills、ユーザー単位の ~/.agents/skills などからスキルを見つけます。スキルは SKILL.md を中心とするフォルダです。Codexでは、プロンプト内でスキル名を明示するか、内容が説明文と一致したときに自動で選ばれます。

導入後は、まずCodexに利用可能なスキルを確認させます。CLIやIDEでは /skills、または $ でスキルを指定できます。認識されない場合は、Codexを再起動してください。

保存先を手で管理するなら、Codex公式ドキュメントの .agents/skills/<skill-name>/SKILL.md という構成に従います。ただし、これはCodex側の一般仕様です。emilkowalski/skills のREADMEが指定する手動コピー手順ではありません。

Claude Codeで使うとき

Claude Codeは、プロジェクト単位なら .claude/skills/<skill-name>/SKILL.md、個人共通なら ~/.claude/skills/<skill-name>/SKILL.md の構成を読みます。スキルは説明文に合った依頼で自動選択されるほか、/skill-name で明示的にも呼び出せます。

ここでも、まずはREADMEのコマンドを使います。保存先やエージェント選択の表示は、利用しているインストーラーの最新版を確認してください。手作業で導入する場合だけ、Claude Code公式のディレクトリ構成に合わせます。

MITライセンスでも更新内容は確認する

リポジトリはMIT Licenseです。利用、複製、改変、配布はできます。ただし、コピーまたは重要な部分を配布するときは、著作権表示とライセンス文を残す必要があります。無保証でもあります。

そのまま社内標準へ取り込む前に、SKILL.md の指示、更新履歴、ライセンスを確認してください。スキルはAIの出力を保証するものではありません。実装前に差分を読み、テストと画面確認をする責任はプロジェクト側に残ります。

最初は「コードを変えないレビュー」から始める

導入直後に「きれいにして」と頼むと、AIは広い範囲を勝手に変えがちです。

最初はレビューだけに絞ります。対象URL、対象ファイル、変更しない条件を先に渡してください。

このLPをemilkowalski/skillsのデザイン原則を参照してレビューしてください。
余白、タイポグラフィ、視線誘導、CTA、アニメーションの観点から、違和感と改善案を出してください。
コードは変更しないでください。問題を優先度順に整理してください。

次に、AIらしさが残る箇所だけを探させます。

現在のページについて、AIが作ったように見える不自然なUIを探してください。
コードは変更せず、まず問題点を優先度順に整理してください。

ここで重要なのは、改善案を全部採用しないことです。画面の目的とブランドを知っているのは、プロジェクト側です。

実装は効果の高い3項目だけにする

レビューが終わったら、変更範囲を絞ります。

レビュー結果のうち、最も効果の高い3項目だけを実装してください。
ブランドカラー、文章、ページ構成は変更しないでください。
変更前後の差分と、各変更の理由を短く説明してください。

この順番なら、AIはデザイン監督ではなく、限定された実装担当になります。

安全に進めるなら、次の4段階です。

  1. スクリーンショットまたは対象ページを確認させる
  2. コードを変えず、問題を優先度順に出させる
  3. 上位3項目だけを実装させる
  4. 差分、モバイル表示、キーボード操作、prefers-reduced-motion を確認する

特にモーションは、見た目のために足すものではありません。状態変化、操作の結果、移動先をわかりやすくするためにだけ使います。

モーションとインタラクションをレビューしてください。
派手な演出を追加するのではなく、操作の理解を助ける必要最小限のアニメーションを提案してください。

スマートフォンを先に見ると改善点が見つかる

PCでは自然に見える画面も、スマートフォンでは情報の優先順位が崩れます。

スマートフォン表示を中心に確認し、余白、文字サイズ、ボタンの押しやすさ、情報の優先順位を改善してください。
コードは変更せず、問題を重要度順に出してください。

確認するポイントは4つで十分です。

  • 見出しと本文のサイズ差が小さすぎないか
  • CTAが指で押しにくくないか
  • 重要でない装飾が先に目に入っていないか
  • セクション間の余白が、情報のまとまりを壊していないか

「Apple風」「Linear風」は分解して頼む

「Apple風にして」「Linear風にして」だけでは、AIが何を変えるべきか決められません。見た目の模倣にも寄りやすくなります。

代わりに、欲しい判断を分解します。

Apple風という言葉を、特定製品の見た目の模倣ではなく、次の観点に分解してください。
操作直後の反応、控えめなモーション、状態変化のわかりやすさ、余白、文字の読みやすさ、半透明と影の使い方。
このページで実現できる項目だけを提案してください。

apple-design は、AppleのWWDCデザイントークをWebへ翻訳したスキルです。固有の見た目をコピーする指示ではなく、応答性、空間的一貫性、節度、可逆な操作感を検討するために使うのがよいでしょう。

Linear風も同じです。「密度を高める」「境界線を薄くする」「情報の階層を明確にする」「頻繁に見る操作は動かしすぎない」のように、観察できる要件へ分けてください。

動きの名前がわからないときは、animation-vocabulary が役に立ちます。「ポップオーバーが少し弾んで出る動き」のような言葉を、AIが扱える用語に直してから実装を頼めます。

自分専用のdesign-libraryを優先する

emilkowalski/skills だけでは、会社や案件の事情まではわかりません。

役割を分けると、AIの提案がぶれにくくなります。

  • emilkowalski/skills:汎用的なUI品質、モーション、細部の判断基準
  • design-library:配色、語調、ロゴ、コンポーネント、禁止事項など固有のルール
  • プロジェクトのコード:実際に直す対象
  • CodexまたはClaude Code:上の情報を読み、レビューと実装をする役

たとえば、プロジェクトに design-library フォルダがあるなら、こう頼みます。

emilkowalski/skillsのデザイン原則と、プロジェクト内のdesign-libraryフォルダを参照してください。
一般的なUI品質はスキルを基準にし、配色、ブランド表現、禁止事項は自社のデザインライブラリを優先してください。
まずコードを変えず、競合するルールと改善候補を優先度順に整理してください。

この優先順位が大切です。スキルは汎用的な物差しです。ブランドを決めるものではありません。

画面を直す前に、AIへレビュー基準を渡す

emilkowalski/skills は、AIにセンスを魔法のように与える道具ではありません。

それでも、何を見て、どこを疑い、どんな動きを避けるかを先に渡せます。だから「それっぽいけれど惜しいUI」を、感覚だけに頼らず直しやすくなります。

まずは1枚のLPで、コードを変えないレビューから試してください。改善項目を3つに絞って実装し、モバイル表示で見直す。この小さな往復が、AIに画面を丸投げするよりずっと安全です。

参考リンク

コメントを残す