フロントエンドデザイン

これはドメイン・ワークフロー・スキルではなく、ビジュアル・デザインの保護策スキルです。ドメイン・スキルは必須の製品構造、用語、ワークフロー、出力ビューを所有します。このスキルはビジュアル品質を所有し、その構造内で適用される必要があります。

必須参考資料

ビジュアル計画または実装前に、両方のファイルを読むこと。いずれかのファイルをスキップすることはスキル違反です。

• .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 紫色、カードの多いダッシュボード、ジェネリックな admin シェルを拒否します。
   • 初期版機能: 機能するスクリーン、コントロール、ルート、ダイアログ、および 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、工事、または同様のビジネス / ドメイン・スキルに適合する場合、そのスキルの必須ワークフロー、用語、およびレイアウト構造に従います。ドメイン・スキルが指定しないものについては、ジェネリックな admin シェルにフォールバックするのではなく、このスキルのビジュアル・ルールと構成ガイダンスを使用します。
• 作成された構成: すべてのアプリは意図的に設計されたように感じるべきです。一貫性のあるエステティックにコミットし、CSS 変数を一貫して使用し、穏やかに分散されたパレットよりも支配的なカラーと鋭いアクセントを優先し、高い影響を持つ瞬間にモーションを使用し、ワークフロー明確性と矛盾しない場合は非対称または予期しない構成を優先し、ブランド互換性のある背景とビジュアル詳細を通じて雰囲気を構築します。
• 実ロゴを使用: まず public/brand/logos/ を確認します。そのフォルダに使用可能なロゴ ファイルが含まれている場合は、そのフォルダからヘッダーまたはプライマリ・アプリ・クロームで正しい実ロゴを使用します。public/brand/logos/ が存在しないか、使用可能なロゴ ファイルがない場合のみ、ロゴを作成または発明します。
• デフォルトではカードレス: ゼロ・カードを目指します。UI がカードなしで機能する場合、カードは許可されません。メジャー・ページ領域を占有するボーダー付きラウンド・サーフェスは、Card がインポートされていなくてもカードです。カードはダイアログ / ポップオーバー / シート・コンテイメント、簡潔な通知、または行、分割線、またはトーナル分離が失敗したときの真に繰り返されたアイテムに対してのみ許可されます。
• トップレベルのカードなし: メイン・ページを大きな兄弟カードから構成しない、ラウンド・パネルのスタック / グリッド、または大きなフレーム化されたヒーロー / 詳細コンテナ。トップレベルの構造はオープン・セクション、トーナル・バンド、行、分割線、ワークスペース・エリア、または 1 つのオープン・フォーカル・ワーキング・ゾーンである必要があります。
• デフォルトではサイドバーなし: ユーザーが明示的にサイドバーを要求するか、選択されたドメイン・スキルが明示的に要求する場合にのみサイドバーを使用します。アプリが操作的、ビジネス、admin のような、マルチステップ、または複数のセクションを持つため、サイドバーを追加しないでください。
• エアリーなスペーシング: ジェネラスなギャップ、ガター、行リズム、およびセクション・スペーシングを使用します。スペースが少し多すぎることは許可されています。密集した、濃い、または圧縮された UI は失敗です。
• エアリーな内部密度: エアリーさは行、テーブル、リスト、カード、および複合コンポーネント内で継続する必要があります。1 つの行に列が多すぎることを詰め込まないでください。より清潔なスタック化されたまたはより豊かな行レイアウトがより良く呼吸するでしょう。内部コンテンツは、サブ・エレメント、メタデータ、アクション、およびラベル間でジェネラスなギャップを使用する必要があります。
• テーブル・リズム: サーフェス・テーブルを使用する場合、テーブルに shadow-xs を指定し、ジェネラスなヘッダー・パディング、行パディング、およびより高い行リズムを使用します。テーブルは圧縮された、フラット、またはスプレッドシート密集に感じるべきではありません。
• デフォルトではラウンド: 選択されたドメイン・スキルがより鋭い、または特定のラジアス言語を明示的に要求しない場合は、明確にラウンドされたモダン・システムを優先します。デフォルトではおおびかな 4px / 6px / 8px admin ラジアスを避けてください。コントロール、チップ、タブ、および主要なサーフェスは通常、明確にラウンドまたはピル型に感じるべきです。
• 文字のあるタイポグラフィー: 美しい、特徴的で興味深いフォントを選択します。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 ストリップ + カード・グリッド + テーブルではなく、1 つのドミナント・ワーキング・サーフェスにフォーカスしていますか？
• 大きなフレーム化されたヒーロー / 詳細 / インスペクター・サーフェスを避けていますか？
• レイアウトはジェネラスなスペーシングでエアリーで、密集していないですか？
• 内部密度もエアリーですか：行、テーブル、カード、およびメタデータ・ブロックは詰まったまたは過度にカラムされていないですか？
• ドメイン・スキルがラジアス言語をオーバーライドしない場合、UI は曖昧なエンタープライズ 4 / 6 / 8 ラジアスではなく明確にラウンドされていますか？
• タイポグラフィーはデフォルト / ジェネリックではなく特徴的で意図的に感じますか？
• ページ・バックグラウンド、キャンバス、nav クロム、およびの任意のフォーカル・サーフェスはサムネイル・スケールで明確に分離していますか？
• すべての前景カラーはブランド・カラー領域、無効ステート、ラベル、プレースホルダー、バッジ、ボタン、アイコン、およびミュート・テキストを含む背景に対して読みやすいですか？
• インプット、検索 / フィルター・コントロール、テーブル、およびヘッダー / nav クロムはページ・バックグラウンドから十分なトーナル分離がありますか？
• ライト・モードで、通常のテキスト・インプットおよびセレクトを含むすべての編集可能なコントロールが、実際にページ色の塗りつぶしではなくほぼ白色または非常に薄いティント・バックグラウンドを使用していますか？
• 編集可能なコントロールは bg-transparent、bg-background、bg-muted、および同じトークン / ページまたはパネル・塗りつぶしから解放されていますか？
• 要約 / インスペクター / ライブ・サマリー・パネルはページにブレンドするのではなく明確なほぼ白色 / 薄いティント・サーフェスを使用していますか？
• ヘッダー / トップバーが存在する場合、明確な backdrop-blur-md スタイルを持つ、またはページにブレンドしていますか？
• 必須のサイドバーはより暗いプライマリー導出トーンを使用していますか、またはそれでは弱い淡いサーフェスを使用していますか？
• テーブルはサーフェスされていますか？shadow-xs またはそのヘッダー / 行がタイトなスペーシングを失っていますか？
• public/brand/logos/ が使用可能なロゴ ファイルを含んでいますが、ヘッダーはまだ理由のないプレースホルダー・ロゴまたはロゴを使用していないですか？
• .tasks/domain.md からのブランドカラーはプライマリー / アクティブ / フォーカス・トリートメントに反映されていないですか？
• UI はワークフローが許可した場合、作成された構成を使用する代わりにジェネリックな admin シェルにデフォルトしていますか？
• 必須のサイドバーは弱い薄いサーフェスではなく、より暗いプライマリー導出トーンを使用していますか？
• 必須のサイドバーはラベル、バッジ、アイコン、またはアクションをクリップするか、詰まったアイテム・パディング / 行の高さを使用していますか？
• UI は、ドメイン・スキルがそれを要求しない場合でも、曖昧なエンタープライズ中央ラジアス・コントロールにフォールバックしていますか？
• タイポグラフィーはジェネリック・フォントにフォールバックするか、製品が 1 つをサポート出来た場合、特徴的なディスプレイ / ボディ・ペアリングに欠けていますか？
• テーマ変数はコンポーネント・スタイリング前に構成されていないですか？
• shadcn コンポーネントはアプリ固有のクラス / スタイル・カスタマイズなしで使用されていますか？
• カスタム CSS はグローバル・テーマ変数の代わりにハード・コードされた 1 回限りの色 / ラジアス / シャドウを使用していますか？
• スクリーンは詰まったか、またはすべてのモジュールが等しい重みを持っていますか？
• UI はスターター admin テンプレート、Bootstrap ダッシュボード、またはジェネリックな AI / SaaS アプリのように見えますか？

