frontend-design

フロントエンドデザイン

汎用的な AI らしさを避けながら、個性があり、本番環境に適したフロントエンドインターフェースを作成するためのガイドです。このスキルでは、既存の状態を把握し、デザインを計画し、意図を持って構築し、見た目を検証するまでのライフサイクル全体を扱います。

優先順位

このスキルのルールはすべて、必須事項ではなくデフォルトです。

1. 既存のデザインシステム／コードベースのパターン -- 最優先で、常に尊重します
2. ユーザーの明示的な指示 -- スキルのデフォルトより優先します
3. スキルのデフォルト -- 新規開発の場合、またはユーザーがデザインのガイダンスを求めている場合に適用します

既存のパターンが確立されたコードベースで作業する場合は、そのパターンに従ってください。ユーザーがデフォルトと矛盾する方針を指定した場合は、ユーザーの指示に従ってください。

ワークフロー

Detect context -> Plan the design -> Build -> Verify visually

---

レイヤー 0：コンテキストの検出

デザイン作業を始める前に、コードベースを調べて既存のデザインに関する手がかりを確認します。これに基づいて、このスキルの独自のガイダンスをどの程度適用するかを判断します。

確認する項目

• デザイントークン／CSS 変数：--color-*、--spacing-*、--font-* のカスタムプロパティ、テーマファイル
• コンポーネントライブラリ：shadcn/ui、Material UI、Chakra、Ant Design、Radix、またはプロジェクト固有のコンポーネントディレクトリ
• CSS フレームワーク：tailwind.config.*、styled-components のテーマ、Bootstrap のインポート、命名規則が統一された CSS モジュール
• タイポグラフィ：HTML／CSS でのフォントのインポート、@font-face 宣言、Google Fonts のリンク
• カラーパレット：定義済みのカラースケール、ブランドカラーのファイル、デザイントークンのエクスポート
• アニメーションライブラリ：Framer Motion、GSAP、anime.js、Motion One、Vue Transition のインポート
• 間隔／レイアウトのパターン：一貫して使用されている間隔スケール、グリッドシステム、レイアウトコンポーネント

プラットフォーム標準のファイル検索ツールとコンテンツ検索ツール（Claude Code の Glob/Grep など）を使って、これらの手がかりを検索してください。日常的なファイル調査にシェルコマンドを使わないでください。

モードの分類

検出した手がかりに基づいて、モードを選択します。

• 既存システム（複数のカテゴリにわたり 4 つ以上の手がかりがある）：既存システムを優先します。このスキルの美的な見解（タイポグラフィ、色、動き）は、確立されたシステムに従います。構成、コピー、アクセシビリティ、検証に関する構造的なガイダンスは引き続き適用されます。
• 部分的なシステム（手がかりが 1～3 個）：既存のものに従い、規則が見つからない領域にのみスキルのデフォルトを適用します。たとえば、Tailwind が設定されていてコンポーネントライブラリがない場合は、Tailwind のトークンに従いながら、コンポーネント構成にはスキルのガイダンスを適用します。
• 新規開発（手がかりが検出されない）：スキルのガイダンスを全面的に適用します。
• 判断が難しい場合（手がかりに矛盾がある、または不明確な場合）：作業を進める前にユーザーに確認します。

ユーザーへの確認

コンテキストの判断が難しい場合は、プラットフォームのブロッキング型質問ツール（Claude Code の AskUserQuestion、Codex の request_user_input、Gemini の ask_user）を使います。質問ツールを利用できない場合は、「部分的なシステム」モードを想定し、慎重に作業を進めます。

質問の例：「[検出した手がかり] が見つかりました。既存のデザインパターンに従いますか、それとも個性的なデザインを作成しますか？」

---

レイヤー 1：ビルド前の計画

コードを書く前に、短い文を 3 つ書きます。これにより一貫性が生まれ、コードを書く前にユーザーが方向性を修正するための確認ポイントになります。

1. ビジュアルの方針 -- 雰囲気、素材感、エネルギーを説明する 1 文

   • 新規プロジェクトの例：「余白をたっぷりとったクリーンなエディトリアル調。セリフ体の見出しと、彩度を抑えたアースカラー」または「データを前面に押し出した高密度のダッシュボード。等幅フォントのアクセントと、暗い面による階層構造」
   • 既存のコードベース：既存の美的スタイルと、新しい作業でそれをどう発展させるかを説明します

