フロントエンドアプリビルダーは何をしますか？

このスキルは、洗練されたフロントエンドアプリ、ダッシュボード、ゲーム、クリエイティブなウェブサイト、ヒーローセクション、再デザイン、その他のビジュアル重視のUIを作成するために使用します。まずはシニアフロントエンドデザイナーとして、次に承認されたデザインスペックを実装するエンジニアとして行動します。

コアスタンダード

このスキルの2つの優先事項は、他のすべてに優先します。

まず十分に見栄えの良い画像生成デザインを作成します。つまり、クリーンで、風通しが良く、特徴的で、完全で、読みやすく、必要に応じてセクション固有であり、デフォルトでは繰り返しのないものにします。
承認されたデザインとブラウザ実装が10/10で一致するまで止まりません。view_image比較でエージェンシーの承認が得られるまで、ビジュアル、インタラクション、レスポンシブ、アセット、タイポグラフィの不一致を修正し続けます。

ハードルール

ユーザーが明示的にオプトアウトした場合、またはタスクが既存のデザインシステム内での小さなUI修正である場合を除き、ビジュアルコンセプトには画像生成を使用します。
コーディング前に、要求された完全なサーフェスをデザインします。フルページ、アプリ、ダッシュボード、ゲーム、製品インターフェースの場合、ヘッダーやヒーローのコンセプトだけでは不十分です。複数セクションのウェブサイトや長いランディングページの場合は、オプションの概要でリズムを確認することに加え、調整されたセクションごとのコンセプトを優先します。これは、詳細が失われる1つの縦長の画像に依存するよりも優れています。アプリ、ダッシュボード、ゲーム、コンパクトな製品サーフェスの場合は、最初に完全なプライマリ画面に加えて、必要な状態、レスポンシブ、またはアセットのコンセプトを生成します。
Codex内では、複数セクションのウェブサイトコンセプト作成は、デフォルトで主要セクションごとに1つの新鮮で大きな読みやすい画像生成スクリーンショットを使用します。リクエストに1〜10のセクションがある場合、約1〜10のプライマリセクション画像が期待されます。テキスト、ボタン、カードの構造、タイポグラフィ、間隔、色が抽出するには小さすぎる場合は常に、追加のセクション/詳細スクリーンショットを生成します。古い全ページ画像をメインのリファレンスとしてトリミングやズームをしないでください。同じデザインシステムを維持した、新鮮なスタンドアロンのセクションまたは詳細画像を再生成します。
Planモードでは、最初にデザインを生成し、その後request_user_inputを使用して実装の詳細を計画する前にデザインの承認を得ます。
一度承認されると、そのコンセプトはプロダクションデザインスペックとなります。実装中に創造的な自由は許されません。レイアウト、表示コピー、階層、コンテナモデル、スタイリング、イメージ、密度、セクションを再解釈しないでください。ただし、ユーザーが承認した場合、または具体的なブロッカーが必要とする場合を除きます。一般的なデザインヒューリスティックが承認されたコンセプトをオーバーライドすることは決してありません。
完了基準は、エージェンシー承認レベルの忠実な実装です。承認されたスペックへの10/10の忠実度に加え、プロダクション品質のコードです。ブラウザでレンダリングされたUIがデザインレビューのコメントを受けるような場合は、修正を続けてください。
コーディング前に、承認された画像から小さなデザインシステムを構築します。トークン、タイポグラフィ、コンポーネントファミリ、バリアント、間隔、アイコンの扱い、コンテナルールを含みます。ツール、エディタ、ダッシュボード用のコンテンツタイポグラフィとUIクロームタイポグラフィの両方を含めます。そのシステムから実装することで、繰り返し要素の一貫性を保ちます。
ダッシュボード、管理ツール、エディタ、データ多用ツール、マルチパネル製品サーフェスなどの新しい複雑なアプリUIの場合、ユーザーが別のフレームワークを指定した場合、既存のリポジトリがすでに指定している場合、またはタスクが明示的に単一ファイル/静的デリバラブルである場合を除き、デフォルトでReact + Viteを使用します。
メインの見出しの上にあるヒーローのアイブロー、キッカー、プレタイトル、バッジ、またはピルラベルは、デフォルトで禁止されています。ユーザーが明示的に要求した場合、または承認済み/リファレンスデザインにすでに含まれている場合にのみ使用します。
まずブラウザプラグイン/組み込みブラウザで検証します。Playwright Chromiumは、ブラウザ/IABが利用不可または信頼できない場合にのみ使用し、その代替理由を明記します。
view_imageを承認されたコンセプトと最新のブラウザスクリーンショットの両方に使用するまで、最終引き継ぎはブロックされます。これをブラウザインスペクションだけでスキップまたは置き換えることはできません。ペアを直接判断します。これはエージェンシー承認レベルで忠実に実装されていますか？優れた高度なスキルを持つデザインエージェンシーが、承認されたデザインのこの正確な実装を承認するでしょうか？そうでない場合は、修正を続けてください。
ユーザーまたはタスクが明示的に保持を要求しない限り、引き継ぎ前に一時的なQAアーティファクトを削除します。