実装ルール

• サイドバーより topbar、タブ、セグメント化されたコントロール、ブレッドクラム、コマンド行、ステップフロー、ドローワー、シート、ダイアログ、または詳細ルートを優先します。
• カード型ラッパーを追加する前に、オープン・スペーシング、タイポグラフィー、分割線、行、トーナル・バンド、テーブル、ドローワー、シート、ダイアログ、または詳細ルートを試してください。
• テーブルと行ベースのビューでは、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 ブロック、ヘルパー・ボックス、またはモジュールの等しい重みです。
• サーフェス分離はボーダーではなく主にボーダーに依存しています。
• 同じ白色またはほぼ白色のパネル化により、メジャー・サーフェスが一緒にブレンドします。
• テキスト、アイコン、ラベル、プレースホルダー、無効テキスト、バッジ、ボタン・テキスト、テーブル・テキスト、またはデータ値は背景に対して読みにくいです。
• ブランド・カラーは実際の背景対応に高いコントラストの前景 / テキスト・カラーを導出せずに使用されます。
• インプット、検索 / フィルター・コントロール、データ行、またはヘッダー / nav クロムはページ・バックグラウンドにブレンドします。
• ライト・モードで編集可能なコントロールはほぼ白色または非常に薄いティント・バックグラウンドではないため、明確に読みません。
• セレクトはコントラストされていますが、通常のテキスト・インプットはページ色またはミュートのままです。
• 編集可能なコントロールは bg-transparent、bg-background、bg-muted、またはページまたはパネルと同じトークン / 塗りつぶしを使用します。
• 要約 / インスペクター / ライブ・サマリー・カードまたはパネルはページと同じ塗りつぶしを使用せずにほぼ白色 / 薄いティント・コントラスト・サーフェスを使用します。
• ヘッダー / トップバーが存在していますが、明確な半透明 backdrop-blur-md スタイルがないか、ページにブレンドしています。
• 行 / テーブル・コンテンツは詰まった、過度にカラムされた、または最初のカラム内とメタデータ・ブロック内で締まりすぎています。
• サーフェス・テーブルは shadow-xs がなくなるか、そのヘッダー / 行がタイトなスペーシング・パディングを失っています。
• public/brand/logos/ が使用可能なロゴ ファイルを含んでいますが、ヘッダーはまだ理由なくプレースホルダー・ロゴまたはロゴを使用していないです。
• ブランド・カラーは .tasks/domain.md からプライマリー / アクティブ / フォーカス・トリートメントに反映されていません。
• UI はワークフローが許可した場合、作成された構成を使用する代わりにジェネリック admin シェルにデフォルトしています。
• 必須のサイドバーは弱い淡いサーフェスではなく、より暗いプライマリー導出トーンを使用していません。
• 必須のサイドバーはラベル、バッジ、アイコン、またはアクションをクリップするか、詰まったアイテム・パディング / 行の高さを使用しています。
• UI は曖昧なエンタープライズ中央ラジアス・コントロールにフォールバックしています。ドメイン・スキルはそれを要求していない場合でも。
• タイポグラフィーはジェネリック・フォントにフォールバックするか、製品が 1 つをサポート出来た場合、特徴的なディスプレイ / ボディ・ペアリングに欠けています。
• テーマ変数はコンポーネント・スタイリング前に構成されていません。
• shadcn コンポーネントはアプリ固有のクラス / スタイル・カスタマイズなしで使用されます。
• カスタム CSS はグローバル・テーマ変数の代わりにハード・コードされた 1 回限りのカラー / ラジアス / シャドウを使用しています。
• スクリーンは詰まったか、またはすべてのモジュールが等しい重みを持っています。
• UI はスターター admin テンプレート、Bootstrap ダッシュボード、またはジェネリックな AI / SaaS アプリのように見えます。