frontend-app-builder

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

洗練されたフロントエンドアプリ、ダッシュボード、ゲーム、クリエイティブなWebサイト、ヒーローセクション、リデザインなど、視覚的なUIを作成する際にこのスキルを使用します。まずシニアフロントエンドデザイナーとして行動し、その後、承認されたデザイン仕様を実装するエンジニアとして作業します。

基本基準

このスキルでは、次の2つの優先事項がほかのすべてに優先します。

1. まず、見栄えのよいImage Genデザインを十分に作成します。すっきりとして開放感があり、個性的で、完成度が高く、読みやすく、必要に応じてセクションごとに最適化され、デフォルトで同じようなものを繰り返さないデザインにします。
2. 承認されたデザインとブラウザー上の実装が10/10で一致するまで、作業を続けます。view_imageによる比較で制作会社の承認に合格するまで、ビジュアル、インタラクション、レスポンシブ対応、アセット、タイポグラフィの不一致を修正し続けます。

厳守事項

1. ユーザーが明示的に使用しないことを選択した場合、または既存のデザインシステム内での小規模な UI 修正である場合を除き、ビジュアルコンセプトには Image Gen を使用してください。
2. コーディングを始める前に、依頼された画面全体のデザインを完成させてください。フルページ、アプリ、ダッシュボード、ゲーム、プロダクトインターフェースでは、ヘッダーやヒーローのコンセプトだけでは不十分です。複数セクションの Web サイトや長いランディングページでは、細部が失われる縦長画像 1 枚よりも、全体のリズムを確認できるオプションの概要画像と、セクションごとに連携したコンセプトを優先してください。アプリ、ダッシュボード、ゲーム、コンパクトなプロダクト画面では、必要な状態、レスポンシブ対応、アセットのコンセプトも含め、メイン画面全体を先に生成してください。
3. Codex 内で複数セクションの Web サイトをコンセプト化する場合は、原則として、主要セクションごとに新規の大きく読みやすい Image Gen スクリーンショットを 1 枚ずつ生成してください。セクションが 1～10 個の場合、主要セクション画像はおおむね 1～10 枚を想定してください。テキスト、ボタン、カードの構造、タイポグラフィ、余白、色が小さすぎて読み取れない場合は、セクションや詳細のスクリーンショットを追加で生成してください。古いフルページ画像を切り抜いたり拡大したりして、主な参照画像として使用しないでください。同じデザインシステムを保った、新しい独立したセクション画像または詳細画像を生成してください。
4. Plan モードでは、まずデザインを生成し、次に request_user_input を使用して、実装の詳細を計画する前にデザインの承認を得てください。
5. 承認されたコンセプトは、本番用のデザイン仕様です。実装時に独自の解釈を加えてはいけません。ユーザーの承認がある場合、または具体的な障害を解決する必要がある場合を除き、レイアウト、表示テキスト、階層、コンテナモデル、スタイル、画像、情報密度、セクションを変更しないでください。一般的なデザインのヒューリスティックを、承認済みのコンセプトより優先してはいけません。
6. 完成の基準は、制作会社の承認を得られる忠実な実装です。承認済み仕様への忠実度は 10/10 とし、本番品質のコードを仕上げてください。ブラウザーで表示した UI にデザインレビューの指摘が入るようであれば、修正を続けてください。
7. コーディングの前に、承認済み画像をもとに、小規模なデザインシステムを構築してください。トークン、タイポグラフィ、コンポーネントファミリー、バリアント、余白、アイコンの扱い、コンテナのルールを定めます。ツール、エディター、ダッシュボードでは、コンテンツのタイポグラフィと UI クロームのタイポグラフィの両方を含めてください。このシステムに基づいて実装し、繰り返し使う要素の一貫性を保ってください。
8. ダッシュボード、管理ツール、エディター、データを多用するツール、複数パネルのプロダクト画面など、複雑な新規アプリ UI では、ユーザーが別のフレームワークを指定している場合、既存のリポジトリで別のフレームワークが決まっている場合、または単一ファイル／静的な成果物が明示的に求められている場合を除き、React + Vite を標準として使用してください。
9. メイン見出しの上に置くヒーローのアイブロウ、キッカー、プレタイトル、バッジ、ピル型ラベルは、デフォルトでは使用禁止です。ユーザーが明示的に求めている場合、または承認済みデザイン／参照デザインに含まれている場合に限り使用してください。
10. まず Browser プラグイン／組み込みブラウザーで確認してください。Browser／IAB が利用できない、または信頼性に欠ける場合に限り、Playwright Chromium を使用し、代替手段を使った理由を明記してください。
11. 承認済みコンセプトと最新のブラウザーのスクリーンショットの両方に view_image を使用するまで、最終引き渡しはできません。これは省略できず、ブラウザー上で確認するだけでは代用できません。両者を直接見比べて、「制作会社の承認を得られる忠実な実装か」「優れた、熟練したデザイン会社が、この承認済みデザインの実装をこのまま承認するか」を判断してください。そうでなければ、修正を続けてください。
12. ユーザーまたはタスクから保持するよう明示的に求められていない限り、引き渡し前に一時的な QA 成果物を削除してください。

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