2. コンテンツ計画 -- ページに何をどの順番で配置するか

   • ランディングページ：ヒーロー、サポート、詳細、CTA
   • アプリ：主要なワークスペース、ナビゲーション、補足コンテキスト
   • コンポーネント：どのような状態があり、何を伝えるか

3. インタラクション計画 -- 印象を変える具体的な動きのアイデアを 2～3 つ

   • 「アニメーションを追加する」ではなく、「ヒーローの読み込み時に段階的にフェードイン、セクション間のスクロールに合わせた視差効果、カードのホバー時に拡大」
   • 既存のコードベースでは、既存のモーションライブラリを使って、追加するインタラクションだけを説明します

---

レイヤー 2：デザインの基本指針

これらの原則は、すべてのコンテキストタイプに適用されます。優先順位に従い、既存のデザインシステムとユーザーの指示が優先されます。

タイポグラフィ

• 個性が際立つ、印象的なフォントを選びます。既存のコードベースで使われている場合を除き、よくあるフォント（Inter、Roboto、Arial、システム標準フォント）は避けます。
• 明確な理由がない限り、書体は最大 2 種類にします。ディスプレイ／見出し用フォントと本文用フォントを組み合わせます。
• レイヤー 0 で既存のフォントが検出された場合は、そちらを優先します。

色とテーマ

• CSS 変数を使って、一貫性のあるパレットを設定します。控えめで均等に分散したパレットより、支配的な色と鮮やかなアクセントの組み合わせが効果的です。
• 白地に紫を基調とすることや、ダークモードを前提にすることは避けます。コンテキストに応じてライトとダークを使い分けます。
• プロダクトにすでに複数色のシステムがある場合を除き、アクセントカラーはデフォルトで 1 色にします。
• 検出された既存のカラートークンを優先します。

構成

• コンポーネントではなく、構成から始めます。最初のビューポートは文書ではなくポスターとして扱います。
• ボーダー、シャドウ、カードなどの装飾を加える前に、余白、配置、スケール、トリミング、コントラストを活用します。
• デフォルトではカードを使わないレイアウトにします。ユーザーのインタラクションを収める役割がある場合（クリック可能な項目、ドラッグ可能な単位、選択可能なオプション）はカードを使えます。カードのスタイルを取り除いても理解しやすさが損なわれないなら、カードにすべきではありません。
• 構成に関するルールはすべてデフォルトです。ユーザーはこれらを上書きできます。

モーション

• 視覚表現が中心となる作業では、意図的な動きを 2～3 つ実装します。登場時のアニメーション、スクロール連動または奥行き効果、ホバーまたは表示切り替えのトランジションを 1 つずつ用意します。
• プロジェクトに既存のアニメーションライブラリがあれば、それを使用します。
• 既存のライブラリが見つからない場合は、フレームワークに応じて次のデフォルトを使います。
  • CSS アニメーション：汎用的な基本選択肢
  • Framer Motion：React プロジェクト
  • Vue Transition / Motion One：Vue プロジェクト
  • Svelte transitions：Svelte プロジェクト
• 動きは短い録画でもはっきり分かり、モバイルでも滑らかで、ページ全体で一貫している必要があります。装飾目的にすぎない場合は削除します。

アクセシビリティ

• デフォルトではセマンティック HTML を使います。何でも div にするのではなく、nav、main、section、article、button を使います。
• WCAG AA の最低基準を満たす色のコントラストを確保します。
• すべてのインタラクティブ要素にフォーカス状態を設けます。
• 適切に実装すれば、アクセシビリティと美しさは両立できます。

画像

• 画像が必要な場合は、抽象的なグラデーションや偽の 3D オブジェクトより、実写またはリアルな写真を優先します。
• テキストを重ねる領域の色調が安定した画像を選ぶか、生成します。
• 環境で画像生成ツールを利用できる場合は、プレースホルダーのストック画像ではなく、コンテキストに合ったビジュアルを作成するために使います。

---

コンテキストモジュール

構築する対象に合ったモジュールを選択します。既存のアプリケーション内で作業する場合は、機能の内容にかかわらず、デフォルトでモジュール C を選択します。

