Communitygithub.com

フロントエンドアプリビルダー (Frontend App Builder)

洗練されたフロントエンドアプリ、ダッシュボード、ゲーム、クリエイティブウェブサイト、リデザインなどを、プロダクト品質のイメージ生成デザインと忠実な実装で構築するスキルです。

フロントエンドアプリビルダー (Frontend App Builder) とは?

このスキルは、プロフェッショナルなフロントエンドアプリケーションやウェブサイトをゼロから構築するための包括的なガイドです。主な特長は、まず上級デザイナーとして振る舞い、視覚的に美しく、セクションごとに明確なイメージ生成コンセプトを作成した後、それをエンジニアとして忠実に実装する点にあります。クリーンで風通しがよく、読みやすく、区別されたデザインを生成し、承認されたデザインとブラウザでのレンダリング結果が10/10の一致度になるまで修正を繰り返します。Codex、Claude Code、CursorなどのAIコーディングエージェント上で動作し、React + Viteをデフォルトとしますが、ユーザーが特定のフレームワークを指定した場合や既存のリポジトリに従う場合もサポートします。ワークフローには、イメージ生成によるコンセプト作成、ユーザー承認、デザイントークンの抽出、厳密な実装、そしてブラウザでの検証が含まれます。特に、ヘッダーのみの不完全なコンセプトを拒否し、全ページ・全状態をカバーする完全なデザインを要求します。

対応~Claude Code✓Codex CLI~Cursor
npx skills add https://github.com/illuminatedworm/terrarium-tavern/tree/HEAD/.agents/skills/frontend-app-builder

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

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

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

基本基準

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

  1. まず十分に優れたイメージ生成デザインを(必要に応じてセクション固有で、デフォルトでは反復しないように)作成します。クリーンで、風通しがよく、区別され、完全で、読みやすいものにします。
  2. 承認されたデザインとブラウザ実装が10/10で一致するまで止まりません。view_imageでの比較がエージェンシーの承認を通過できるようになるまで、視覚、インタラクション、レスポンシブ、アセット、タイポグラフィの不一致を修正し続けます。

