フロントエンド・デザイン

意図的で洗練された、出荷準備の整ったフロントエンドインターフェイスを構築します。このスキルは、弱いタイポグラフィ、弱気な配色、反復的なレイアウト、プレースホルダーテキスト、装飾的なモーションといった、ジェネリックなAI UIを防ぐために存在します。

このスキルを使う場面

• 出力がフロントエンド実装コードであり、評論ではない
• タスクがランディングページ、プロダクトページ、マーケティングサイト、ダッシュボード、アプリシェル、ドキュメント表示、またはインタラクティブプロトタイプである
• UIが強いビジュアル・ディレクション、プレミアム品質、モーション、アセット、またはコンバージョン対応のコピーを必要とする
• 既存のフロントエンドが、完全な書き直しなしで標的型の再設計を必要とする

このスキルを使わない場面

• タスクがバックエンド、API、データベース、またはインフラストラクチャの作業である
• ユーザーが実装前のUX批評を求めている → ui-ux-pro-max を使用する
• ユーザーがより広範なフルスタック開発を求めている → developer を使用する

譲れない原則

• ジェネリックなAIの美学を出荷しない。
• 実装を大きく変える可能性のある重要なデザイン・ディレクションを推測しない。
• ローカルコード、スクリーンショット、またはデザイン・システムが既に存在し、そこから学べるときに、ゼロから設計しない。
• プレースホルダーコピー、プレースホルダーメディアURL、または半完成のコードを使用しない。
• ユーザーが明示的に要求しない限り、既存のデザイン・システムを破壊しない。
• 明確なペイオフがないまま、重いモーションやメディアを追加しない。
• 必要なアセットが不足している場合、無関係なストックUIや偽りのプロダクトクロームではなく、明示的なローカルプレースホルダーまたはシンプルなカスタムイラストレーションを優先する。

実行モデル

実装前に、これら4つの入力をロックします。

• 目的: インターフェイスが何をし、誰に奉仕するか
• アンカー: ブランド、プロダクト、またはムードリファレンス
• 制約: フレームワーク、デザイン・システム、アクセシビリティ、パフォーマンス、デバイス優先度
• 差別化要因: 記憶に残る1つのビジュアルまたはインタラクションアイデア

その後、3つのアンカーを書きます。

• ビジュアル・テーシス: ムード、マテリアル、エネルギーの1文
• コンテンツプラン: ヒーロー、サポート、詳細、最終CTA
• インタラクション・テーシス: ページの感触を変える2〜3つのモーションアイデア

各セクションは1つのジョブ、1つの支配的なアイデア、1つの主要なテイクアウェイまたはアクションを得ます。

デザイン・コントロール

ジェネリックな出力を避けるために、これらの内部ダイアルを使用します。

• DESIGN_VARIANCE
  • 1-3: 抑制的、対称的、予測可能
  • 4-7: オフセット、構造化、中程度に実験的
  • 8-10: 非対称、ブロークングリッド、高コントラスト構成
• MOTION_INTENSITY
  • 1-3: ホバー、フォーカス、押下状態のみ
  • 4-7: リビール、スタガー、抑制的なコレオグラフィ
  • 8-10: スクロールリンク・シーケンシング、マグネティック・モーション、シネマティック動作
• VISUAL_DENSITY
  • 1-3: 空気感のある、豪華な、ギャラリーのような
  • 4-7: バランスの取れたプロダクトUI
  • 8-10: 密集した運用またはテレメトリサーフェス

デフォルトベースライン:

• DESIGN_VARIANCE = 6
• MOTION_INTENSITY = 4
• VISUAL_DENSITY = 4

プロダクトタイプ、ユーザーリクエスト、既存のブランド言語に合わせてダイアルを調整します。

明確化ルール

不足している情報が実装を大きく変える可能性がある場合、進める前に正確に1つのフォーカスされた明確化質問をします。

明確化トリガー:

