Communitygithub.com

ランディングページディレクター

ソース素材の取り込み、ガイド付きのデザイン決定、ネームドビジュアルディレクション、ロックされたデザインブリーフ、画像ファーストのセクションリファレンス、ブランド主導のモーションディレクション、実装、レスポンシブビジュアルQAを通じて、プレミアムなマーケティングランディングページ、キャンペーンページ、ワンページセールスサイト、ビジュアル重視のホームページをデザイン、構築、リデザイン、アニメーション、アートディレクションします。

ランディングページディレクター とは?

「ランディングページディレクター」は、AIエージェントが自由なスタイリングではなく、明確なデザイン決定のシーケンスを通じて、プレミアムなランディングページを作成するためのスキルです。このスキルは、ブリーフの理解、ビジュアルディレクションの絞り込み、デザインシステムのロック、リファレンスの作成、忠実なコード変換、そしてレンダリング結果の検査という一連のワークフローを自動化します。Claude CodeやCursorなどのAIエージェント上で動作し、ユーザーが「このランディングページをプレミアムに見せて」や「スクロールアニメーションを追加して」といった漠然とした要求をした際に、画像生成、コード生成、ブランド一貫性チェック、ブラウザベースのビジュアルテストなどのツールを連携させて、一貫性のある高品質な結果を提供します。スキルは、段階的なワークフローステートマシンに従い、ソース素材の棚卸し、最大6つの質問によるガイド付き意思決定、3つの名前付きビジュアルディレクションの提案、デザインブリーフのロック、画像ファーストのセクションリファレンスの作成、コードへの変換、そして最終的なビジュアルQAを実行します。このプロセスにより、ブランドの一貫性、モーションの意図、レスポンシブ対応が保証され、ダッシュボードやネイティブアプリなどの不適切なユースケースでは使用されません。

対応~Claude Code~Codex CLI✓Cursor
npx skills add https://github.com/Aston1690/landing-page-skill/tree/HEAD/skills/landing-page-director

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

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

ドキュメント

ランディングページディレクター は何をしますか?

ランディングページを自由なスタイリングではなく、明確なデザイン決定を通じて作成します。品質は、ブリーフを理解し、ビジュアルディレクションを絞り込み、システムをロックし、リファレンスを作成し、それらを忠実に変換し、レンダリング結果を検査するというシーケンスから生まれます。

このスキルはランディングページのワークフローを所有します。画像、翻訳、テスト、ブランド、コピー、またはフレームワークのスキルが専門的な作業に貢献することはありますが、このワークフローを置き換えたり、競合する2番目のアートディレクションを導入したりしてはなりません。

デフォルトの実行

アートディレクションと完全なビルド/レビューループには、このディレクターを使用してください。design-harnessがインストールおよび設定されている場合は、それをロードして、独立した実装、保存されたコンテキスト、ブラウザの証拠、および制限されたリビジョンに使用します。それ以外の場合は、これらのステージを直接実行して記録します。実行可能なハーネスチェックが実行されたと主張しないでください。ユーザーが2番目のスキルを呼び出す必要はありません。単一のステージを割り当てられた子は、別のオーケストレーションループを開始せずに親に戻らなければなりません。

互換性

ビジュアルリファレンスには組み込みの画像生成を使用し、最終的なビジュアルQAにはブラウザ対応の検査ツールを使用します。imagegen-frontend-web、image-to-code、brand-consistency、およびplaywright-visual-testingが利用可能な場合はそれらを調整します。フルランディングページのビルドおよび大規模なリデザインには、デフォルトでGSAPのコレオグラフィーを使用し、ローカルなインタラクションフィードバックにはCSSを使用します。明示的な静的リクエスト、保存制約、および既存の必須モーションシステムを尊重します。