このスキルは、ビジュアルコンセプトの作成と忠実なフロントエンド実装を担当します。アプリにフロントエンド設計以外の機能が必要な場合は、ほかのインストール済みスキルを使用してください。プロバイダーの設定によって、Image Gen によるコンセプト作成、静的 UI の作業、またはプロバイダーに依存する動作を実行しないデザインレビューが妨げられることがあってはなりません。ただし、プロバイダーに依存する動作を実装・検証する場合は、その機能に対応するインストール済みスキルと連携してください。別のインストール済みスキルが設定方法を扱っている場合は、プレースホルダーを使った設定手順を避けてください。

AI／モデルによって生成される出力には、ユーザーが別のプロバイダーを指定するか、OpenAI を使用しないよう明示しない限り、利用可能であれば openai-developers:openai-platform-api-key を使用してください。このスキルが利用可能な場合は、偽のキー、プレースホルダーの環境変数、手動での API キー設定手順ではなく、必ずその認証情報フローを使用してください。

Image Gen のワークフロー

インストール済みの @imagegen スキルを読み、その指示に従ってください。ウェブサイト固有のブリーフ作成ガイダンスには、references/imagegen-website-concepts.md を使用してください。

Image Gen を呼び出す前に：

• ユーザーの具体的な要件をブリーフに盛り込んでください。製品／ページの目的、対象ユーザー、必要なセクションや状態、ワークフロー、提供されたコピー、ナビゲーションラベル、CTA ラベル、データフィールド、必要なメディア、レスポンシブ対応、実装上の制約などです。
• 求められている画面全体を含めるよう依頼してください。ページ全体、アプリ画面、ダッシュボード、ゲーム画面、または連携するセクション／状態のセットなどです。成果物がヒーローセクションを超える場合は、後続のセクション、状態、またはレスポンシブ表示の続きもコンセプトに含める必要があると伝えてください。必要なセクション数が既知、または要件から明らかな場合は、それぞれ独自のコンセプトスクリーンショットが必要なセクション／状態を列挙してください。
• 実装上の制約を繰り返し伝えてください。アプリ UI のテキストと操作部品はコードで表現すること、製品や背景のアセットは適切な場合に独自のテキストとブランド表現を含めて完全に描画すること、アセットを個別に分けること、再利用可能なコンポーネント群、意図的に選定したコンテナモデル、既定のカードグリッドを使わないこと、依頼または参考資料にないヒーローの見出し前フレーズ／導入文／バッジ／ピルを追加しないこと、実用的な HTML／CSS／コンポーネント実装にすることです。
• ユーザーのコンテンツ、スクリーンショット、または既存アプリの情報設計を維持してください。Image Gen に無関係なセクション、架空の指標、新しい製品上の主張、追加のダッシュボード、新たなナビゲーション、別の製品ストーリーを作らせないでください。
• 複数セクションのウェブサイトや長いランディングページでは、既定で主要なセクションごとに連携したコンセプト画像を 1 枚ずつ作成してください。全体像は構成やリズムを確認する目的で任意で作成できますが、テキスト、ボタンの詳細、カード構造、余白、タイポグラフィの分析が難しくなるような、巨大で圧縮された 1 枚のボードに頼らないでください。
• 情報量の多いアプリ、ダッシュボード、エディター、製品画面、複雑なセクションでは、全画面の 1 枚の画像では読み取れなくなる部分について、状態別または詳細なコンセプトを個別に作成してください。対象には、テーブル、サイドバー、インスペクター、モーダル、ツールバー、グラフ、フォーム、カード、料金プラン、推薦文、メディアモジュールなどがあります。
• コンセプトスクリーンショットが小さすぎる、ぼやけている、切れている、混み合っている、または判然としない場合は、コーディング前にそのセクション／状態／詳細のスクリーンショットを新たに単独で生成してください。配色、タイポグラフィの雰囲気、コンポーネント群、アセットの扱い、密度、セクション順序は維持してください。以前の画像の小さな部分を切り抜いたり、分割したり、拡大したりして、実装の基準として再利用しないでください。
• ゲームの場合は、コンセプトに加えて専用の Image Gen アセット制作を計画してください。背景に奥行きがある環境では、透明背景のキャラクター／状態スプライトまたはスプライトシート、地形／足場タイル、収集アイテム、危険物、ゴール／チェックポイントオブジェクト、小物、2～3 層の視差背景を用意してください。HUD テキスト、スコア、操作方法、物理挙動、衝突判定はコードで表現してください。

画面全体を求められているのにヘッダーだけのコンセプト、雑然としたもの、ありきたりなもの、反復的なもの、仕様が不十分なもの、読みづらいもの、装飾過多のもの、参考資料にあるか明示的に依頼されていないヒーローの見出し前フレーズ／導入文／バッジ／ピルを追加した仕様外のもの、または忠実な実装が現実的でないものは、採用せずに作り直してください。