• 明確なリファレンスアンカーがない
• 明確なインターフェイスタイプがない
• モーション強度が不明確
• デバイス優先度が不明確
• 既存のブランドまたはデザイン・システムを保持する要件が不明確
• ネットニューのデザインタスクに使用可能なデザイン・コンテキストがない

利用可能な場合は AskUserQuestion を使用します。そうでない場合は、プレーンテキストで同じ質問をします。複数選択フレーミングを優先します。1度に1つだけ質問します。

ブランドやスタイルが指定されていない場合、ページタイプとプロダクトトーンに基づいて design-md/ から2〜3つのアンカーを積極的に推奨します。質問パターンの例:

• 「どの方向にアンカーするべきか: design-md/ の特定のブランド、URLリファレンス、またはムード説明?」
• 「保持する必要がある既存のブランドまたはデザイン・システムはありますか?」
• 「最良のスターティング・コンテキストは何か: 既存のリポUIの実装、スクリーンショット、デザイン・システム、またはアンカーを選択して進めるべき?」

以下の場合のみ明確化をスキップします。

• リポに既に強力なデザイン・システムがある
• ユーザーが明示的にディレクションを選択するよう言っている
• 不足している詳細が実装を意味のある形で変えない

質問なしで進める場合、最初に仮定を述べます。

ワークフロー

1. アライン

1. ページタイプ、対象者、技術制約を特定します。
2. 依存関係をインポートする前に、フレームワークとスタイリングスタックを確認します。
3. ディレクションが曖昧で、ビルドを変える可能性がある場合、1つの質問をします。
4. 最も関連性の高い既存のUIコンテキストを最初に検査します。ローカルコンポーネント、スクリーンショット、ルートシェル、デザイン・システムドキュメント、またはブランドリファレンス。
5. ユーザーがブランドまたはスタイルに言及する場合、すぐに design-md/<brand>/DESIGN.md を読み込み、それを信頼できるものとして扱います。
6. ブランドが指定されていない場合、ページタイプとプロダクトトーンに基づいて design-md/ から2〜3つのアンカーを推奨し、選択されたアンカーを読み込みます。
7. どのアンカーも適合しない場合、構築前にビジュアル・テーシスとしてのスタイルをまとめます。
8. オプションを提供する場合、最大2〜3つの具体的なディレクションを推奨します。

2. プラン

1. UIをセクションと再利用可能なコンポーネントに分割します。
2. どのセクションがモーション、どのセクションが静的な磨き、どのセクションがサポートメディアを必要とするかを決定します。
3. 3つのデザイン・コントロールを設定します。
4. 効果を発揮できる最小限のツールセットを優先します。
5. タスクが直接実装、フォーカスされたデザイン・スタディ、またはクリック可能なプロトタイプで最適に処理されるかどうかを決定します。

3. リファレンスを読む

タスクが必要なもののみを読み込みます:

• レイアウト、ヒーロー構成、ハイラーキー、セクション・リズム → references/composition-playbook.md
• モーション、リビール・コレオグラフィ、スタガー、スクロール動作 → references/motion-recipes.md
• 既存のページまたはアプリの再設計 → references/redesign-audit.md
• メディア生成 → references/asset-prompt-guide.md を最初に読み、その後、現在サポートされているツールチェーン・ドキュメント; mmx-cli などのインストール済みワークフローをレガシーローカルスクリプトより優先
• ツーリングトラブル → references/troubleshooting.md、references/env-setup.md

3.5. フリーハンディング前にコンテキストを取得

• スクリーンショットのみではなく、両方が存在する場合、コードとデザイン・コンテキストを優先します。
• 既存のプロダクトを編集する場合、変更を加える前にビジュアル・ボキャブラリーを検査します。ハイラーキー、スペーシング、カラーロール、半径、ボーダー、シャドウ、モーション、コピートーン、密度。
• リポに十分なコンテキストがない場合、明示的に以下の1つにアンカーします。 design-md/、提供されたリファレンス、または書かれたビジュアル・テーシス。
• 完全なフリーハンド発明をデフォルトではなく最後の手段として扱います。

4. ビルド