中核契約

  • 承認されたコピー、事実に基づく主張、ロゴ、ブランドアセット、ページ順序、およびソーステンプレート要件はロックされたものとして扱います。
  • クライアントのウェブサイト、コンテンツソース、ブランドガイド、ロゴ、フォント、提供されたメディア、製品ビジュアル、および関連するリファレンスがまだ利用できない場合は、それらを尋ねます。最初のメッセージに何も添付されていなかったという理由だけで、ソースマテリアルが存在しないと決して想定しないでください。
  • アートディレクションを提案する前に、提供されたすべてのドキュメント、URL、画像、ブランドファイル、およびリポジトリソースを読み込み、インベントリを作成します。
  • 統計、 testimonial、賞、クライアント、認証、場所、連絡先詳細、製品スクリーンショット、または証拠を決して捏造しないでください。
  • 安全に省略できない場合は、[TO BE CONFIRMED]を使用して不足情報を可視化します。
  • 実装前に、1つの一貫したビジュアルランゲージを確立します。
  • ユーザーがビジュアル承認のチェックポイントを要求しない限り、日常的なアートディレクションとリファレンス選択の決定を自分で行います。エージェントが選択したリファレンスを正直に記録し、決してユーザー承認済みとは呼ばないでください。コンテンツの不確実性とロックされた要件との競合はエスカレーションしますが、通常のデザイン選択はエスカレーションしません。
  • スペクタクルよりも、コントロールされた読みやすい階層を優先します。プレミアムな結果は、巨大なタイポグラフィ、混雑したヒーロー、装飾的なマーク、または過剰なブランディングに依存してはなりません。
  • モーションをビジュアルランゲージの一部として扱います。目的、個性、タイミングシステム、および動きを抑えた対応物を与えます。
  • 正確に1つのプライマリテイストディレクションを使用します。複数のスタイルスキルやムードボードをブレンドしないでください。
  • コーディング前にビジュアルリファレンスを生成し、批判的にレビューします。
  • 静的に見えるモックアップではなく、動作するページを構築します。
  • 完了を報告する前に、実際のレンダリングページをデスクトップとモバイルの両方の幅で検査します。

ワークフローステートマシン

ステージを順番に従います。ユーザーがそのステージで確立されるすべてのものをすでに提供している場合にのみ、ステージをスキップします。ブリーフ、ファイル、会話、ブランドキット、またはリファレンスURLにすでに存在する情報をユーザーに繰り返し尋ねないでください。

1. ブリーフを読み、分類する

ユーザーに何かを尋ねる前に、会話とワークスペースにすでに存在するすべてのものをインベントリします。guided-intake.mdを読み、ソースセットが欠落または不完全な場合は、そのソースマテリアルの事前チェックを実行します。

ソースインベントリには以下が含まれます:

  • クライアント名、現在のウェブサイトまたはソースページのURL、タスクが新しいページ、リデザイン、クローン、または拡張のいずれであるか
  • 承認されたコンテンツドキュメント、コピーのステータス、必要なページ/セクションの順序、主張、法的テキスト、およびプライマリコンバージョン
  • ブランドガイド、ロゴ、マーク、色の仕様、フォントファイルとライセンス、アイコンシステム、および以前のコラテラル
  • 提供された写真、動画、イラスト、図、製品スクリーンショット、UIキャプチャ、 testimonial、証拠、およびコンプライアンス資料
  • 競合他社やインスピレーションのリファレンス(クライアントが好きなものと嫌いなものを含む)
  • 既存のリポジトリ、フレームワーク、コンポーネントシステム、技術的制約、アナリティクス/フォームの送信先、およびデプロイ期待値

何も存在しない場合は、プロジェクトがグリーンフィールドであることを記録し、アセットが提供されたふりをせずに進めます。ユーザーがウェブサイト、ドキュメント、フォルダ、またはアセットセットが存在するがアクセスできないことを示した場合は、それに依存する決定を下す前に、URL、添付ファイル、パス、または権限をリクエストします。

タスクを分類します:

  • 新規でビジュアルが未定義: ガイド付きインテークとディレクション選択を実行します。
  • 新規で明示的なビジュアルブリーフがある場合: コンパイルされたブリーフを確認し、リファレンスに進みます。
  • リファレンス主導またはクローン: リファレンスを分析し、要求された構造、コンテンツ、およびインタラクションモデルを保持します。
  • リデザイン: ディレクションを提案する前に現在のページを監査します。既存の機能とロックされたコピーを保持します。

コードを変更する前に、リポジトリとそのインストラクションファイルを検査します。ユーザーが明示的に移行を要求しない限り、既存のフレームワーク、パッケージマネージャー、コンポーネント規則、およびランタイムを保持します。

2. 必要に応じてガイド付きインテークを実行する

デザイン決定が委任された場合は、クライアントのコンテキストから未解決のビジュアルプリファレンスを選択し、インタビューを実行する代わりにその理由を記録します。以下の質問は、ユーザーが協力的なディレクション選択を望んでいる場合、または重要な要件を安全に推測できない場合にのみ使用します。

ソースマテリアルの事前チェックはデザインの質問の前に行われ、デザイン質問数の制限にはカウントされません。会話、ワークスペース、現在のウェブサイト、または接続されたソースですでに見つかった資料については尋ねないでください。

