鉄則
デザイン思考フェーズを完了せずにUIを出力してはならない — コードを1行も書く前に、目的、トーン（1方向）、差別化アンカーを定義すること。DFIIスコアが8以上でなければ次に進んではならない。
フロントエンドデザインスキル
目的
ジェネリックなAI美学を避け、特徴的でプロダクション品質のインターフェースを構築するための、クリエイティブなフロントエンドデザイン手法、ビジュアル原則、品質チェックリストを提供します。
プロセス
- デザイン思考フェーズ（必須 — スキップしないこと）
- 目的を定義する：このインターフェースはどのようなアクションを可能にするか？説得力があるか、機能志向か、探索的か、表現的か？
- トーンを定義する：1つの支配的な方向性を選択する（ブルータリズム / エディトリアル / ラグジュアリー / レトロフューチャリスティック / インダストリアル / オーガニック / プレイフル / マキシマリスト / ミニマリスト）。2つ以上を混ぜてはならない。
- 差別化アンカーを定義する：「ロゴを消してスクリーンショットを撮ったとき、どうやってそれが誰のものか分かるか？」に答える。これは最終UIで視覚的に確認できなければならない。
- DFIIをスコアリングする — デザイン実現可能性とインパクト指標を計算する（下記参照）。スコア < 8 → 方向性を再考してから進む。
- 原則を読み込む —
reference/frontend-design-principles.mdを読み、タイポグラフィ、色、モーション、レイアウトのガイダンスを得る。 - 実装する — 選択した美学に沿った動作するコード（Angular、Flutter、またはHTML/CSS/JS）を構築する。ワークスペースのデザイントークンに従う（Angularの場合はdaisyUI、Flutterの場合はAppSpacing/colorScheme）。
- 必要な出力構造で納品する — デザイン方針サマリー、デザインシステムスナップショット、実装コード、差別化ポイントを含める。
完全なデザイン原則、アンチパターン、品質チェックリストについては、以下を読むこと：
reference/frontend-design-principles.md
エラーハンドリング
ターゲットフレームワークが指定されていない場合は、先に進む前にユーザーに問い合わせること。 外部フォント/アセットリソースが利用できない場合は、フォールバックの選択肢を文書化して続行すること。
デザイン実現可能性＆インパクト指標（DFII）
コードを書く前にデザインの方向性をスコアリングする。最低スコア8が必要。
評価軸（各1〜5点）
| 評価軸 | 質問 |
|---|---|
| 美的インパクト | この方向性は視覚的にどの程度特徴的で記憶に残るか？ |
| コンテキスト適合性 | この美学はプロダクト、オーディエンス、目的に合っているか？ |
| 実装の実現可能性 | 利用可能な技術でクリーンに構築できるか？ |
| パフォーマンスの安全性 | 高速でアクセシブルな状態を維持できるか？ |
| 一貫性リスク | これを画面/コンポーネント間で維持できるか？（減点対象） |
計算式
DFII = (インパクト + 適合性 + 実現可能性 + パフォーマンス) − 一貫性リスク
範囲: −5 → +15
解釈
| DFII | 意味 | アクション |
|---|---|---|
| 12–15 | 優れている | 完全に実行する |
| 8–11 | 強い | 規律をもって進める |
| 4–7 | リスクあり | スコープまたはエフェクトを削減する |
| ≤ 3 | 弱い | 美的方向性を再考する |
必要な出力構造
すべてのフロントエンドデザインの出力には、以下の4つのセクションを必ず含めること：
1. デザイン方針サマリー
- 美学の名称（例：「エディトリアルブルータリズム」「ラグジュアリーミニマル」）
- DFIIスコア
- 主なインスピレーション（概念的なもの — ビジュアルの盗用ではないこと）
2. デザインシステムスナップショット
- フォント（理由を含める — なぜこのフォントがこのプロダクトに適しているのか？）
- カラー変数（
--color-primary、--color-accent、--color-neutralのように命名すること） - スペーシングのリズム（基本単位とスケール）
- モーションの哲学（控えめ/目的的？それともなし？）
3. 実装コード
- 完全に動作するコード
- 意図が明らかでない箇所にのみコメントを付けること
- Angularの場合：daisyUIのセマンティックトークン（
bg-primary、text-base-content）を使用すること — ハードコードされた16進数は禁止 - Flutterの場合：
Theme.of(context).colorSchemeおよびAppSpacing.*トークンを使用すること —Color(0xFF...)やEdgeInsets.all(16)は禁止
4. 差別化ポイント
明示的に次のように述べること：
「このUIは、Y ではなく X を行うことで、ジェネリックなUIを避けています。」
この文を完成できない場合、そのデザインは十分に特徴的ではありません。
オペレーターチェックリスト（納品前ゲート）
- デザイン思考フェーズが完了している（目的 + トーン + 差別化アンカーが定義されている）
- DFIIスコア ≥ 8
- 最終UIに記憶に残るデザインアンカーが1つ表示されている
- ジェネリックなフォントを使用していない（Inter、Roboto、Arial、system-ui は禁止）
- ジェネリックな色を使用していない（紫から白へのグラデーション、フラットなグレーは禁止）
- デフォルトレイアウトを使用していない（対称的なカードグリッド、テンプレート的な構造は禁止）
- コードがデザインの野心に一致している（マキシマリスト＝複雑なコード、ミニマリスト＝正確なスペーシング）
- アクセシブルでパフォーマンスが良い（コントラスト比 ≥ 4.5:1、フォーカス状態、キーボードナビゲーション）
- 必要な出力構造：4つのセクションすべてが存在する
- 以前のデザインと同じに見えてはならない — 明暗、フォント選択、レイアウトの個性を変えること
クリエイティブな野心の義務
Claudeは並外れたクリエイティブな仕事が可能です。遠慮せずに、固定観念にとらわれず、特徴的なビジョンに完全にコミットしたときに真に創造できるものを示してください。
要件をクリエイティブに解釈してください。コンテキストに合わせて真にデザインされたと感じられる、予想外の選択をしてください。同じデザインのDNAを共有するデザインを2つ作ってはいけません。
世代をまたいで一般的な選択に収束しては絶対にいけません。 Space Grotesk、紫のグラデーション、対称的なヒーローレイアウトが「以前うまくいった」という事実こそ、それらを再び使わない理由です。多様性は必須であり、オプションではありません。
開始前に尋ねるべき質問（必要な場合）
- これは、感情的に誰のためのものか？
- 信頼感、興奮、穏やかさ、挑発的のうち、どれを感じさせるべきか？
- 記憶に残ることと明確さのどちらがより重要か？
- これは他のページ/コンポーネントにもスケールするか？
- 最初の3秒間でユーザーに何を感じさせるべきか？
ワークスペース統合
| スタック | デザイントークンルール | リファレンス |
|---|---|---|
| Angular | daisyUIセマンティックトークンのみ — bg-primary、text-base-content、border-base-300 | angular-spa/reference/daisyui-v5-components.md |
| Flutter | Theme.of(context).colorScheme.* + AppSpacing.* — Color(0xFF...) や EdgeInsets.all(16) は禁止 | ui-standards-tokens/reference/ui-design-tokens.md |
| HTML/CSS | CSS変数のみ — var(--color-primary) | :root ブロックで定義 |
| React Native | このスキルでは対象外 → mobile-developer スキルを使用 | .claude/skills/mobile-developer/SKILL.md |
関連スキル：
web-design-guidelines— 実装後に実行し、Vercel Web Interface Guidelines に対して監査するdesign-system— Angular および Flutter 向けトークン準拠の強制angular-spa— daisyUI を使用した Angular 実装パターンui-standards-tokens— Flutter デザイントークンの定義