frontend-design

フロントエンドデザイン

これはビジュアルデザインのガードレールとなるスキルであり、ドメインワークフローのスキルではありません。必要なプロダクト構成、用語、ワークフロー、出力ビューはドメインスキルが定めます。このスキルはビジュアル品質を担い、その構成の中で適用する必要があります。

必須のリファレンス

ビジュアルの計画や実装に着手する前に、以下の両方のファイルを読んでください。どちらかを省略すると、スキル違反になります。

• .agents/skills/frontend-design/references/visual-style-references.md
• .agents/skills/frontend-design/references/shadcn-setup-and-theming.md

必須のワークフロー

1. 現在のタスク、ドメインコンテキスト、選択したドメインスキルを確認します。
2. .tasks/domain.md が存在する場合は読み込みます。ブランドカラー、会社名、ドメインのトーン、用語、ワークフロー、エンティティ、ステータス、ロール、制約を抽出します。
3. フロントエンドデザインのリファレンスを両方読みます。
4. コーディング前に、以下のデザイン工程を行います。
   • ビジョン：ドメインに即したプロダクトとビジュアルの方向性を定めます。汎用的なSaaSの紫色、カードだらけのダッシュボード、ありきたりな管理画面の構成は避けます。
   • 初期バージョンの機能：動作する画面、コントロール、ルート、ダイアログ、localStorage による状態管理を定めます。
   • デザイントークン：プライマリー、セカンダリー／アクセント、背景、キャンバス、焦点となるコントラスト処理、テキスト、境界線、角丸、コンタクトシャドウ、ステータスカラー、タイポグラフィ、ゆとりのあるスペーシング、カードを使わない構成を定めます。
   • デザインの方向性：ブランドカラーの使用、実際のロゴの使用、ゆとりのあるスペーシング、内側のゆったりとした密度、角丸のコントロール、十分なコントラストの入力欄、柔らかく引き締まったシャドウ、視覚的ノイズの最小化、カードを使わないデフォルト設定、意図的に構成されたデザインを徹底します。選択したドメインスキルで構成が指定されていない場合は、非対称性、計算されたネガティブスペース、鮮やかなアクセントの階層、動き、雰囲気のある背景のディテールなど、より強いビジュアル表現を取り入れます。
5. デザイン準拠ゲートを通過します。
6. 画面の細部を作り込む前に、CSS 変数、Tailwind／shadcn のテーマトークン、関連する shadcn コンポーネントのスタイルを設定します。
7. これらのトークンを使って UI を構築します。適切な箇所では Tailwind を使い、Tailwind では制約がある場合はカスタム CSS クラスを記述します。カスタム CSS では、グローバル CSS 変数、角丸、カラー、シャドウトークンを再利用する必要があります。
8. 完了前の監査を実行し、仕上げる前に修正します。

必ず守ること