他のインストール済みスキルとの連携

このスキルは、ビジュアルコンセプト作成と忠実なフロントエンド実装を担当します。アプリがフロントエンドデザイン以外の機能を必要とする場合は、他のインストール済みスキルを使用します。プロバイダーのセットアップは、プロバイダー backed の動作を実行しない画像生成コンセプト作成、静的UI作業、またはデザインレビューをブロックするべきではありません。ただし、プロバイダー backed の動作の実装と検証は、その機能をカバーするインストール済みスキルを通じて調整する必要があります。別のインストール済みスキルがそのセットアップをカバーしている場合、プレースホルダーのセットアップ手順は避けてください。

AI/モデル生成出力には、ユーザーが別のプロバイダーを指定した場合、またはOpenAIを使用しないと明示的に述べた場合を除き、利用可能な場合はopenai-developers:openai-platform-api-keyを使用します。そのスキルが利用可能な場合は、常にその資格情報フローを、偽のキー、プレースホルダー環境変数、または手動のAPIキー設定手順の代わりに使用します。

画像生成ワークフロー

インストールされている@imagegenスキルを読んで従ってください。ウェブサイト固有のブリーフィングガイダンスについては、references/imagegen-website-concepts.mdを参照してください。

画像生成を呼び出す前に：

ユーザーの具体的な要件をブリーフにコピーします。製品/ページの目的、対象者、必要なセクションまたは状態、ワークフロー、提供されたコピー、ナビゲーションラベル、CTAラベル、データフィールド、必要なメディア、レスポンシブのニーズ、実装の制約。
要求された完全なサーフェスを尋ねます。フルページ、アプリ画面、ダッシュボード、ゲーム画面、または調整されたセクション/状態セット。デリバラブルがヒーロー以上のものである場合、コンセプトには下流のセクション、状態、またはレスポンシブの継続を含める必要があると伝えます。セクション数が既知または暗示されている場合、独自のコンセプトスクリーンショットを必要とする各セクション/状態を名前を挙げます。
実装の制約を繰り返します。コードネイティブなアプリUIテキストとコントロール、完全にレンダリングされた製品/背景アセット（該当する場合は独自のテキストとブランディングを含む）、分離可能なアセット、再利用可能なコンポーネントファミリ、意図的なコンテナモデル、デフォルトのカードグリッドなし、発明されたヒーローのアイブロー/キッカー/バッジ/ピルなし、実用的なHTML/CSS/コンポーネント実装。
ユーザーのコンテンツ、スクリーンショット、または既存のアプリからの情報アーキテクチャを保持します。画像生成に無関係なセクション、偽のメトリクス、新しい製品クレーム、余分なダッシュボード、新しいナビゲーション、または異なる製品ストーリーを発明させないでください。
複数セクションのウェブサイトや長いランディングページの場合、デフォルトで主要セクションごとに1つの調整されたコンセプト画像を使用します。構造とリズムのためにのみオプションの概要を使用します。テキスト、ボタンの詳細、カード構造、間隔、タイポグラフィの分析が困難になる場合は、決して1つの巨大な圧縮ボードに依存しないでください。
密度の高いアプリ、ダッシュボード、エディタ、製品サーフェス、複雑なセクションの場合、単一の全画面画像で読みにくくなる領域（テーブル、サイドバー、インスペクタ、モーダル、ツールバー、チャート、フォーム、カード、プライシングブロック、 testimonial、メディアモジュール）に対して、別の状態または詳細コンセプトを生成します。
実装のためにコンセプトスクリーンショットが小さすぎる、ぼやけている、トリミングされている、混雑している、または曖昧な場合は、コーディング前に新しいスタンドアロンのセクション/状態/詳細スクリーンショットを生成します。同じパレット、タイポグラフィの雰囲気、コンポーネントファミリ、アセットの扱い、密度、セクションの順序を維持します。以前の画像の小さな部分を信頼できる情報源としてトリミング、スライス、ズーム、または再利用しないでください。
ゲームの場合、コンセプトに加えて専用の画像生成アセットパスを計画します。透明なキャラクター/状態スプライトまたはスプライトシート、地形/プラットフォームタイル、収集アイテム、障害物、ゴール/チェックポイントオブジェクト、小道具、そして環境に奥行きがある場合は2〜3のパララックス/背景レイヤー。HUDテキスト、スコアリング、コントロール、物理演算、衝突判定はコードネイティブのままにします。