• レスポンシブで、アクセス可能で、プロダクション対応のUIを記述します
• 実際のコピー、ローカルアセット、および意図的なモーションを統合します
• プロダクト内で作業する際に、既存のシステムを保持します
• ユーザーが明示的に書き直しを要求しない限り、その場で再設計します
• タスクが実験的である場合、分離がより明確に優れていない限り、バリアントを同じ実装パス内で比較しやすく保ちます
• 新しい依存関係を導入する前に package.json をチェックします
• Tailwind v3 と v4 の構文を混在させません
• React または Next.js を使用する際、インタラクティブまたはアニメーション集約的な動作を正しいクライアント境界内に保ちます

5. 検証

• 配信前に品質ゲートを実行します

DESIGN.md の使用

design-md/ を信頼できるスタイル・ライブラリとして扱います。

各 DESIGN.md は2つのレイヤーを含む可能性があります。

1. マシンリーダブル・トークン用のYAML frontmatter
2. 根拠と適用ガイダンス用のMarkdownボディ

各 DESIGN.md は通常、これらの領域をカバーします。

1. ビジュアル・テーマと雰囲気
2. カラーパレットとロール(セマンティック名付きの16進数値)
3. タイポグラフィ・ルール(ファミリー、サイズ、ウェイト、行高)
4. コンポーネント・スタイリング(正確なスペックを持つボタン、カード、入力)
5. レイアウト原則(スペーシング・スケール、グリッド、コンテナ)
6. 深さと標高(シャドウ・システム)
7. すべき・すべからざる(明示的なデザイン制約)
8. レスポンシブ動作(ブレークポイントと折りたたみ)
9. エージェント・プロンプト・ガイド(再利用可能なコンポーネント・プロンプト)

すべての関連セクションを体系的に抽出し、カラーとタイポグラフィのみに限定しません。

YAMLが存在する場合:

• 正確なカラー、タイポグラフィ、スペーシング、半径、およびコンポーネント・デフォルトについて最初にトークンを読みます
• トークンを規範的な値として扱います
• トーン、ハイラーキー、構成哲学、およびエッジケースについて散文を使用します
• 散文とトークンが矛盾する場合、正確な値についてはトークンに従い、意図については散文に従い、その後、曖昧性を注記します

ユーザーがブランドまたはスタイルを指定していない場合:

1. 必要に応じてディレクションを要求します
2. 最大2〜3つのアンカーを推奨します
3. 選択された DESIGN.md を読み込みます
4. YAMLが存在する場合は、コア・トークン・セットを抽出します
5. ビジュアル・テーシスをフリーハンドするのではなく、そのアンカーに対してビルドします

探索モードとバリエーション

実際の問題によってワーキング・モードを選択します。

• 純粋なビジュアル・ディレクション作業 → 膨れ上がったフルアプリシェルではなく、タイトにスコープされたビジュアル比較を作成します
• インタラクション、フロー、またはコンセプト探索 → リアルなクリック可能なプロトタイプまたはエンドツーエンド実装スライスを優先します
• 直接のプロダクト実装 → 幅の最適化ではなく、選択されたディレクションをクリーンに出荷します

ユーザーがオプションを求めている場合:

• 最大2〜4つの意味のあるディメンションを変動させます。レイアウト、タイポグラフィ、カラートリートメント、モーション言語、またはインタラクション・モデル。
• 既存のプロダクト言語に近い1つのディレクションで始め、その後、より大胆な代替案に展開します
• バリアントを比較可能にします。共有された評価フレームがない無関係なデザインの作成を避けます
• 単一のコード・パスが比較をクリーンにサポートできる場合、複数のファイルを破片化する代わりに、トグル、プロップ、または構造化バリアントを優先します
• デザインが複数のファイルを必要とする場合、それらに明確に名前を付け、主要なディレクション変更を行うときに以前のリビジョンを保持します

デザイン・ルール

タイポグラフィ