一度に1つの決定を尋ねます。各質問には、2つまたは3つの相互に排他的な選択肢を含め、推奨する選択肢を最初に配置し、そのビジュアルまたは商業的な効果を1文で説明し、自由形式の代替案を許可します。「Direction 1 of 4」のような進行状況を常に表示します。

未解決の決定のみを優先します。典型的な漠然としたブリーフには、4つの決定が必要です:

  1. ビジュアルディレクション
  2. カラームード
  3. タイポグラフィのキャラクター
  4. ヒーロー/レイアウト構造

イメージ、モーション、またはコンバージョンアーキテクチャについては、ブリーフからそれらを推測できない場合にのみ尋ねます。モーションが商業的または物語的に重要な場合は、エクスペリエンスが控えめ、表現力豊か、またはスクロール主導のいずれであるべきかを尋ね、パフォーマンスのトレードオフを説明します。ユーザーがより深いワークショップを要求しない限り、インタビューは6つの質問以下に抑えます。

重要なディレクションの選択が未解決の間は、コーディングを開始しないでください。

3. 3つの名前付きディレクションを提示する

未定義のブランドディレクションの場合、同じレイアウトの3つのカラーバリエーションではなく、真に異なる3つのルートを提案します。各ディレクションは以下を指定する必要があります:

  • 記憶に残る名前
  • 戦略的アイデアとオーディエンスへの印象
  • フォントペアリングまたはタイポグラフィカテゴリ
  • 代表的なカラーの役割を持つパレットムード
  • ヒーロー構成
  • ヒーローの密度、見出しのスケール範囲、最初のビューポートのコンテンツ予算、および折り返しより下に意図的に配置されるもの
  • 画像処理
  • ナビゲーションとフッターでのロゴ処理(背景処理と最大ビジュアルフットプリントを含む)
  • サーフェス、ボーダー、半径、およびシャドウのキャラクター
  • CTA処理と、プライマリコンバージョンが装飾的な乱雑さなしにビジュアル的に支配的になる方法
  • モーションのキャラクター
  • 主なトレードオフ

デザインが委任された場合は、ルートを簡単に比較し、最も強いものを選択し、そのヒーローリファレンスを生成します。それ以外の場合は、1つのルートを推奨し、要求された協力的チェックポイントのために代替案を提示します。1つの選択されたルートでタスクが解決される場合に、3つの完全なディレクションを生成することは避けます。

4. デザインブリーフをコンパイルしてロックする

design-brief-schema.mdを読みます。その構造を使用して、プロジェクト内にDESIGN-BRIEF.mdを作成します。

visual-calibration.mdを読み、具体的なビジュアルターゲットと修正ループを確立します。これは、ブリーフが「プレミアム」、「モダン」、または「もっと良くして」だけを言っている場合に特に重要です。

選択を実装準備ができたルールに変換します。名前付きフォント、ウェイト、タイプスケール、カラートークン、グリッド、最大幅、スペーシングリズム、半径、ボーダー、シャドウ、画像ルール、セクションリズム、インタラクション、モーショントークン、モーション削減、およびブレークポイント変換。

また、後期段階でのリジェクトを引き起こす一般的な実用的な構成制約もロックします:

  • デスクトップとモバイルでの最大ヒーロー見出し幅とサイズ
  • 最初のビューポートの優先順位順序と、テキスト、メディア、証拠、アクションの密度予算
  • ヘッダーの高さと最大ロゴの高さと幅。マークを背景なしで配置する必要がある場合は、真に透明なアセットを使用します
  • スケール、コントラスト、配置、およびサポートコンテキストによるプライマリCTAの顕著性
  • インデックス、仕切り、ボーダー、アイコン、テキスト間の最小クリアランス
  • セクション固有の構成ルール。証拠、成功、プロセス、コンバージョンセクションが同じカードグリッドのバリエーションにならないようにします
  • 承認された処理、好まれない処理、後でページに再登場してはならない拒否されたモチーフ

3種類の情報を分離します:

  • ロック済み: 承認されたコピー、ブランド事実、提供されたアセット、選択されたディレクション。
  • 派生: デザイントークン、レスポンシブ動作、構成ルール。
  • 未解決: まだ確認を待っている情報。

このスキルにバンドルされたスクリプトがアクセス可能な場合は、node scripts/validate_design_brief.mjs <project>/DESIGN-BRIEF.mdを実行します。続行する前に、欠落またはプレースホルダーセクションを修正します。

5. 画像ファーストのセクションリファレンスを作成する

imagegen-frontend-webをロードし、組み込みの画像生成機能を使用します。