デザイン品質基準

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

• 明確で独創的なアイデア、または一貫したビジュアルの視点を持たせます。
• ファーストビューでは、提供内容、プロダクトの魅力、主要なアクションが明確に伝わるようにします。
• ページ全体に心地よいリズムを持たせます。セクション、状態、遷移、モバイル表示が、カードの積み重ねや同じセクション構成の繰り返しに頼らず、一つのシステムとして設計されていると感じられるようにします。
• セクション間の流れに一貫性を持たせます。新しい主要 UI コンポーネントを作り出すのではなく、共通の余白、配色、文字組みのリズム、メディアの扱い、さりげない遷移でセクションをつなげます。
• 優れたタイポグラフィを採用します。階層、サイズ、ウェイト、行間、ラベルの扱いを明確にし、コントロールや UI の文字がブラウザーのデフォルトのサイズに戻らないようにします。
• 余白と情報密度に意図を持たせます。明示的に求められている場合や、採用済みのデザインに含まれている場合を除き、埋め草のカード、ヒーローのアイブロウ／キッカーラベル、ピル、バッジ、見せかけの指標、アイコンの並びは使いません。
• 基本はシンプルにします。ページをイラスト、アイコン、装飾ウィジェット、複雑な UI の装飾で埋めるのではなく、より少ない、より力強いビジュアル要素を使います。
• 一貫性のあるビジュアルシステムを構築します。配色、余白、角丸、境界線、シャドウ、グラデーション、アイコンのスタイル、画像、コンポーネントの形状を統一します。
• アイコンがある場合は、忠実に再現することが重要です。汎用的な類似アイコンに置き換えるのではなく、採用済みデザインのアイコンの比喩、線の太さ、塗りのスタイル、角の形、サイズ、色、配置、間隔に合わせます。
• 色の忠実な再現は必須です。採用済みデザインの実際の背景、サーフェス、文字、境界線、シャドウ、アクセントカラーに合わせます。デザインの背景が白の場合は、クリーム色、アイボリー、ベージュ、ウォームグレーなど、白に近い別の色ではなく白を使います。
• ヒーローメディアの扱いは、採用済みデザインに合わせます。コンセプトにヒーロー画像の色オーバーレイや色味がない場合、実装で追加してはいけません。画像の端をページになじませるためにエッジフェード、マスク、背景グラデーションを使うのは構いませんが、色オーバーレイで画像を覆ってはいけません。
• ロゴ、ブランドマーク、ヒーロー画像、プロダクトのレンダー、背景シーン、イラスト、テクスチャ、ポスター、アバター、空の状態、ゲームのスプライト／タイル／背景レイヤーには、高品質な生成アセットを使います。プロダクトや背景のアセットは、一貫したブランディングと、アセットに含まれるべきテキストを画像内に配置し、完全に仕上げます。
• 階層を明確にし、状態を伝え、プロダクトに実体感を持たせる、目的のあるモーションを使います。
• ユーザーから具体的なコピーが提供されていない場合は、具体的でありきたりではないコピーを用います。

デフォルトでは、すっきりとして、ゆとりがあり、品のある創造性 7/10 を目指します。デザインらしさを感じさせる独自性を持たせつつ、実装しやすい節度も保ち、繰り返しに頼らないようにします。「すっきり」とは、何もなく無機質な状態ではなく、無駄がなく読みやすい状態を指します。

ビジュアルデザインのデフォルト

ユーザーからより具体的なアートディレクションがない場合は、以下をデフォルトとして使用してください。あらゆるアプリをマーケティングサイト風に仕立てるのではなく、プロダクトの種類に合わせて調整してください。