• ブランドを最優先：.tasks/domain.md にブランドカラーが指定されている場合は、それを使用します。メインのブランドカラー／アクセントカラーは、主要な操作、アクティブなナビゲーション、選択状態、フォーカス、リンクに割り当てます。相性のよい色合いを基に、ニュートラルなサーフェス、境界線、控えめなテキスト、ステータスカラーを導きます。汎用的な紫や青をデフォルトにしないでください。
• 常に読みやすい前景色に：ブランドカラーは、プライマリ、セカンダリ、アクセント、アクティブ、フォーカスの役割に使用しますが、読みやすさを確保するため、前景色／テキストカラーは別途選びます。ブランドパレットだけでは、すべてのテキストカラーをまかなえないのが一般的です。テキスト、アイコン、ラベル、プレースホルダー、バッジ、ボタン、無効状態、データ値はすべて、実際の背景に対して高いコントラストを保つ必要があります。背景にブランドカラーを使う場合は、別のブランドカラーをそのまま流用せず、読みやすい前景色を導きます。最低限として、WCAG AA の基準である通常のテキストは 4.5:1、大きなテキスト／アイコンは 3:1 を目指します。
• ドメインスキルとの互換性：アプリが CPQ、CRM、建設業など、選択されたビジネス／ドメインスキルに該当する場合は、そのスキルで定められたワークフロー、用語、レイアウト構成に従います。ドメインスキルで指定されていない部分には、汎用的な管理画面に頼るのではなく、このスキルのビジュアルルールと構成ガイダンスを適用します。
• 意図のある構成：どのアプリも、意図を持ってデザインされた印象にします。一貫性のある美的方向性を定め、CSS 変数を一貫して使い、均等に控えめなパレットではなく、主役となる色に鋭いアクセントを組み合わせます。効果の高い場面には動きを取り入れ、ワークフローの明瞭さを損なわない範囲で非対称性や意外性のある構成を活用し、ブランドに調和した背景やビジュアルの細部で雰囲気を作ります。
• 実際のロゴを使う：まず public/brand/logos/ を確認します。そのフォルダーに使用可能なロゴファイルがあれば、ヘッダーまたはアプリの主要な枠組みに、そのフォルダー内の正しいロゴを使用します。ロゴを作成または考案してよいのは、public/brand/logos/ が存在しない場合、または使用可能なロゴファイルがない場合に限ります。
• カードなしをデフォルトに：カードはゼロを目指します。カードなしで UI が成立するなら、カードは使用できません。ページの主要領域を占める、境界線付きの角丸サーフェスは、Card をインポートしていなくてもカードです。カードを使用できるのは、ダイアログ／ポップオーバー／シートの囲い、簡潔な通知、または行・区切り線・トーンの違いでは表現しきれない、真に反復される項目に限ります。
• 最上位にカードを置かない：大きなカードを並べた構成、角丸パネルの積み重ね／グリッド、大きく枠で囲んだヒーロー／詳細コンテナーでメインページを構成しないでください。最上位の構成には、開かれたセクション、トーンの異なる帯、行、区切り線、ワークスペース領域、または開放的な作業領域を使います。
• サイドバーなしをデフォルトに：ユーザーが明示的に求めている場合、または選択されたドメインスキルで明示的に必要とされる場合に限り、サイドバーを使用します。アプリが業務用、ビジネス用、管理画面風、マルチステップ、または複数セクション構成だからといって、サイドバーを追加しないでください。
• ゆとりのある間隔：広めの間隔、余白、行間、セクション間隔を確保します。少し広すぎるのは許容されますが、窮屈で密度が高く、圧縮された UI は失敗です。
• 内側にもゆとりを持たせる：ゆとりは、行、テーブル、リスト、カード、複合コンポーネントの内側にも必要です。すっきりとした積み重ねや、情報に富んだ行レイアウトで呼吸感を出せる場合、1 行に多くの列を詰め込まないでください。内部のコンテンツでは、サブ要素、メタデータ、操作、ラベルの間に十分な間隔を設けます。
• テーブルのリズム：サーフェスを設けるテーブルには shadow-xs を適用し、ヘッダーと行のパディングを広めに取り、行の高さにもゆとりを持たせます。テーブルを窮屈で平坦な、スプレッドシートのような見た目にしないでください。
• 角丸をデフォルトに：選択されたドメインスキルで、よりシャープな角や特定の角丸表現が明示的に求められていない限り、明確に角丸のモダンなシステムを優先します。デフォルトでは、控えめな 4px／6px／8px の管理画面風の角丸を避けます。コントロール、チップ、タブ、主要なサーフェスは、はっきりと角丸にするか、ピル型にします。
• 個性のあるタイポグラフィ：美しく、独特で、印象に残るフォントを選びます。Arial や Inter のような一般的なデフォルトは避けます。プロダクトで対応できる場合は、個性のあるディスプレイ書体と洗練された本文書体を組み合わせます。タイポグラフィで UI の質を高め、スターターアプリのデフォルトのように見せないでください。
• 主役となる作業サーフェスは 1 つに：最初の画面では、明確な業務対象または作業セクション 1 つに焦点を当てます。プロダクト全体を一度に見せようとしないでください。
• 主要領域を枠で囲まない：メインの作業領域、ヒーロー、インスペクター、詳細領域を、大きな境界線付きの角丸パネルにしないでください。開放的なレイアウト、分割行、トーンの異なる帯、区切り線、または補足情報用のドロワー／シートを使います。
• shadcn と CSS はトークンを先に：コンポーネントの作業に入る前に、app.css／グローバル CSS 変数、Tailwind のテーマ値、関連する shadcn コンポーネントのスタイルを設定します。shadcn のデフォルトカラーやコンポーネントスタイルを、そのままデザインとして採用しないでください。shadcn コンポーネントは基本プリミティブにすぎません。アプリのトークン、間隔、コントラスト、角丸、シャドウ、インタラクションルールに合わせて、クラス／スタイルを必ずカスタマイズします。すべてのビジュアル判断に Tailwind を使う必要はありません。CSS 変数とテーマトークンを再利用しつつ、より独自で、ミニマルかつ洗練された UI を実現できるなら、カスタム CSS を記述します。
• 十分なソフトコントラスト：サーフェスを設ける場合は、まずトーン、次に境界線、最後にシャドウでキャンバスと区別します。ほぼ同じ白のサーフェスに薄い境界線を付けるだけでは不十分です。
• 操作可能なサーフェスのコントラスト：編集可能なコントロールはすべて、ひと目でわかるようにします。通常のテキスト入力、セレクト、テキストエリア、コンボボックス、日付フィールド、検索フィールド、コマンドバーのコントロール、shadcn のフォームコントロールはすべて、ライトモードではほぼ白またはごく薄い色合いの背景、ダークモードではほぼ黒の背景にします。セレクトだけを修正して、通常の入力欄をページと同じ色のままにしないでください。コントロールに bg-transparent、bg-background、bg-muted、またはページ／パネルと同じ塗りつぶしを使わないでください。--input は、ライトモードでは --background より明らかに明るく、ダークモードではキャンバスより明らかに暗くする必要があります。検索／フィルター用コントロールは、画面内でも特に明瞭な入力サーフェスにします。
• やむを得ない場合のパネル／カードのコントラスト：サマリーパネル、ライブサマリーカード、インスペクター、通知、反復項目コンテナーなど、カード風のサーフェスが本当に避けられない場合は、ライトモードでははっきりと異なる、ほぼ白またはごく薄い色合いの背景にし、ダークモードではほぼ黒の背景にします。境界線が見えていても、色付きのページ上でパネルの塗りつぶしが同じでは不十分です。
• ヘッダーの扱い：アプリにヘッダー／トップバーがある場合は、ライトモードでは半透明のほぼ白またはごく薄い色合いのサーフェス、ダークモードではほぼ黒のサーフェスにし、backdrop-blur-md とおよそ 70-80% の不透明度を適用します。ヘッダーはページとの十分なコントラストを保ち、使用可能な場合は実際のロゴを使用します。
• 必要な場合のサイドバーの色調と余白：選択されたドメインスキルでサイドバーが必要な場合は、プライマリカラーを基にした、より濃い色をサイドバーの背景または主要なサイドバーサーフェスに使います。ラベル、バッジ、アクティブ状態が収まる十分な幅を確保し、テキストを切ったり、操作要素を端に押し込んだりしないでください。項目のパディングを広めにし、明確な縦方向のリズムを作り、二次的な説明に限って意図的に省略表示します。
• 接触面の奥行きに限定：通常のレイアウトサーフェスに shadow-sm、shadow-md、shadow-lg をデフォルトで使わないでください。ボタンなどの小さな操作要素には shadow-2xs、カード／テーブルなどの囲いのあるサーフェスには shadow-xs、ポップオーバーやバナーには shadow-xl、ダイアログには shadow-2xl を優先します。必要な場合に限り、柔らかく控えめで、接触面に沿った奥行きを使います。柔らかさとは、輪郭が硬く広がらないことを意味します。コントラストのために、シャドウを明確なグレーにしてもかまいません。奥行きは浮き上がりではなく、端の接触として見えるようにします。
• ドメイン固有性：ドメイン名とラベルを入れ替えただけで変わらないような UI にしないでください。