モジュール A：ランディングページとマーケティング（グリーンフィールド）

デフォルトのセクション順序：

1. ヒーロー — ブランド／製品、提供価値、CTA、主役となるビジュアルを1つ
2. サポート — 具体的な機能、オファー、または実績を1つ
3. 詳細 — 雰囲気、ワークフロー、製品の奥行き、またはストーリー
4. 最終CTA — コンバージョン、開始、訪問、または問い合わせ

ヒーローのルール（デフォルト）：

• 1つの構成にします。ダッシュボードにはしません。画面全体に広がる画像か、主役となるビジュアル面を使います。
• ブランドを最初に、見出しを2番目に、本文を3番目に、CTAを4番目に配置します。
• テキスト列は狭く保ち、画像の落ち着いた領域に固定します。
• 明確な理由がない限り、セクション数は合計6つまでにします。
• H1の見出しは1つにします。ファーストビュー内の主要CTAは1つにします。

コピー：

• 見出しに意味を担わせます。補足コピーは通常、短い1文にします。
• デザインの解説ではなく、製品の言葉で書きます。UIにプロンプトの文言やAIについての解説を含めません。
• 各セクションの役割は1つにします。説明、実証、掘り下げ、またはコンバージョンです。
• すべての文に掲載するだけの価値が必要です。コピーは増やすより減らすことを基本にします。

モジュール B：アプリとダッシュボード（グリーンフィールド）

デフォルトのパターン：

• 落ち着いたサーフェスの階層、明快なタイポグラフィと余白、少ない色数、密度が高くても読みやすい情報、最小限の装飾を使います。
• 次の要素を軸に構成します：主要な作業領域、ナビゲーション、副次的なコンテキスト／インスペクター、操作や状態を示す明確なアクセント1色。
• カードは、それ自体がインタラクション要素である場合（クリック可能な項目、ドラッグ可能な単位、選択可能なオプション）のみ使います。意味を損なわずにパネルを通常のレイアウトにできるなら、カードの装飾を取り除きます。

コピー（マーケティングではなく実用性）：

• 価値の訴求、雰囲気、ブランドの語り口よりも、状況の把握、ステータス、操作を優先します。
• セクション見出しには、その領域の内容や、そこでユーザーができることを示します。良い例：「プランのステータス」「検索指標」。悪い例：「可能性を解き放つ」。
• ホームページのヒーローに載せられそうな文は、製品UIらしく聞こえるまで書き直します。
• 判断基準：担当者が見出し、ラベル、数値だけをざっと見ても、ページの内容をすぐに理解できますか？

モジュール C：コンポーネントと機能（既存アプリでのデフォルト）

既存のアプリケーションに追加する場合：

• 既存のビジュアル言語に合わせます。このモジュールの目的は、目立たせることではなく、既存の一部としてなじませることです。
• 周囲のコードで使われている余白のスケール、角丸、カラートークン、タイポグラフィを引き継ぎます。
• インタラクションの品質を重視します。明確な状態（デフォルト、ホバー、アクティブ、無効、読み込み中、エラー）、状態間の滑らかな遷移、ひと目で分かる操作可能性を実現します。
• 新しいコンポーネント1つのために、新たなデザインシステムを導入してはいけません。既存アプリの角丸が4pxなら、8pxのコンポーネントを追加しません。

---

厳守するルールとアンチパターン

デフォルトで避けるもの（上書き可能）

これらは、このスキルの推奨方針です。ユーザーはどれでも上書きできます。

• 最初の印象が、ありきたりなSaaSのカードグリッドになっている
• 紫と白の配色、ダークモードを前提とした設計
• グリーンフィールドの作業で、使われすぎているフォント（Inter、Roboto、Arial、Space Grotesk、システムのデフォルトフォント）を使う
• 統計、スケジュール、ピルの集まり、ロゴの集合で雑然としたヒーローセクション
• 同じ雰囲気を別の言葉で繰り返すセクション
• ストーリー上の目的がないカルーセル
• 複数のアクセントカラーが競合している
• 実際のビジュアルコンテンツの代わりに、装飾的なグラデーションや抽象的な背景を使う
• デザインの解説のように聞こえるコピー（「シームレスな統合を体験してください」など）
• 画像の混雑した側にテキストが配置される、左右分割型のヒーロー