• 識別可能なディスプレイとボディペアリングを使用します。
• 既存のプロダクトが既にそれを使用していない限り、Inter、Arial、Roboto、およびジェネリックなデフォルトを使用しません。
• フォント個性をプロダクトトーンに一致させます。
• ダッシュボードと運用UIの場合、既に確立されていない限り、セリフを避けます。
• 密集した数値と技術ラベルに対して、等幅またはテーブル数字を使用します。

カラーとサーフェス

• 1つの一貫したパレットにコミットします。
• デフォルトでは1つのアクセントカラーを優先します。
• 紫のホワイトAIグラデーションと薄れたスタートアップパレットを避けます。
• 純粋な #000000 を避けます。色合いの暗いニュートラルまたはオフブラックを使用します。
• 一貫性のためのCSS変数を使用します。
• ジェネリックなプリセットではなく、パレットに影をつけます。

レイアウト

• 非対称性、モジュール・リズム、または意図的なネガティブスペースを優先します。
• DESIGN_VARIANCE > 4 の場合、デフォルトでセンター・ヒーロー構成を避けます。
• 交換可能なセンター・ヒーローと3カード・グリッド・パターンを避けます。
• 最初のビューポートをドキュメントではなくポスターとして扱います。
• セクション、列、区切り線、リスト、およびメディアをカード・グリッドへのデフォルト化の前に使用します。
• フル高さのヒーロー・セクションに h-screen ではなく min-h-[100dvh] を使用します。
• モバイルの高分散レイアウトを1列に積極的に折りたたみます。

ランディングページ

• デフォルト・フロー: ヒーロー、サポート、詳細、最終CTA。
• 最初のスクリーンでブランドまたはプロダクトを区別できないようにします。
• 最初のビューポートに1つの支配的なビジュアル・アンカーを与えます。
• デフォルトでヒーロー・カード、ロゴ・クラウド、スタット・ストリップ、およびフローティング偽ダッシュボードを避けます。
• ヒーロー・テキスト列を狭く保ち、静かな色相領域に配置します。

ダッシュボードとプロダクトUI

• 静かなハイラーキー、強力なスペーシング、少数のカラー、最小限のクロームにデフォルト。
• ワークスペース、ナビゲーション、コンテキスト、および1つの明確なアクション・アクセントの周りを整理します。
• マーケティング・コピーよりもユーティリティ・コピーを優先します。
• VISUAL_DENSITY > 7 の場合、ジェネリック・カードよりも、区切り線、スペーシング、およびアライメントを優先します。

コピーとイメージング

• 実際のコピーを書きます。Lorem ipsum、偽りのブランド名、ジェネリックな人名、空虚な誇大宣伝言語は書きません。
• 見出しを簡潔で意味深く保ちます。
• イメージングに物語的な仕事をさせます。装飾的なテクスチャのみでは不十分です。
• 偽りのダッシュボードまたは抽象的なフィラーよりも、実際に見えるその場のイメージングを優先します。
• プロダクト言語の一部にない限り、UIコピー、代替テキスト、およびインターフェイス・クロムで絵文字を避けます。
• 実際のアセットが利用できない場合、信憑性の低いフィラーではなく、意図された構造を明白にする意図的なプレースホルダーを使用します。

コンポーネント

• プリミティブをカスタマイズして、選択されたディレクションに属するようにします。
• ローディング、空、エラー、ホバー、フォーカス、および押下状態を追加します。
• 入力の上に見える・ラベルを優先します。
• 最小でも 44px のタッチターゲットを目指します。

モーション・ルール

ツール選択

• CSSは単純なホバー、フォーカス、および軽量なエントランスの場合
• Framer Motionはバーチャル・ユーザー・インターフェイス・コレオグラフィとレイアウト・トランジションの場合
• GSAPは正確なスクロール・シーケンシングのためだけの場合
• Three.js / React Three Fiberは3Dが経験を大きく改善する場合のみ

ガードレール