• 基本方針：創造性はおよそ7/10、密度は低〜中程度、余白は十分に確保し、実装の明確さとタイポグラフィの規律を重視します。また、実際のビジュアルが効果を発揮する分野では、画像を活用した見せ場を設けます。
• コンセプトを生成する前に、一貫したビジュアルの方向性を選びます。テーマの枠組み、背景の特徴、タイポグラフィの特徴、ヒーローまたは主要画面の構成、セクションやアプリのリズム、特徴的なコンポーネントのモチーフを2〜4個、動きの手がかりを1〜2個決めます。組み合わせに一貫性を持たせ、汎用的なテンプレートではなく、意図の伝わるデザインに仕上げてください。
• ヒーローまたは最初のビューポート：明確な焦点を1つ設け、短く読みやすい見出しまたは主要タスク、控えめな補足文、目立つ主要アクション、小型ノート PC でも機能する十分な余白を確保してください。統計、チップ、バッジ、見せかけの操作部品、競合する小型パネルを詰め込み、最初の画面を混雑させないでください。
• ヘッダーはシンプルに：基本は、すっきりしたブランドマーク、必要なナビゲーション、主要なアクションまたはコントロールです。ユーザーから明示的に求められた場合や、プロダクトのワークフロー上必要な場合を除き、アイコンの多いナビゲーション、余分なボタン、検索バー、ステータスウィジェット、セグメントコントロール、装飾用イラスト、密度の高いプロダクト用 UI は避けてください。
• ビジュアルの節度：小さな装飾的ビジュアルを多数使うよりも、質の高い画像やイラストを1〜2点使うことを優先してください。アイコンは、ナビゲーション、コントロール、プロダクトの意味を明確にする場合にのみ使用してください。
• コンテナの扱い：コンセプトやプロダクトの種類に本当に必要な場合を除き、入れ子になったカード、各セクションを囲む大きな角丸コンテナ、定番のベントー／カードグリッド、枠で囲みすぎたダッシュボードは避けてください。開放的なレイアウト、帯、レール、リスト、テーブル、キャンバス、または意図的な枠組みを1つ使う構成を優先してください。
• セクションのリズム：長いページでは、1つの一貫したブランドシステムを保ちながら、密度、画像とテキストの比率、配置、スケール、余白、視覚的なテンポに変化をつけてください。ページ全体で同じ中央揃えのブロックや、左側のテキストと右側のカードの組み合わせを繰り返さないでください。
• セクションの連続性：複数のセクションコンセプトを1つのページにまとめる場合は、余白、帯、配置、繰り返し使うタイポグラフィ、共通のメディアフレーム、色のリズム、小さな余白の変化など、既存のデザインシステムを活用してつなげてください。ユーザーから求められた場合や、承認されたコンセプトに含まれる場合を除き、大型のカルーセル、アコーディオン、料金カード、ダッシュボード、フォーム、ナビゲーションシステム、機能グリッドなど、新しいコンポーネント群を勝手に追加しないでください。
• メディアのフレーミング：生成画像は通常、アスペクト比、トリミングのルール、角丸、影、余白に一貫性を持たせた、実装しやすく明確なフレームに配置してください。ユーザーが明示的に求めない限り、画像サイズをばらばらにしたり、まとまりのないコラージュにしたりしないでください。
• UI の節度：小さなラベル、ユーティリティ用のピル、システム風のマーカー、見せかけの指標、装飾的なダッシュボード用語は、プロダクトを明確にする場合にのみ使用してください。単なる視覚的な埋め草であれば、承認前に取り除いてください。

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

ユーザーが最初にコンセプトを生成するよう求めた場合、選択肢のレビューを求めた場合、または承認まで待つよう求めた場合にのみ使用してください。

• コンセプトを生成して提示します。
• ユーザーが承認するまで反復します。
• ユーザーがレビュー中の間は実装しないでください。
• 承認後は、コンセプトを有効な仕様として扱い、以下の忠実度ワークフローに従ってください。

コーディングの前に

コーディングに入る前に、承認されたコンセプトをデザインシステムと実装項目一覧に落とし込みます。