デザイン準拠ゲート

すべての回答が適切になるまで、コーディングを始めないでください。

• .tasks/domain.md を読み、ブランドカラーが記載されている場合は要約しましたか？
• public/brand/logos/ を確認し、ロゴファイルがある場合は実際にそれを使用する計画を立てましたか？
• フロントエンドデザインに関する参照資料を両方読みましたか？
• グローバル CSS 変数、Tailwind/shadcn トークン、shadcn コンポーネントのスタイルをどのように変更するか、具体的に定めましたか？
• ドメインスキルが求める構成に従いつつ、そのスキルで自由度が認められている部分では独自のビジュアル構成を採用していますか？
• 汎用的なシェルではなく、色、動き、空間構成、背景の雰囲気について、意図的な方向性を選びましたか？
• カードを一切使わずにこの UI を構築できますか？できない場合、残すカードは限定的に許可されるケースにすべて該当していますか？
• ページ最上位のカードはありませんか？
• 明示的に求められているか、選択したドメインスキルで必須とされている場合を除き、サイドバーを避けていますか？
• 最初に表示される画面では、タイトル＋フィルター＋KPI ストリップ＋カードグリッド＋テーブルではなく、ひとつの主要な作業領域に焦点を当てていますか？
• 大きく枠で囲まれたヒーロー、詳細、インスペクターの各領域を避けていますか？
• 密集させず、ゆとりのある余白を設けていますか？
• 内部の密度にもゆとりがありますか？行、テーブル、カード、メタデータブロックが窮屈だったり、列が多すぎたりしませんか？
• ドメインスキルで角丸に関する指定がない場合、曖昧なエンタープライズ向けの 4/6/8 の半径ではなく、明確に丸みのある UI になっていますか？
• タイポグラフィは、デフォルトのありふれたものではなく、個性があり、意図的に選ばれた印象ですか？
• サムネイルサイズで見たときに、ページ背景、キャンバス、ナビゲーションのクローム、主要なサーフェスが明確に区別できますか？
• ブランドカラーの領域、無効状態、ラベル、プレースホルダー、バッジ、ボタン、アイコン、ミュートテキストを含め、すべての前景色は背景に対して読みやすいですか？
• 入力欄、検索・フィルター操作部、テーブル、ヘッダー／ナビゲーションのクロームは、ページ背景から十分に色調が区別されていますか？
• ライトモードでは、通常のテキスト入力やセレクトを含むすべての編集可能なコントロールに、ページと同じ色ではなく、ほぼ白または非常に薄い色合いの背景を実際に適用していますか？
• 編集可能なコントロールに bg-transparent、bg-background、bg-muted、ページやパネルと同じトークンによる塗りつぶしを使用していませんか？
• 要約、インスペクター、ライブ要約のパネルには、背景に溶け込まない、ほぼ白または薄い色合いのサーフェスを使用していますか？
• ヘッダー／トップバーがある場合、十分なコントラストを備えた、背景ぼかし付きの明瞭な半透明処理を使用していますか？
• テーブルを表示する場合、shadow-xs を使い、ヘッダーと行にゆったりとしたパディングを設けていますか？
• サイドバーが必要な場合、十分な幅、パディング、行の高さ、オーバーフロー処理を備えた、プライマリーカラー由来の暗めの色調を使用していますか？
• シャドウは接触面の奥行き表現に限定していますか？
• デザインは、このドメインとタスクに固有のものになっていますか？