ページのナラティブを計画します。最初にヒーローリファレンスを生成し、批判的にレビューし、弱い構成を修正してから他のセクションに拡張します。計画されたセクションごとに、1つの別々の大きな横長のリファレンス画像を生成します。7つのセクションがあるページは、7つのセクション画像を受け取ります。フルページのコンポジットから小さな断片を切り取る代わりに、新しい詳細リファレンスを生成します。

すべてのリファレンスでこれらを一定に保ちます:

  • パレットとカラーの役割
  • フォントペアリングとタイポグラフィの個性
  • グリッドロジックとスペーシングリズム
  • ボーダー、半径、アイコン、サーフェスランゲージ
  • 画像処理とアートディレクション

セクション構成を意図的に変化させます。デフォルトで左テキスト/右画像、カードグリッド、弁当箱コンテナ、および特大の中央揃え見出しを繰り返すことは避けます。

プロジェクトバウンドのリファレンスをdesign-references/の下に、01-hero.png、02-proof.png、03-product.pngのような順序付けられた名前で保存します。承認されたリファレンスをビジュアルの真実のソースとして扱います。

リファレンスを孤立したボードとしてだけでなく、現実的なビューポートクロップでレビューします。実装前に、以下を確認します:

  • ヒーローには1つの支配的なメッセージ、1つの支配的なアクションがあり、証拠、画像、ラベル、装飾デバイスの競合するクラスターがないこと。
  • 表示タイプは、キャンバスに対して過剰なサイズではなく、通常の表示サイズで自信を持って見えること。
  • ヘッダーロゴは視覚的にナビゲーションに従属し、誤って白い長方形やミスマッチした背景を導入しないこと。
  • 最終的なコンバージョンセクションは、中央揃えのコピーとボタンだけでなく、十分なコントラストとビジュアルウェイトを持つデザインされた瞬間であること。
  • 番号付き行、タイムラインステップ、およびルール付きリストは、行の両側に十分な余裕があること。
  • 構成や意味の代わりとして装飾記号が使用されていないこと。

ディレクション選択とリファレンスレビューは別々のチェックポイントです。名前付きルートは、その実行が良いことを確立しません。ユーザーがリファレンスを拒否した場合は、それを修正します。拒否された構成からコーディングを開始しないでください。

静止画像はタイミングを完全に指定することはできません。動く各セクションについて、デザインブリーフに簡潔なモーション注釈を追加します。トリガー、シーケンス、空間的変化、期間、イージング、繰り返し、モバイル適応、および動きを抑えた結果。リファレンスに奥行きやレイヤー画像が含まれているという理由だけで、アニメーションを発明しないでください。

ユーザーがビジュアル承認を要求した場合は、リファレンスを表示し、そのチェックポイントで待機します。それ以外の場合は、批判的レビュー後にリファレンスを選択し、自律的に続行します。このワークフローでは、エージェントによって受け入れられたリファレンスは実装の真実のソースとして機能できますが、ユーザー承認済みとして説明してはなりません。

6. リファレンスをコードに変換する

image-to-codeをロードし、承認されたすべてのリファレンスをタイポグラフィ、スペーシング、カラー、構成、画像、コンポーネント、レスポンシブの意図、およびインタラクションの手がかりについて分析します。

セクションを構成する前に、以下のセマンティックトークンを実装します:

  • 背景、前景、ミュートテキスト、アクセント、ボーダー、サーフェスの色
  • 表示用および本文用のフォントファミリー
  • タイプスケールと行間の関係
  • スペーシングリズムとコンテンツ幅
  • 半径、ボーダー、シャドウレベル
  • モーションの期間とイージング

最初のビジュアルスライスとしてヘッダーとヒーローを実装し、残りのセクションを変換する前に1440ピクセルと390ピクセルでそれらを検査します。この時点でロゴのスケールと背景、ヒーローの密度、見出しの折り返し、CTAのウェイト、およびフォールドの構成を修正し、弱い最初の画面がページ全体に伝播しないようにします。

利用可能な場合は、ロゴに内在的な透明な画像アセットを使用します。CSSブレンディング、白いコンテナ、クリッピング、またはフィルターは、不要な埋め込み背景を削除する代わりにはなりません。ロゴのサイズは、ソースビットマップの寸法だけでなく、可視マークによって決定します。

ルール付きまたは番号付きのコンポーネントでは、番号と仕切りまたはコンテンツエッジの間に明示的なスペーシングを確保します。レンダリング結果の光学的なクリアランスを確認します。数学的に等しいパディングでも、細いルールの近くでは窮屈に見えることがあります。

関連スキル