ハードルール

  1. ユーザーが明示的にオプトアウトした場合、またはタスクが既存のデザインシステム内での小さなUI修正である場合を除き、ビジュアルコンセプトにはImage Genを使用します。
  2. コーディング前に、要求された完全な表面をデザインします。フルページ、アプリ、ダッシュボード、ゲーム、または製品インターフェースの場合、ヘッダーやヒーローのコンセプトだけでは不十分です。複数セクションのウェブサイトや長いランディングページでは、詳細が失われる1つの縦長画像に頼るのではなく、セクションごとの調整されたコンセプトと、リズムをつかむためのオプションの概要を優先します。アプリ、ダッシュボード、ゲーム、またはコンパクトな製品サーフェスの場合、最初に完全なプライマリ画面と、必要な状態、レスポンシブ、アセットのコンセプトを生成します。
  3. Codex内では、複数セクションのウェブサイトコンセプトをデフォルトで、主要セクションごとに1つの新鮮で大きな、読みやすいImage Genスクリーンショットにします。リクエストに1〜10のセクションがある場合、約1〜10の主要セクション画像が期待されます。テキスト、ボタン、カードの構造、タイポグラフィ、間隔、色が抽出するには小さすぎる場合はいつでも、追加のセクション/詳細スクリーンショットを生成します。以前の全ページ画像をメインリファレンスとしてトリミングしたりズームしたりしないでください。同じデザインシステムを維持した新鮮なスタンドアロンセクションまたは詳細画像を再生成します。
  4. 計画モードでは、最初にデザインを生成し、実装の詳細を計画する前に request_user_input を使用してデザインの承認を得ます。
  5. 一旦承認されると、コンセプトはプロダクションのデザイン仕様です。実装中に創造的自由は許されません:レイアウト、表示コピー、階層、コンテナモデル、スタイリング、画像、密度、またはセクションを、ユーザーが承認するか、具体的な障害によって必要とされない限り、再解釈しないでください。一般的なデザインヒューリスティックが承認されたコンセプトをオーバーライドすることは決してありません。
  6. 完了バーはエージェンシー承認の忠実な実装です:承認された仕様への10/10の忠実度とプロダクション品質のコード。ブラウザでレンダリングされたUIがデザインレビューコメントを受けるような場合は、修正を続けてください。
  7. コーディング前に、承認された画像から小さなデザインシステム(トークン、タイポグラフィ、コンポーネントファミリー、バリアント、間隔、アイコン処理、コンテナルール)を構築します。ツール、エディター、ダッシュボード用のコンテンツタイポグラフィとUIクロームタイポグラフィの両方を含めます。そのシステムから実装し、繰り返し要素が一貫性を保つようにします。
  8. ダッシュボード、管理ツール、エディター、データ重視のツール、マルチパネル製品サーフェスなどの新しい複雑なアプリUIの場合、ユーザーが別のフレームワークを指定していない限り、デフォルトでReact + Viteを使用します。既存のリポジトリがすでに別のフレームワークを指示している場合、またはタスクが明示的に単一ファイル/静的デリバラブルである場合も同様です。
  9. ヒーローのアイブロー、キッカー、プリタイトル、バッジ、またはメイン見出しの上のピルラベルは、デフォルトでは禁止されています。ユーザーが明示的に要求した場合、または承認された/リファレンスデザインにすでに含まれている場合にのみ使用します。
  10. まずブラウザプラグイン/組み込みブラウザで検証します。Playwright Chromiumは、ブラウザ/IABが利用できないか信頼できない場合にのみ使用し、フォールバック理由を述べてください。
  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つの巨大な圧縮ボードに決して依存しないでください。
  • 高密度のアプリ、ダッシュボード、エディター、製品サーフェス、複雑なセクションの場合、単一の全画面画像で読み取れなくなる領域(テーブル、サイドバー、インスペクター、モーダル、ツールバー、チャート、フォーム、カード、価格ブロック、お客様の声、メディアモジュール)に対して、別の状態または詳細コンセプトを生成します。
  • コンセプトスクリーンショットが実装に小さすぎる、ぼやけている、トリミングされている、混雑している、または曖昧な場合は、コーディング前に新鮮なスタンドアロンのセクション/状態/詳細スクリーンショットを生成します。同じパレット、タイポグラフィのムード、コンポーネントファミリー、アセット処理、密度、セクション順序を維持します。以前の画像の小さな部分を切り取ったり、スライスしたり、ズームしたり、再利用したりして、真実のソースとして使用しないでください。
  • ゲームの場合、コンセプトに加えて専用のImage Genアセットパスを計画します:透過的なキャラクター/状態スプライトまたはスプライトシート、地形/プラットフォームタイル、収集アイテム、障害物、ゴール/チェックポイントオブジェクト、小道具、環境に奥行きがある場合は2〜3のパララックス/背景レイヤー。HUDテキスト、スコアリング、コントロール、物理、衝突はコードネイティブのままです。

完全な表面の要求に対してヘッダーのみのコンセプト、散らかったもの、一般的なもの、反復的なもの、仕様が不十分なもの、読みにくいもの、装飾過多なもの、明示的に要求または参照に存在しないヒーローのアイブロー/キッカー/バッジ/ピルを含む仕様から外れたもの、または忠実に実装するのが現実的でないものは拒否または反復します。

デザイン品質基準

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

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

デフォルトでクリーンで、風通しがよく、センスの良い7/10の創造性:デザインされたと感じられるほど区別され、構築できるほど抑制され、反復的ではありません。「クリーン」は編集され読みやすいと解釈し、空っぽで無菌的ではありません。

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

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

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

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

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

  • コンセプトを生成して表示します。
  • ユーザーが承認するまで反復します。
  • ユーザーがまだレビューしている間は実装しません。
  • 一旦承認されたら、コンセプトをアクティブな仕様として扱います。

…

[翻訳のため一部省略]

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

関連スキル