• 正確な表示テキスト、ナビゲーション項目、CTA ラベル、セクション見出し、実績を示す要素、データラベル、重要な UI テキスト。
• セクション／状態ごとの画像インベントリ：コンセプトの元スクリーンショット、ネイティブのアスペクト比、視覚的な優先度、読み取り可能なテキスト、タイポグラフィの関係、間隔、ボタン／コントロールのスタイル、コンポーネント／コンテナーのルール、主要な色、追加の抽出スクリーンショットが必要だった未解決の詳細。
• ファーストビューに表示可能なコピーの一覧：採用したコンセプトまたはユーザー提供のコピーから使用を許可された、表示されるすべてのヒーロー、ナビゲーション、アイブロウ／キッカー／プレタイトル、バッジ／ピル、CTA、ラベル、実績を示すテキスト。
• 最初のビューポートの構成、セクションの順序、後続の状態、レスポンシブ時の続き、次のセクションのプレビュー。
• セクションの連続性に関する計画：採用したデザインシステムを使って隣接するセクションをどうつなぐか、許可される主要なコンポーネントファミリー。表示されていない主要コンポーネントは、ユーザーが要求した場合、または必要なワークフローを機能させるために不可欠な場合を除き、使用禁止として扱ってください。
• ブランドマーク、画像の役割、製品モックアップ、ダッシュボード、テーブル、チャート、マップ、メディアレール、フォーム、HUD、その他の視覚的なアセット。
• ヒーロー／メディアの処理インベントリ：各画像について、オーバーレイなし、カラーオーバーレイ、グラデーションオーバーレイ、エッジフェード、マスク、透明背景、背景色との一致のいずれかを記録します。実装前に明示的に記録してください。
• 単独アセットの要件：コンセプトにロゴ、ブランドマーク、製品ラベル、パッケージ、ポスター、看板、製品レンダー、ブランド背景オブジェクトが含まれる場合は、ブランディングの一貫性を保つため、実装前に Image Gen の編集機能を使って対応する単独アセットを作成してください。
• ゲームアセットの要件：コンセプトがゲームの場合は、実装前に Image Gen を使って対応するプロダクションアートアセットを作成してください。必要に応じて、透明なスプライト／状態アセット、タイル／プラットフォーム、収集アイテム、ハザード、ゴールオブジェクト、小道具、パララックス／背景レイヤーを含めてください。衝突判定ボックスとゲーム状態にはコードを使用し、目に見えるアートの代用にはしないでください。
• 画像からサンプリングまたは概算したデザイントークン：背景、サーフェス、テキスト、薄い色のテキスト、境界線、影、アクセント、セマンティックカラー、角丸、エレベーション、間隔のスケール、モーションのタイミング。
• 色の固定：コンセプトの背景が純白、オフホワイト、クリーム色、グレー、ダーク、色付きのいずれなのかを明示し、その選択を正確に実装してください。パレットを暖色寄り・寒色寄りにしたり、彩度を落としたり、「より上品に」独自解釈したりしないでください。
• タイポグラフィシステム：フォントファミリー／フォールバック、文字サイズのスケール、ウェイト、行の高さ、字間、ラベルの処理、見出し／本文／キャプションのスタイル、コントロールのテキストスタイル、レスポンシブ時の文字サイズの挙動。
• アイコンインベントリ：表示されるすべてのアイコン、グリフ、シェブロン、ロゴ風マーク、ツールバー記号、状態記号、空状態記号。その意味、ソースファミリー、アウトラインか塗りつぶしか、線幅、サイズ、色、コンテナー、配置、間隔、選択時／ホバー時／無効時の処理も記録してください。
• コンポーネントファミリーとバリアント：ボタン、ナビゲーション、行、パネル、メディアフレーム、製品モックアップ、カード（存在する場合のみ）、テーブル、フォーム、チップ、アイコン、空状態、レスポンシブバリアント、ホバー／フォーカス／選択状態。
• 複雑なアプリ UI のコンポーネントアーキテクチャ計画：アプリシェル、ナビゲーション、主要な機能領域、再利用可能な UI プリミティブ、データ／状態ヘルパー、チャート／テーブル／フォームのモジュール、アセットモジュール、レスポンシブレイアウトの境界。優れたフロントエンド実装では、コンポーネントの責務を明確にし、巨大な App コンポーネントやコピーしたマークアップの寄せ集めを避けてください。
• コンテナーのモデル：カード、パネル、レール、バンド、リスト、テーブル、キャンバス、ドロワー、サイドバー、モーダル、フルブリードセクション。
• コアワークフロー：反応する必要があるコントロール、選択状態、フィルター、タブ、編集、作成フロー、成功状態、再生、ゲーム操作、生成結果のデモ。

コンセプトに必要な後続セクション、状態、モバイル表示、複雑な領域の読み取り可能な詳細が含まれていない場合、視覚的一貫性または抽出に不確実性があるときは、対応するセクション／状態／詳細のコンセプトを生成してください。それ以外の場合は、まったく同じビジュアルシステムで拡張してください。

実装