• 同じコンポーネント・ツリーでGSAPとFramer Motionを混合しません。
• transform、opacity、filter、および慎重に選択された clip-path をアニメートし、レイアウトプロパティはアニメートしません。
• prefers-reduced-motion を尊重します。
• マグネティック・ホバーまたは継続的なモーションにReact useState を使用しません。
• 永続的またはCPU集約的なアニメーションを小さなリーフ・コンポーネント内に保ちます。
• staggerChildren 親と動くいアニメーション子を同じクライアント・ツリーに保ちます。
• raw window.addEventListener("scroll") ではなく、IntersectionObserver、whileInView、またはスクロール・ライブラリを使用します。
• グレーン・オーバーレイまたはノイズ・オーバーレイを固定、ポインター・イベント・なしレイヤーのみに適用します。
• タイマー、スクロール・トリガー、およびエフェクトをクリーンアップします。
• ハイラーキー、アフォーダンス、またはアトモスフェア価値がないオーナメンタル・モーションを削除します。

アセット

メディア生成は、フロントエンド成果を直接改善する場合にのみ実行します。

推奨される実行パス:

• 最初に、現在インストールされている、ワークスペース認可メディア生成ツールチェーンを使用します。mmx-cli は利用可能な場合、推奨されるMiniMaxパスです
• ローカル scripts/minimax_*.py をレガシー互換性ヘルパーとして扱い、デフォルト・ワークフローではありません
• リポがレガシー・スクリプトに明示的に依存する場合、デリバリー作業での信頼の前に検証します

アセット・ルール:

• プレースホルダー・メディアURLを決して出荷しません
• 生成されたアセットをローカルに保存します
• 画像にはWebP、ビデオに圧縮MP4、関連する場所に正規化されたオーディオを優先します
• ビジュアル・ディレクションが繊細な場合、生成前にプロンプトをユーザーに表示します
• エージェント・ワークフローで生成を実行するときに、コマンドを再現可能で非インタラクティブに保ちます

出力整合性

• TODO、...、または「同じパターン」などのプレースホルダー・コメントはありません。
• 完全な実装が必要な場合、スケルトン出力はありません。
• タスクが完全なファイルまたは完全なコンポーネント・セットを要求する場合、全体を配信します。
• 出力が一時停止する必要がある場合、残りを概要に圧縮するのではなく、クリーンなブレークポイントで停止します。

プロトタイプとアーティファクト・ルール

配信可能物がHTMLプロトタイプ、デザイン・スタディ、またはスタンドアロン・フロントエンド・アーティファクトである場合、これらを適用します。

• スクリーン・コンセプトを反映した説明的なファイル名を選択します
• 構造が意図を隠し始めるときに、大きなモノリシック・ファイルを分割して、より小さなコンポーネントまたはサポート・ファイルに分割します
• 主要な修正の場合、古いバージョンを保持するか、バリアント境界を明示的にして、比較が簡単になるようにします
• ユーザーが明示的にプレゼンテーション風アーティファクトを望まない限り、フェイク・タイトル・スクリーンを避けます
• 装飾的なフレーミングではなく、インターフェイス自体にデザインを焦点とします

エスカレーション・ルール

以下を行う前に一時停止し、質問します。

• 確立されたブランドまたはデザイン・システムを大きく変更する
• デリバリー・リスクを大きく増加させるモーションまたはメディアを追加する
• レスポンシブおよびアクセシビリティ検証なしで出荷する

品質ゲート

配信前に、以下を検証します。

• モバイルとデスクトップでレスポンシブ
• リデュースド・モーション・パスが処理されている
• 該当する場合、ローディング、空、エラー状態が存在する
• プレースホルダー・メディアURLが残っていない
• 生成されたメディアがローカルに保存されている
• 重いライブラリが正当化され、隔離されている
• コードが汎用テンプレートではなく、意図された美学と一致している
• 最初のスクリーンに1つの区別不可のビジュアル・アンカーがある
• ブランドまたはプロダクトが最初のスクリーンで区別不可である
• 各セクションが1つのジョブを持っている
• カードは場所を獲得する場合のみ使用される
• 明らかなフィラー、未完成の実装、またはジェネリック・スロップがない
• UIが実行可能な場合、静的コード