常に避けるもの（品質の最低基準）

ユーザーが誰も望まない、明確な品質上の問題です。

• UIにプロンプトの文言やAIについての解説が漏れ出している
• コントラストの問題 — 画像や背景上のテキストが読めない
• フォーカス状態が視覚的に示されていないインタラクティブ要素
• 適切なHTML要素があるのに、意味のないdivを並べている

リトマスチェック

ビジュアル確認の前に、手短にセルフレビューします。すべてのチェックがあらゆる状況に当てはまるわけではありません。どれが関連するかは判断してください。

• 最初の画面でブランドや製品がひと目でわかりますか？
• 視線を引きつける強力なビジュアル要素が1つありますか？
• 見出しだけを流し読みして、ページの内容を理解できますか？
• 各セクションの役割は1つに絞られていますか？
• カードを使っている箇所で、本当にカードは必要ですか？
• 動きは階層や雰囲気を高めていますか。それとも、ただ付け加えられているだけですか？
• 装飾的なシャドウをすべて取り除いても、デザインに高級感がありますか？
• コピーはプロンプトのようではなく、製品らしい語り口になっていますか？
• 新しい成果物は既存のデザインシステムに合っていますか？（モジュール C）

---

ビジュアル確認

実装後、見た目を確認します。これは簡単なチェックであり、ピクセル単位の精査ではありません。確認は1回だけ行います。明らかな問題があれば修正してください。問題がなければ先に進みます。

ツールの優先順位

最初に利用できる選択肢を使います。

1. 既存のプロジェクト用ブラウザツール — Playwright、Puppeteer、Cypress などがすでにプロジェクトの依存関係に含まれている場合は、それを使います。確認のためだけに新しい依存関係を追加しないでください。
2. ブラウザー MCP ツール — エージェントの環境でブラウザー自動化ツール（例：claude-in-chrome）が利用できる場合は、それを使います。
3. agent-browser CLI — ほかに利用できるものがない場合は、これをデフォルトで使います。インストール方法と使用方法については、agent-browser スキルを読み込んでください。
4. 頭の中でのレビュー — ブラウザーにアクセスできない場合（ヘッドレス CI、インストール権限がないなど）は、リトマスチェックを使ってセルフレビューし、ビジュアル確認を省略したことを記載します。

確認する項目

• 出力はビルド前の計画で定めたビジュアルの方向性に合っていますか？
• 明らかな視覚上の問題（レイアウトの崩れ、読みにくいテキスト、画像の欠落など）はありますか？
• そのコンテキストのモジュールが意図した見た目になっていますか（ランディングページはランディングページらしく、ダッシュボードはダッシュボードらしく、コンポーネントは周囲に調和しているか）？

スコープの管理

反復は1回です。スクリーンショットを撮り、リトマスチェックに照らして評価し、明らかな問題を修正したら先に進みます。納品物（PR の説明、会話の出力など）にスクリーンショットを含めてください。

1回の確認を超える反復的な改善（スクリーンショットの確認と修正を複数回行うこと）については、compound-engineering:design:design-iterator エージェントを参照してください。

---

創造性

このスキルは構成を整えるためのものですが、目指すのはありきたりな AI 生成物ではなく、独自性のある成果物です。

ゼロから作る場合は、大胆な美的方向性を決めてください。雰囲気を検討しましょう。極限までミニマル、マキシマリスト、レトロフューチャー、オーガニック／ナチュラル、ラグジュアリー／洗練、遊び心のあるもの、エディトリアル、ブルータリスト、アールデコ、ソフト／パステル、インダストリアルなど、あるいはコンテキストに合うものを考案してもかまいません。表現の幅は無限にあります。これらをインスピレーションにしつつ、プロジェクトにふさわしいデザインを作ってください。

問いかけてみましょう。何がこのデザインを忘れられないものにするのでしょうか？見る人の記憶に残る、たった1つの要素は何でしょうか？

実装の複雑さは、美的なビジョンに合わせてください。マキシマリストなデザインには、豊富なアニメーションやエフェクトを使った入念なコードが必要です。ミニマリストなデザインには、抑制、正確さ、そして余白、タイポグラフィ、さりげない細部への丁寧な配慮が必要です。エレガンスは、強さではなく、ビジョンを巧みに実現することから生まれます。