• 将来のアプリを囲い込むマーケティング用ラッパーではなく、実際に使えるサーフェスを最初に構築してください。
• リポジトリのフレームワーク、ルーティング、コンポーネント、スタイリング、状態管理、アクセシビリティ、アセットの規約に従ってください。
• 既存のフレームワーク制約がない状態で、新しい複雑なアプリ UI を作成する場合は、デフォルトで React + Vite を使用してください。シニアフロントエンドエンジニアが行うように構成してください。すなわち、小さく焦点を絞ったコンポーネント、明確なアプリシェル、繰り返し使われるコントロール向けの再利用可能なプリミティブ、ダッシュボード・テーブル・チャート・フォーム向けの機能別モジュール、分離されたサンプルデータと状態ヘルパー、共有トークンとスタイルです。App はモノリシックな画面実装ではなく、構成をつなぐグルーとして保ってください。
• 画像から抽出したデザインシステムを通じて実装してください。類似した要素は同じコンポーネントまたは共有スタイルプリミティブを使用する必要があり、差異は場当たり的にコピーした CSS ではなく、明示的なバリアントであるべきです。
• 承認されたコンセプトを正確に実装してください。コピー、階層、セクションの順序、密度、色、タイポグラフィ、余白、角丸、ボーダー、シャドウ、アセットのフレーミング、インタラクションモデルを維持してください。
• 複数セクションのページでは、承認されたセクションコンセプトに対応するスライス単位で実装してください。最初のビューポートから始め、そのブラウザスクリーンショットをセクションコンセプトと比較し、目に見えるずれを修正してから、セクションごとに続けてください。ページ全体をコーディングし終えるまで視覚的な比較をすべて先送りにしないでください。また、広い全体像の画像の方が追いやすいという理由だけで、セクション固有のデザイン判断を統合したり簡略化したりしないでください。
• 承認されていない主要な UI コンポーネントを追加することなく、セクションを 1 つのまとまりのあるページに接続してください。余白、背景の帯、配置、タイポグラフィのリズム、繰り返されるモチーフ、メディアのフレーミングを使ってギャップを埋めてください。承認されたコンセプトに含まれている場合、ユーザーから要求された場合、または具体的な機能上の必要性として記録されている場合を除き、ページを完成したように見せるために新しいカルーセル、アコーディオン、料金ブロック、ダッシュボード、フォーム、タブシステム、機能カードグリッド、その他の大きなコンポーネントを考案しないでください。
• コンセプト承認後は、承認されたコンセプトに含まれている場合、ユーザーから提供された場合、または意図的な逸脱として記録されている場合を除き、新たに目に見えるファーストビューのコピー、ヒーローのアイブロウ／キッカー、説明ラベル、サブタイトル、カテゴリテキストを追加しないでください。セマンティック HTML、SEO、アクセシビリティの理由で H1 や見出しレベルを変更する必要がある場合は、まず要素のセマンティクスを変更してください。補完する目に見えるコピーを考案しないでください。
• 承認されたデザインに存在しなかった装飾的なヒーローのアイブロウラベル、ピル、バッジ、グラデーション、グロー、オーバーレイを追加しないでください。コンセプトのパレット、方向、強度、配置に一致しない限り、グラデーション処理で代替しないでください。承認されたヒーロー画像にカラーオーバーレイがない場合は、その上に半透明の色合い、ウォッシュ、着色レイヤーを追加しないでください。画像を一致しないページ背景に自然に溶け込ませる必要がある場合は、画像の上にカラーオーバーレイを乗せるのではなく、一致するアセット、透明な切り抜き、エッジフェード、マスク、画像周囲の背景グラデーションを使用してください。白い背景をクリーム／オフホワイトに置き換えたり、承認された色温度を別のものに変えたりしないでください。
• コントロール上のタイポグラフィを意図的に定義してください。ボタン、タブ、入力、ツールバー、サイドバー、インスペクタパネル、レイヤー行、ステータスバー、コマンドパレット、エクスポート／共有コントロールについて、ブラウザのデフォルトや継承された 16px サイズに頼らないでください。
• コンテナモデルを維持してください。仕様でオープンな余白、帯、レール、リスト、テーブル、キャンバス、フルブリード構成が使われている箇所に、カード、ボーダー付きパネル、フローティングコンテナ、タイル、カードグリッドを追加しないでください。
• 実際のインタラクティブなアプリ UI のテキスト、ナビゲーション、ボタン、フォーム、テーブル、コントロール、ラベルはコードネイティブに保ってください。これは、製品画像、ポスター、パッケージ、看板、背景シーン、ヒーロー写真、その他のラスターアセット内に属するテキストやブランディングには当てはまりません。静的なスクリーンショットを UI として出荷しないでください。
• 中心となるアイコン以外のアセットには Image Gen を使用してください。製品画像や背景アセットは、必要なテキスト、ロゴ、マーク、ラベル、パッケージ、看板、ブランディングを含めて完全にレンダリングしてください。アセットを UI に重ねる必要がある場合は、透明背景またはクリーンな切り抜きを要求してください。アセットのテキストを正確に引用し、テキストが重要な場合は逐語的なレンダリングを要求してください。
• 承認されたデザインにブランド製品のイメージが含まれる場合は、Image Gen 編集を使用して、コンセプトまたは一致するアセットパスからロゴ／製品／パッケージ／看板アセットのスタンドアロン版を作成してください。それらのアセットを UI に重ねる必要がある場合は、透明背景のバリアントを含めてください。ブランドのラスターアセットを、汎用 CSS、一致しないフォント、近似ラベルから再構築しないでください。
• ゲームでは、目に見える制作アートに Image Gen を使用してください。キャラクター／状態スプライトまたはスプライトシート、地形／プラットフォームタイル、収集アイテム、危険物、ゴール／チェックポイント、前景プロップ、パララックス／背景レイヤーです。衝突、スケーリング、アニメーションがより簡単だからといって、canvas で描画した図形にフォールバックしないでください。HUD テキスト、スコア、コントロール、ヒットボックス、物理、ゲーム状態はコードネイティブに保ち、衝突ジオメトリをレンダリングされたアセットに合わせて調整してください。コードで描画した、またはベクターのゲームアートは、意図的な逸脱または具体的なブロッカーとして記載する必要があります。
• コンセプトのアセットを、粗い CSS 描画、汎用グラデーション、プレースホルダー SVG、ストック風のクロップで置き換えないでください。画像は構図の中に自然に収まる必要があります。背景色、ライティング、エッジ、クロップ、シャドウ、透明度が周囲のデザインと溶け合うようにしてください。SVG は忠実なアイコンや方向指示グリフには問題ありません。
• 矢印、シェブロン、キャレット、開閉インジケーター、ページネーション矢印、カルーセル矢印には SVG／アイコンコンポーネントを使用してください。コンセプトが意図的にそうしていない限り、プレーンテキストのグリフを使用しないでください。
• アイコンは他の視覚要素と同じくらい忠実に実装してください。承認されたデザインのスタイルに一致する場合に限り、リポジトリ既存のアイコンセットまたは lucide を優先してください。それ以外の場合は、コンセプトに一致する小さなカスタム SVG／アイコンバリアントを作成してください。カスタム SVG アイコンは制作品質のベクターアセットでなければなりません。明確な viewBox、クリーンなジオメトリ、一貫したストローク幅、整列した結合／キャップ、バランスの取れたネガティブスペース、光学的な中央揃え、スケーラブルなパス、ギザギザしたまたはプレースホルダーに見える図形がないこと、デザインシステムに一致する場合に限り currentColor または明示的な塗りを使用すること。塗りアイコンをアウトラインアイコンに、角丸アイコンをシャープアイコンに、太いストロークを細いストロークに、特定のメタファーを汎用記号に置き換えないでください。アイコンの色、光学的サイズ、ベースライン配置、パディング、インタラクティブ状態を、抽出されたアイコンインベントリと一貫させてください。
• アプリインターフェースを体験的にしてください。ローカル状態、意味のある選択状態、機能するフィルター／タブ／フォーム、編集可能または作成可能なアイテム、成功状態、再生コントロール、ゲームコントロール、または適切な場合はシミュレートされた生成出力です。
• ヒーロー内のインタラクティブ UI は、本当に適合する場合にのみ使用してください。SaaS／ソフトウェア製品のプレビュー、製品デモ、目的のあるインタラクティブアニメーションなどです。ブランド、エディトリアル、製品、会場、食品、消費者向け、背景主導のヒーローに、偽のインタラクティブクロームを無理に押し込まないでください。忠実な実装と一貫したブランディングは、インタラクティブ性の追加よりも重要です。
• モーションはデザインを支える場合にのみ追加してください。アクセシビリティと prefers-reduced-motion を尊重してください。
• 実装は本番志向に保ってください。セマンティックマークアップ、安定したレスポンシブ寸法、脆弱なハードコードのハックがないこと、リポジトリが対応している場合は型／lint／テストチェックです。