実装ルール

• サイドバーよりも、トップバー、タブ、セグメントコントロール、パンくずリスト、コマンド行、ステップ形式のフロー、ドロワー、シート、ダイアログ、詳細画面を優先してください。
• カード風のラッパーを追加する前に、余白、タイポグラフィ、区切り線、行、トーンの異なる帯、テーブル、ドロワー、シート、ダイアログ、詳細画面を使えないか検討してください。
• テーブルや行ベースのビューでは、UI にゆとりを持たせて読みやすくできる場合、列数を減らし、行の情報量を増やし、行の高さにゆとりを持たせ、縦方向の積み重ねを明確にすることを優先してください。
• 画面に表示するテーブルでは、通常、境界線だけに頼らず、shadow-xs、ゆとりのあるヘッダーのパディング、ゆとりのある本文行のパディングを使用してください。
• 詳細ビューでは、枠付きパネルを使う前に、インラインの分割レイアウト、選択された行、区切り線、トーンの異なるセクション、ドロワー、シートを優先してください。
• Card コンポーネントをインポートする場合、またはカード風のラッパーが残る場合は、許容されるケースのうち、なぜ避けられないのかを近くにインラインで説明してください。
• 読みやすい UI フォントを使用してください。対象の領域でその雰囲気が明確に求められる場合を除き、タイプライター風やブログ風のフォントは避けてください。
• 必須のワークフロー構成や運用上の明瞭さと衝突しない範囲で、表現力のある構成、より強いアクセントの階層、雰囲気のある背景を取り入れてください。
• すべてを境界線やボックスで囲むのではなく、トーン、余白、階層によって各面を区別してください。
• まずコントラストを確保できる前景色／テキスト色を選んでください。ブランドのプライマリ、セカンダリ、アクセントカラーは、特定の面で明確に読みやすい場合を除き、本文のテキスト色として扱わないでください。
• 入力欄、セレクト、テキストエリア、検索フィールドには、コントラストのある塗りつぶしを明示的に設定してください。透明やページと同じ色のままにしないでください。
• 要約、インスペクター、ライブ要約のパネルが避けられない場合は、コントラストのある塗りつぶしを明示的に設定してください。
• ヘッダー／トップバーがある場合は、トークンに基づく半透明の背景、backdrop-blur-md、明確なコントラストを使用し、単調で同色の帯にしないでください。
• 必須のサイドバーでは、ラベルが読みやすく、アクティブ状態が見え、バッジやアクションが切れないよう、十分な幅と項目の高さを確保してください。
• カードが本当に避けられない場合は、キャンバスとの意図的なトーンの差と、視認できる柔らかな境界線を設けてください。白一色で弱いカードは不適切です。
• 実際のワークフローで必要な shadcn コンポーネントのみを追加してください。
• 入力欄、ボタン、テーブル、タブ、ダイアログ、シート、ポップオーバー、ナビゲーションが、このアプリのビジュアルルールに従うよう、shadcn コンポーネントのクラス／スタイルは必ずカスタマイズしてください。デフォルトのスタイルは使用しないでください。
• Tailwind ユーティリティでは限界がある場合は、レイアウト、背景、余白、コンポーネントの見た目を拡張するカスタム CSS クラスを使用してください。グローバルテーマの var(...) による色、角丸、境界線、シャドウのトークンに基づいたクラスにしてください。
• すべてのボタン、リンク、メニュー、ダイアログ、タブ、フォーム、ルート、localStorage を使用する状態が機能するようにしてください。