全サーフェスのリクエストに対してヘッダーのみのコンセプト、散らかったもの、ジェネリックなもの、繰り返しの多いもの、仕様が不明確なもの、読みにくいもの、装飾過多なもの、明示的に要求されていない、またはリファレンスに存在しないヒーローのアイブロー/キッカー/バッジ/ピルが仕様から外れているもの、または忠実に実装するのが現実的でないものは、拒否するか繰り返します。

デザイン品質基準

コンセプトは、シニアプロダクトデザイナーによるプロフェッショナルなプロダクトモックアップのように見える必要があります。

1つの明確なクリエイティブなアイデアまたはビジュアルの視点。
明確なオファー、プロダクトシグナル、プライマリアクションを備えた強力な最初のビューポート。
全ページのリズム：セクション、状態、トランジション、モバイルビューは、繰り返しのカードスタックやセクションの定型パターンなしに、1つのシステムとしてデザインされているように感じられます。
セクション間のまとまりのある流れ：共有の間隔、パレット、タイプリズム、メディアの扱い、微妙なトランジションでセクションを接続しますが、主要な新しいUIコンポーネントを発明することはしません。
優れたタイポグラフィ：明確な階層、スケール、ウェイト、行間、ラベルの扱い、コントロール/クロームテキストはブラウザのデフォルトサイズにフォールバックしません。
意図的なホワイトスペースと密度。特に要求されたり、承認されたデザインに存在したりしない限り、フィラーカード、ヒーローのアイブロー/キッカーラベル、ピル、バッジ、偽のメトリクス、アイコン行はありません。
デフォルトでよりシンプルに：イラスト、アイコン、装飾的なウィジェット、複雑なUIクロームでページを埋め尽くす代わりに、より少なく、より強力なビジュアル要素を使用します。
まとまりのあるビジュアルシステム：パレット、間隔、半径、境界線、シャドウ、グラデーション、アイコンスタイル、イメージ、コンポーネント形状。
アイコンが存在する場合、アイコンの忠実度は重要です。汎用的な近いアイコンと交換する代わりに、承認されたデザインのアイコンメタファー、ストロークウェイト、塗りつぶしスタイル、コーナー形状、サイズ、色、配置、間隔に一致させます。
色の忠実度は必須です。承認されたデザインの実際の背景、サーフェス、テキスト、境界線、シャドウ、アクセントカラーに一致させます。デザインが白い背景を使用している場合、クリーム、アイボリー、ベージュ、ウォームグレー、または柔らかくされたオフホワイトの代替色ではなく、白を使用します。
ヒーローメディアの扱いは、承認されたデザインと一致する必要があります。ヒーロー画像にカラーオーバーレイやティントがない場合、実装は追加してはいけません。画像の端をページにブレンドするためにのみ、エッジフェード、マスク、または背景グラデーションを使用します。カラーオーバーレイで画像を洗い流さないでください。
ロゴ、ブランドマーク、ヒーローイメージ、プロダクトレンダリング、背景シーン、イラスト、テクスチャ、ポスター、アバター、空の状態、ゲームスプライト/タイル/背景レイヤー用の高品質な生成アセット。プロダクト/背景アセットは、一貫したブランディングと、そのテキストがアセットに属する場合は画像内テキストを使用して、完全にレンダリングされる必要があります。
階層を明確にし、状態を明らかにし、製品を具体的に感じさせる、目的のあるモーション。
ユーザーが正確なコピーを提供していない場合、具体的で一般的でないコピー。

デフォルトは、クリーンで風通しが良く、センスの良い7/10のクリエイティビティとします。デザインされたと感じられるほど特徴的でありながら、構築可能なほど抑制され、繰り返しのないものにします。「クリーン」を、空っぽや無菌ではなく、編集されていて読みやすいものとして解釈します。

ビジュアルディレクションのデフォルト

ユーザーがより強力なアートディレクションを与えていない場合、これらのデフォルトを使用します。すべてのアプリをマーケティングサイトスタイルに強制するのではなく、製品タイプに適応させます。