検証

アプリを実行し、ビルド結果だけでなく、画面に表示される製品を検証してください。

1. まず Browser/IAB を使用します。アプリを読み込み、最初のビューポートを確認してからスクロールし、主要なワークフローをクリックして操作します。
2. デスクトップ、現在のブラウザのビューポート、モバイルサイズのビューポートを確認します。
3. 承認済みのコンセプトと最新の実装スクリーンショットをキャプチャするか、場所を特定します。最終引き渡し前の同じ QA パスで両方に view_image を使用してください。この手順を省略したり、ブラウザで眺めるだけで代用したりしないでください。
4. 実用上可能であれば、承認済みコンセプトのネイティブ寸法で実装をキャプチャします。難しい場合は、その妨げとなる要因を記録し、現在のブラウザのビューポートも検証してください。
5. 最終確認の前に忠実度の記録を作成します。不一致、コンセプトの根拠、レンダリングの根拠、実施した修正または修正しなかった理由を記載します。複数のセクションや状態がある仕様では、概要だけでなく、該当するセクションや状態のコンセプトスクリーンショットから根拠を示してください。コピー、レイアウト、タイポグラフィ、配色／グラデーション、アセットの扱い、余白／コンテナモデル、レスポンシブ動作、モーションなどから、具体的な比較点を少なくとも 5 つ確認します。
6. コピー、ナビゲーション、CTA ラベル、セクションの順序、最初のビューポートのバランス、次のセクションの見え方、配色、グラデーションの扱い、フォントの個性、文字サイズの段階、余白、境界線、角丸、コンテナモデル、アセットと背景のなじみ方、モーション、シミュレーションされたインタラクションを並べて比較します。
7. ファーストビューのコピーを許可されたコピーリストと照合します。表示されるコピーの追加、削除、改名、順序変更は修正するか、意図的な差異として記載してください。承認されていない追加は忠実度の不合格となります。
8. ヒーローやメインキャンバスだけでなく、あらゆる場所のタイポグラフィを監査します。見出し、本文、キャプション、ラベル、ツールバーのコントロール、サイドバーの行、タブ、入力欄、インスペクターフィールド、ステータスバー、コマンドパレット、エクスポート／共有ボタン、テーブルのセル、グラフのラベル、モバイルでの改行を確認します。スクリーンショットからずれが疑われる場合は、計算済み CSS のサイズ、ウェイト、行の高さを使用します。
9. アイコンが表示されるすべての箇所を監査します。ナビゲーション、ボタン、カード、ツールバーのコントロール、サイドバー、テーブル、ステータス表示、空の状態、ページネーション、カルーセル、モバイルのコントロールを確認します。承認済みコンセプトと照らし合わせて、モチーフ、線や塗りのスタイル、サイズ、色、配置、見た目の重さ、間隔、状態の変化を確認します。
10. キャンバス／エディターアプリでは、アプリの外枠とキャンバス／ドキュメントのテキストを分けて監査します。デフォルトのズームとパンは仕様の一部です。保存されたローカル状態によって、シード、スケール、タイポグラフィの修正が検証時に隠れないようにしてください。
11. 明示的に問いかけます。これはデザイン会社の最終承認に耐えるほど忠実に実装されていますか。優れた高い技術を持つデザイン会社は、承認済みデザインのこの実装そのものに承認を出すでしょうか。デザインレビューで指摘される点がある場合は、具体的な修正チェックリストを作成して編集を続けます。修正可能な視覚上の問題を残したまま最終回答を出してはいけません。
12. 生成されたアセットが読み込まれ、適切に配置され、テキストやコントロールを覆い隠していないことを確認します。
13. 主要なワークフローによって、実際のローカル UI 状態が更新されることを確認します。反応しないコントロール、偽のメディア進行表示、隠された必須メディア、プレースホルダーのインタラクションを出荷してはいけません。