完了前監査

実装内で Card、card、bg-card、shadow-md、shadow-lg、shadow-xl、繰り返し使われている rounded-* border ラッパー、および大きな rounded-* border p-* セクションを検索します。

次に該当する場合は却下し、修正してください。

• 最上位のカードが存在する。
• 不要なカードが残っている。
• 大きな角丸の枠線付き領域が、ヒーローカード、インスペクターカード、または詳細カードのように見える。
• ユーザーからの明示的な要望または選択されたドメインスキルの要件がないのに、サイドバーが存在する。
• 最初に表示される画面の大半が、パネル、カード、KPI ブロック、補助ボックス、または同等の重みを持つモジュールで占められている。
• 面の分離が、トーンではなく主に枠線に依存している。
• 同じ白色またはそれに近い色のパネルを多用しているため、主要な面が互いに溶け込んでいる。
• テキスト、アイコン、ラベル、プレースホルダー、無効状態のテキスト、バッジ、ボタンのテキスト、テーブルのテキスト、またはデータ値が、背景に対して読みにくい。
• ブランドカラーを使用しているのに、実際の背景に対して高いコントラストを持つ前景色／テキスト色を設定していない。
• 入力欄、検索／フィルターコントロール、データ行、またはヘッダー／ナビゲーションの外観がページ背景に溶け込んでいる。
• ライトモードの編集可能なコントロールが、ほぼ白色またはごく薄い色合いになっておらず、明確に見えない。
• セレクトコントロールには十分なコントラストがある一方、通常のテキスト入力欄がページと同じ色またはくすんだ色のままになっている。
• 編集可能なコントロールに bg-transparent、bg-background、bg-muted、またはページやパネルと同じトークン／塗り色を使用している。
• 要約／インスペクター／ライブ要約のカードまたはパネルが、ページと同じ塗り色を使用し、ほぼ白色または薄い色合いのコントラストのある面になっていない。
• ヘッダー／トップバーが存在するのに、明確な半透明の backdrop-blur-md スタイルがない、またはページに溶け込んでいる。
• 行／テーブルのコンテンツが窮屈で、列が多すぎる、または最初の列やメタデータブロックの間隔が狭すぎる。
• 表示されるテーブルに shadow-xs がない、またはヘッダー／行のパディングが狭すぎる。
• public/brand/logos/ に使用可能なロゴファイルがあるのに、ヘッダーで理由なくプレースホルダーロゴを使っている、またはロゴを使っていない。
• .tasks/domain.md のブランドカラーが、プライマリ／アクティブ／フォーカス状態のスタイルに反映されていない。
• ワークフロー上、独自の構成が可能なのに、汎用的な管理画面のシェルをデフォルトで使用している。
• 必須のサイドバーに、プライマリカラーをベースにした濃い色ではなく、淡く弱い色の面を使用している。
• 必須のサイドバーで、ラベル、バッジ、アイコン、またはアクションが切れている、あるいは項目のパディング／行の高さが窮屈である。
• ドメインスキルから求められていないのに、特徴のない中間的な角丸のコントロールを使用している。
• プロダクトに適した書体の組み合わせが可能なのに、タイポグラフィが汎用フォントに頼っている、または特徴的な見出し用フォントと本文用フォントを組み合わせていない。
• コンポーネントのスタイリングより先に、テーマ変数を設定していない。
• shadcn コンポーネントを、アプリに合わせたクラスやスタイルによるカスタマイズなしでそのまま使用している。
• カスタム CSS で、グローバルテーマ変数ではなく、その場限りの色／角丸／影をハードコードしている。
• 画面が窮屈に感じられる、またはすべてのモジュールが同じ重みに見える。
• UI がスターター用の管理画面テンプレート、Bootstrap ダッシュボード、または汎用的な AI／SaaS アプリのように見える。