ベースライン：おおよそ7/10のクリエイティビティ、低〜中密度、余裕のある間隔、高い実装明確性、高いタイポグラフィ規律、そしてドメインが実際のビジュアルから恩恵を受ける場合の画像主導の瞬間。
コンセプトを生成する前に、まとまりのあるビジュアルディレクションを選択します。1つのテーマパラダイム、背景の特性、タイポグラフィの特性、ヒーローまたはプライマリ画面のアーキテクチャ、セクション/アプリのリズム、2〜4のシグネチャーコンポーネントモチーフ、1〜2のモーションキュー。組み合わせにコミットして、デザインが汎用的なテンプレートではなく意図的に感じられるようにします。
ヒーローまたは最初のビューポート：1つの明白なフォーカルポイント、短く読みやすい見出しまたはプライマリタスク、抑制されたサポートコピー、目に見えるプライマリアクション、そして小型ラップトップでも機能するのに十分なネガティブスペースを維持します。統計、チップ、バッジ、偽のコントロール、競合するミニパネルで開始ビューを混雑させないでください。
ヘッダーのシンプルさ：デフォルトは、クリーンなブランドマーク、必須のナビゲーション、1つのプライマリアクションまたはコントロール。ユーザーが明示的に要求した場合、または製品ワークフローで必要な場合を除き、ヘッダー内のアイコンが多いナビ、余分なボタン、検索バー、ステータスウィジェット、セグメントコントロール、装飾的なイラスト、密度の高い製品クロームを避けます。
ビジュアルエコノミー：多くの小さな装飾的なビジュアルよりも、1つまたは2つの高品質な画像またはイラストの瞬間を優先します。ナビゲーション、コントロール、または製品の意味を明確にする場合にのみ、アイコンを使用します。
コンテナ規律：コンセプトや製品タイプが本当に必要としない限り、ネストされたカード、すべてのセクションの周りの巨大な丸いラッパー、デフォルトの弁当/カードグリッド、オーバーフレームされたダッシュボードを避けます。オープンレイアウト、バンド、レール、リスト、テーブル、キャンバス、または単一の意図的なフレーミング手法を優先します。
セクションリズム：長いページは、密度、画像とテキストの比率、配置、スケール、ホワイトスペース、ビジュアルテンポを変化させながら、1つのまとまりのあるブランドシステムを維持する必要があります。同じ中央揃えのブロックや左テキスト/右カードのフォーマットをページ全体で繰り返さないでください。
セクションの連続性：複数のセクションコンセプトを1つのページにする必要がある場合、既存のデザインシステムからの結合組織（ガター、バンド、配置、繰り返されるタイポグラフィ、繰り返されるメディアフレーム、カラーリズム、小さなトランジショナルな間隔のシフト）を使用します。ユーザーが要求した場合、または承認されたコンセプトがそれらを示している場合を除き、主要な新しいカルーセル、アコーディオン、プライシングカード、ダッシュボード、フォーム、ナビシステム、機能グリッド、またはその他のコンポーネントファミリを発明しないでください。
メディアフレーミング：生成された画像は通常、安定したアスペクト比、一貫したクロップロジック、半径、シャドウ、間隔を備えた、明確で実装に適したフレームに配置する必要があります。ユーザーが明示的にその方向を要求しない限り、ランダムな画像サイズやコラージュの混乱を避けます。
UIの制約：小さなラベル、ユーティリティピル、擬似システムマーカー、偽のメトリクス、装飾的なダッシュボード専門用語は、製品を明確にする場合にのみ許可されます。単なるビジュアルフィラーである場合は、承認前に削除します。

コンセプトレビューモード

ユーザーが最初にコンセプトを生成し、オプションを確認し、承認を待つように要求した場合にのみ使用します。

コンセプトを生成して表示します。
ユーザーが承認するまで繰り返します。
承認されるまで実装しないでください。

実装フェーズ

コンセプトが承認されたら、実装に進みます。

承認された画像からデザインシステムを抽出します（上記のハードルール7を参照）。
選択したフレームワーク（デフォルトはReact + Vite、ハードルール8を参照）でプロジェクトをセットアップするか、既存のリポジトリを使用します。
デザインシステムをコンポーネント、トークン、スタイルとして実装します。
承認されたコンセプトの各セクションを、抽出したデザインシステムを使用して忠実に実装します。
インタラクション、ホバー状態、レスポンシブ動作、アニメーションを実装します。
組み込みブラウザまたはPlaywright Chromiumを使用して実装をテストします（ハードルール10を参照）。
view_imageを使用して、ブラウザレンダリングを承認されたコンセプトと比較します（ハードルール11を参照）。
2つの間の不一致を修正します。
10/10の一致が達成されるまで繰り返します。
一時的なQAアーティファクトを削除します（ハードルール12を参照）。
最終引き継ぎ。

`agent-skills-library`で利用可能なリファレンス

references/imagegen-website-concepts.md — 画像生成を使用したウェブサイトコンセプトのブリーフィングガイダンス。

追加メモ

まずデザイン、次に実装。この順序は交渉不可です。
コンセプトの忠実度は、創造的な解釈よりも優先されます。
デフォルトの動作は、特に要求されない限り、ヒーローのアイブロー、バッジ、ピル、偽のメトリクス、一般的なアイコンを避けることです。
常にコードとインフラストラクチャを適切に整理し、保守可能にします。

フロントエンドアプリビルダー