機能 QA は忠実度 QA の代わりにはなりません。ビルドチェックの合格、コントロールのクリック、ローカル状態の確認を、コンセプトとスクリーンショットの比較、ネイティブサイズの確認、書面による不一致の記録の代わりにすることはできません。

重大な不合格条件：主要コンテンツの切れ、意図しない折り返し、プロトタイプに見えるレイアウト、粗雑な初期データ、プレースホルダーのボックス、ありきたりなストック素材のようなアセット、未完成のカード、コンセプトアートの代わりにコードで描いたゲームのプレースホルダー、独自に追加された表示テキスト、独自に追加されたヒーローのアイブロウ／キッカー／ピル／バッジ、色やグラデーションの不一致、白い背景をクリーム色やオフホワイトに変更すること、承認されていないヒーロー画像へのカラーオーバーレイや色合いの追加、アイコンの欠落やありきたりな代替、アイコンのスタイルや線の太さの不一致、背景になじまない画像、古いデバッグ用の残骸、読みにくいテキスト、文字サイズの段階のずれ、ブラウザ既定のコントロールのタイポグラフィ、モバイルでのオーバーフロー、プロらしくないレスポンシブ時の崩れ、承認済み仕様からの目に見えるずれ。

表層のゲート

• ランディングページ／企業サイト：ファーストビュー、ヒーローの役割、ブランド／ナビゲーション／CTA のラベル、セクションの順序、次のセクションのプレビュー、特徴的な画像を維持します。
• 製品／SaaS ページ：製品のモックアップ、ワークフロー図、機能紹介の帯、信頼性を示す要素、ブランド表現を維持します。
• ダッシュボード／ツール：情報密度、サイドバー、ヘッダー、テーブル、タブ、タイムライン、チャート、マップ、行数、選択時／詳細表示時の挙動を維持します。テーブル主体のコンセプトをカードグリッドに変えないでください。
• キャンバス／エディターツール：デフォルトのズーム／パン、キャンバス／ドキュメントのテキストサイズ、UI の密度、ツールバー、サイドバー、インスペクターのコントロール、レイヤーの行、ステータスバー、コマンド操作面、自動保存／初期状態の挙動を維持します。
• タイムライン／計画ツール：グリッド／時間軸の構成、行の幅、イベントの密度、ステータスレール、コマンドセンターへの適合性を維持します。
• クローン風インターフェース：装飾を加える前に、認識可能な基本構成を維持します。製品の種類を損なうマーケティング用ヒーローや独自のナビゲーションを追加しないでください。
• ゲーム：Image Gen のアセットを使って、スプライト、タイル／足場、収集アイテム、障害物、ゴール／チェックポイント、小物、背景／パララックスレイヤーのアートディレクションを維持します。アセットが正しく読み込まれ、拡大縮小され、アニメーションまたは状態切り替えが適切に行われ、衝突判定の形状と合致し、移動、アクション／ジャンプ／ドラッグの挙動、スコアリング、障害物、再スタートに対応していることを確認します。
• メディア画面：メディアが正しく読み込まれ、再生時間、再生／一時停止、シーク／進行状況、表示フレームの変化を確認します。
• フォーム／予約／購入／レストランのフロー：主要な取引フローと確認状態を検証します。

最終回答

採用したコンセプトのパス、レンダリング済みスクリーンショットの取得方法、Browser/IAB による検証方法または Playwright に切り替えた理由、採用コンセプトと最新実装のスクリーンショットを view_image で確認した結果、確認したネイティブサイズのビューポートまたは阻害要因、比較して確認した少なくとも 5 つのポイント、ファーストビューのコピーの差分確認結果、意図的に残した差異を記載します。また、採用デザインに照らして実装を忠実に検証したことを明記してください。修正した重大な不一致と検証済みの主要な操作フローも記載します。重大な不一致が残っていない場合は、その旨を明記してください。