vibe-to-ui

vibe-to-ui

バイブコーディングに取り組む開発者のためのローカルデザインコンパニオンです。まず、対象ページのアーキタイプと情報密度を分類し、ユーザーのプロダクト背景をもとに、参考資料から実現可能なビジュアルと空間設計の方向性を3つ導き出してから、そのうちの1つをデザインシステムとしてまとめます。モーションシステム、コンシューマーアプリのUI/UX要件、ビジュアルアセットの方向性、ムードボード、プレビューなどを含む「スタイルDNA」を抽出し、漠然とした美的感覚を、実際のプロダクトの画面に適した、プロダクトを考慮したデザイン上の判断へと変換します。インスピレーションには、ウェブサイトのURL、スクリーンショット、画像、音楽、または漠然とした意図を利用できます。エージェントはユーザーが提供したものに応じて対応します（references/INSPIRATION-SOURCES.md を参照）。事例は、プロフィールに生の事例を含めることなく、グローバルなインスピレーションライブラリの ~/.vibe-to-ui/inspirations/<product>/pages/<page>/ に保存できます（全ページスクロールの分析、モーション、注釈付きの preview.html、プロダクトレベルの統合を含みます）。また、再利用可能なデザインコンテキストプロファイルを ~/.vibe-to-ui/profiles/<profile>/ に保存し（ブランドマスター、トークン、判断、アセットを含みます）、必要に応じて任意の中間ターゲット向けに適応させることもできます。web、social-cover、hyperframes などがあり、ユーザーが独自に定義することもできます（例：linkedin、print-brochure）。これにより、ユーザーデータがスキルのインストールや更新に結び付くことはありません。探索はすべてスタンドアロンのプレビューを通じて行います。エージェントがユーザーのプロジェクトに手を加えるのは、ユーザーが方向性を確認し、適用を依頼した場合に限られます。

Tip：Git ベースのデザインコンテキストのリモート同期（context remote / context sync）では、独自のプライベートリポジトリを介して ~/.vibe-to-ui の profiles/ と inspirations/ を共有できます。Git を超えるホステッド型の複数プロジェクト管理については、MonkeyUI SaaS をご覧ください。

このスキルを使用するタイミング

• ユーザーがWebサイトのURL、スクリーンショット、またはデザインモックアップを提示し、そのデザインシステムを抽出したい場合
• ユーザーがWebサイトのURLまたはスクリーンショットと製品のコンテキストを提示し、それを文字どおり模倣するのではなく、エージェントに3つのビジュアル方向性へと展開してほしい場合
• ユーザーが、対象がランディングページ、ブランドページ、ダッシュボード、B2B向けの高密度な運用ページ、テーブル詳細管理ページ、ドキュメントページ、オンボーディングフロー、コンシューマーアプリ／C向けアプリの画面、または別のページ類型のどれにあたるか、まずエージェントに特定してほしい場合
• ユーザーが漠然とした美的イメージを持っており、WebサイトのURL、インスピレーション画像、または音楽の録音を使ってデザインの方向性を探りたい場合
• ユーザーが、UIに感じさせたい雰囲気を伝えるために音楽の録音や音声クリップ（メロディー、曲の一部、鼻歌の録音）を共有する場合
• ユーザーが、望む美的イメージに結びつけている曲、ジャンル、音楽的な印象を説明する場合
• ユーザーが、ページをよりリラックスした、エディトリアルな、映画的な、落ち着いた、開放的な、高級感のある、遊び心のある雰囲気にしたい場合、または一般的なSaaSのランディングページとは違う印象にしたい場合
• ユーザーが、写真、風景、建築、インテリア、雑誌、ポスター、パッケージ、ファッション、アルバムカバー、映画のスチル、イラスト、音楽、動画の参考例など、UI以外のインスピレーションを共有し、そこから得られる特徴をレイアウトの判断に反映したい場合
• ユーザーが、ページの実際のユースケースに合ったモーションシステムを定義したい場合。エージェントに観察させるため、公開中のサイトのURLを共有することも含みます
• ユーザーが「信頼できる」「革新的」「遊び心がある」などの製品の個性や雰囲気を説明し、それに合ったモーションの指針を求めている場合
• ユーザーが、対象ページの種類にふさわしいまま、誤った類型へと逸れないムードボードを作りたい場合
• ユーザーが複数の参考画像やサイトURLを集め、それらを一貫したビジュアルストーリーにまとめたい場合
• ユーザーが、審美的な意図を共同作業者や関係者に伝えるための共有可能なデザイン成果物を求めている場合
• ユーザーが、製品やデザインの方向性に合った、個性的なアイコン、イラスト付き機能アイコン、3Dオブジェクトアイコン、ソーシャルビジュアル、または生成されたブランド素材を求めている場合
• ユーザーが、（コンセプトプレビュー、ムードボード、デザインシステムのプレビューなどから）デザインの方向性を確定し、それをプロジェクトに適用したい場合
• ユーザーが、WebサイトのURLまたはスクリーンショットからブランドのビジュアル言語をローカルのDesign Context プロファイル（ブランド／製品／クライアント）に保存し、個々のプロジェクトリポジトリとは切り離しておきたい場合
• ユーザーが vibe-to-ui context --profile <profile> --target <medium> を実行する、または実行方法を尋ねる場合。web、social-cover、hyperframes、あるいはユーザー定義の linkedin、print-brochure など、任意の媒体向けに媒体固有のルールを読み込む、または生成して、対応するエージェントに渡します
• ユーザーがプロジェクト横断型のインスピレーションライブラリを求めている場合。製品ページ（URL／スクリーンショット）を ~/.vibe-to-ui/inspirations/<product>/ に集め、ページ全体の美的特徴とモーションを分析し、製品レベルのビジュアル上のポジショニングを取得して、必要に応じて製品をプロファイルにリンクし、確認後にのみ製品の design-seed.md をプロジェクトの DESIGN.md に統合します

参考資料の優先順位ルール

ワークフローを選ぶ前に、ユーザーの入力を分類します。

• 雰囲気／ムードの参考資料：写真、風景、建築、インテリア、雑誌、ポスター、パッケージ、ファッション、アルバムカバー、映画のスチル、イラスト、音楽、動画、抽象的なイメージ
• 具体的なUIの参考資料：WebサイトのURL、製品／Webページ／アプリのスクリーンショット、ローカルプロジェクト、既存のコードベース

両方がある場合は、必ず次の優先順位に従います。

1. 具体的なUI／プロジェクトへの忠実度
2. ページ種類への忠実度（目的、情報密度、インタラクションモデル、モジュールの構成）
3. ビジュアル素材への忠実度（画像の使い方、タイポグラフィ、情報密度の扱い、ガラス表現、モーションの強さ）
4. 雰囲気の調整

インスピレーションソースの受け付け

ユーザーが提供するものは何でも受け付けます。ウェブサイトの URL、スクリーンショット、ムード画像、音楽、ローカルプロジェクト、説明、またはそれらの組み合わせが対象です。特定の入力方法を優先することはありません。references/INSPIRATION-SOURCES.md に従ってください。

• URLが共有された場合 → アクセス／取得して、フロントエンドの手がかりを読み取り、キャプチャします（Inspiration Library：ページ全体をスクロール、その他の機能：選択的にキャプチャ）。必要に応じて動きも観察します
• スクリーンショットまたは画像が共有された場合 → 直接分析します。最初に URL を尋ねてはいけません
• 音楽／雰囲気／説明が共有された場合 → ムードに基づく方法を使います。実際に閲覧できるサイトにこだわってはいけません
• 複数のソースが混在する場合 → それぞれの役割に応じて使用し、どのように重み付けしたかを明示します

この受け付け方は、ソースの種類が該当する場合、Capabilities 1–4、Motion System、Mood Board、Design Context 全体に適用されます。URL を最優先するのではなく、いずれも同等の選択肢として扱います。

必須ステージ 0：ページタイプの特定

デザインシステムの抽出、空間的な雰囲気の探索、ムードボードの生成、プロジェクトへの適用を行う前に、対象のページタイプを分類してください。

必ず次の項目を示します。

1. 主なページタイプ
2. 必要に応じて副次的な修飾パターン
3. 密度レベル：低／中／高
4. 確信度：高／中／低
5. 根拠：分類の判断材料となったシグナル
6. デザイン上の影響：この分類が余白、階層、画像、コンポーネント、動きに与える意味

次のシグナルを使ってページタイプを分類してください。

• ビジネス目標：コンバージョン、閲覧、監視、データ入力、コンテンツ消費、設定、実行
• 情報密度：画面上で同時に競合するコンテンツの量
• 主な操作方法：スクロール、読解、絞り込み、比較、編集、承認、レコードの詳細表示
• 主要なモジュール：ヒーロー、機能グリッド、テーブル、チャート、サイドバーナビゲーション、詳細ペイン、フォーム、ウィザード、フィード
• 意思決定の速さ：感情に訴える説得、落ち着いた読解、素早い確認、反復操作

一般的なページタイプ：

1. ランディング／マーケティングページ：説得力のあるストーリーテリング、目立つヒーロー、低めの密度、強い視覚的演出
2. ブランド紹介／ポートフォリオ：プレゼンテーション重視、没入感のある画像、エディトリアルなリズム
3. コンテンツ／ドキュメント／エディトリアルページ：読みやすさ、タイポグラフィの階層、安定したナビゲーション
4. E コマース／カタログページ：閲覧、絞り込み、比較、商品カードのシステム
5. B2B ダッシュボード／概要：指標、監視、要約、中〜高密度
6. B2B ワークベンチ／高密度な業務ページ：反復操作、フィルター、テーブル、ステータスチップ、コンパクトな余白
7. データ管理／テーブル・詳細ページ：レコード一覧＋詳細＋一括操作、厳密な一覧性
8. フォーム／オンボーディング／ウィザード：段階的な手順、フォームのグループ化、完了時のフィードバック
9. 一般消費者向けアプリ画面：C 向けのプロダクト体験。通常はモバイルファーストまたはアプリ風で、タスク指向ながら B2B システムより感情に訴える要素が豊かです。カード／フィード、タブ、オンボーディング、空の状態、詳細画面への遷移を中心に構成されることがよくあります

ページが複数のタイプにまたがる場合は、主なタイプを1つ選び、副次的なパターンを記載してください。例：「主：B2B ワークベンチ、副：ダッシュボードの概要。」

2つの作業モード

• リファレンス忠実度モード：ユーザーが具体的な UI、スクリーンショット、ライブページ、またはローカルプロジェクトを提供した場合に使用します。まずページタイプと構造的な印象を合わせ、その後、ムードを調整する前に、出力が参照元に見覚えのある形で近づくようにします。参照元のレイアウト構造を維持するには、references/SPATIAL-VIBE.md の構造抽出手順に従ってください。
• ムード変換モード：ユーザーが雰囲気の参照や抽象的な印象のみを提供した場合に使用します。プロダクトの文脈から想定されるページの類型を推測し、そのムードを類型に合った UI の方向性に変換します。

具体的な UI またはプロジェクトが提供された場合は、既定でリファレンス忠実度モードを使用してください。

絶対に守るべきルール

• ページの種類、密度レベル、操作モデル、ページ構成、タイポグラフィの階層、マテリアルの表現、モーションの強さを特定する前に、自由な解釈へ飛躍しないでください。
• ムードがページの種類と衝突する場合は、まずページの種類を優先してください。アーキタイプを意図せず変えてしまうのではなく、そのアーキタイプの範囲内で雰囲気を調整してください。
• ユーザーが戦略的な再ポジショニングを明示的に求めていない限り、密度の高いB2B業務画面をシネマティックなランディングページ風に仕上げないでください。
• ランディングページ／ブランド／ショーケースの画面では、大きな画像、ゆとりのある間隔、より表現豊かなモーションを取り入れてもかまいません。
• B2Bダッシュボード／高密度の業務画面／テーブル詳細の画面では、一覧性、状態の明確さ、コンパクトで一貫した間隔、フォームやテーブルの読みやすさ、控えめなモーションを優先してください。
• コンシューマーアプリ／C向けアプリの画面では、モバイルファーストの階層、ナビゲーションの明確さ、タッチ時のフィードバック、状態の網羅性、空状態やオンボーディングの品質、ブランドの印象深さを優先し、アプリ画面をランディングページのようにしないでください。これが主要なページの種類である場合は、references/CONSUMER-APP-DESIGN.md を使用してください。
• 参考資料で最も強く印象づけられる要素が写真の風景である場合は、原則として実際の風景画像を主要なビジュアルレイヤーに使用してください。ユーザーがイラストや抽象表現を明示的に求めていない限り、CSSで生成した風景に置き換えないでください。
• 具体的なUIの参考資料とムード画像の両方が提供された場合、ムード画像は副次的な資料として扱ってください。ムード画像は出力の調整に使い、参考資料の構成やページの種類に取って代わるものではありません。
• ユーザーが具体的なUIの参考資料と製品の背景情報を提供した場合、原則として参考資料を起点とした検討を行ってください。参考資料のページの種類と構造上の特徴を忠実に保ちつつ、ムード、マテリアルの表現、密度の扱い、モーションをユーザーの実際の製品コンテキストに合わせた3つのビジュアル案を導き出してください。
• デザインシステムを直接抽出する方法を最初に使うのは、ユーザーが復元、トークン抽出、完全な再現、または「このデザインシステムを分析して」と明示的に求めた場合に限ります。それ以外の場合は、具体的な参考資料からトークンを体系化する前に、コンテキストに即した3つのビジュアル案を作成してください。
• ページの種類の確信度が低い場合は、デザインシステムを体系化する前に、短い確認質問を1つしてください。
• テキストのみではなく、ビジュアルをデフォルトで出力してください。すべての検討、抽出、ムードボード、空間的な雰囲気を扱うワークフローでは、原則として単体で表示できるHTMLのビジュアル成果物を少なくとも1つ生成してください。プレビュー、ビジュアル案、モックアップ、デモを明示的に求められるまで待たないでください。
• ビジュアルの方向性を決めるワークフローでは、Markdownによる分析だけで終わらせないでください。テキスト分析はビジュアル成果物を補足するものであり、その代わりにはなりません。
• UIを生成する前に、次の内容を簡潔に要約してください。
  • 推定されるページの種類と密度
  • 参考資料と似た状態に保つ必要がある要素
  • 調整可能な要素
  • タスクが「参考資料忠実性モード」と「雰囲気変換モード」のどちらで進行するか

永続的な DESIGN.md のコンテキスト

プロジェクトに DESIGN.md がある場合は、ビジュアルデザインに取り組む前に読み、継続的なプロダクト／デザインのコンテキストとして活用します。ファイルがなく、ワークフローを通じて重要なプロダクト戦略やビジュアル戦略が定まった場合は、assets/DESIGN.md を使って作成するか、該当するセクションを追加します。連携プロトコルについては、references/CONTEXT-COLLABORATION.md を参照してください。

会話を通じて明らかになった次の内容を、必要に応じて DESIGN.md に反映します。

• プロダクトの定義、ユーザー、ユースケース、個性、制約
• ページの種類、情報密度、インタラクションモデル、およびデザインへの影響
• 確定したビジュアルの方向性、ムードを表すキーワード、タイポグラフィの姿勢、モーションの個性、画像の方針
• icon_system：固定された UI アイコンライブラリ、カスタム SVG のフォールバック、プリセット、グリッド、ストロークのルール、ユーザーによる上書き
• illustrated_icon_system：有効な対象サーフェス、プリセット、形式、ビジュアルファミリーのルール、スタイル参照、避ける対象サーフェス
• ビジュアルアセットマニフェストのパス、レビュー対象サーフェスのパス、選択した組み合わせ、配置に関するメモ、検証ステータス、確定済みアセット、却下したアセット、再生成に関するメモ
• 使用中のアクティブな Design Context プロファイル ID（例：Iteration Context 内の design_context_profile: vibe-to-ui）

この情報の管理をユーザーに求めないでください。デザイン上の判断に影響する場合、または適用した変更をまとめる場合に限り、言及してください。

ローカルの Design Context プロファイル（~/.vibe-to-ui/）

プロジェクトやメディアをまたいで再利用できるブランドの記憶をユーザーが求める場合は、Capability 7 と references/DESIGN-CONTEXT.md を使用します。

• プロファイルはブランド、プロダクト、またはクライアント（例：vibe-to-ui、acme-brand）を指し、出力プラットフォームではありません。
• ライブデータは ~/.vibe-to-ui/profiles/<profile>/ 配下だけに保存します。スキルテンプレートの assets/design-context/ はコピー元として使い、ライブストアとしては使用しません。
• スキルのインストール、更新、再インストールによって、~/.vibe-to-ui/ を上書き、削除、リセットしてはいけません。
• --list / --init / --target のライフサイクル、マージ処理、オプションの Git リモート同期（remote connect / remote status / sync）には、Node CLI（bin/vibe-to-ui.js）を優先して使用します。
• targets/<medium>.md ファイルは、そのメディアについて初めて依頼されたときに作成し（ID は自由に設定できます。web / social-cover / hyperframes はあくまで例です）、以降は再利用して更新します。
• ブランドの一貫性を保つには、アクティブなプロファイルの brand.md と tokens.json を優先して使い、プロダクトやページ固有のコンテキストにはプロジェクトの DESIGN.md を使用します。

インスピレーションライブラリ（~/.vibe-to-ui/inspirations/<product>/）

プロジェクトをまたいで外部のデザイン参考資料を収集し、理解したいとユーザーが求める場合は、Capability 8 と references/INSPIRATION-LIBRARY.md を使用します。

• グローバルライブラリであり、プロファイルの配下には置きません。保存単位は URL ごとのフォルダーではなく、複数のページ（pages/<slug>/）を含むプロダクトです。
• すべての URL ページで、ページ全体のスクロールをキャプチャした画像とモーションに関するメモが必要です。product.md には、複数ページにわたるビジュアルの特徴をまとめます。
• プロファイルには、inspiration-refs.json を通じてプロダクトへの参照のみ保存できます（デフォルトは reference-only）。
• 生のインスピレーション事例をプロファイルにコピーしないでください。デフォルトの apply ではプロダクトのシードを使用します。プロジェクトの DESIGN.md への記載は、確認後に行います。
• CLI を優先して使用します：vibe-to-ui inspiration add|list|show|link|apply|rebuild-product

8 つの主要機能

1. デザインシステムの抽出（デザインスタイルの復元）

ユーザーが完全な UI リファレンス（Web サイトの URL、スクリーンショット、デザインモックアップ）を提示します → デザインシステムを抽出し、プロジェクトに適用する前にユーザーが確認できるスタンドアロンのプレビュー画面を生成します。

トリガー：ユーザーが「このスタイルを抽出して」「ここで使われているデザインシステムは？」「このデザインを分析して」「https://…を分析して」「どんなモーションが使われている？」「これにかなり近い形で再現して」「このスタイルを復元して」などと言った場合、またはコンセプトの検討ではなく、明確に正確なトークン化を求めている場合です。

ワークフロー：

1. Web サイトの URL、スクリーンショット／画像、またはユーザーが提示したものを受け取ります。URL がある場合は、そのリンクについて references/INSPIRATION-SOURCES.md に従います。画像のみの場合は、直接分析します。
2. ステージ 0：ページタイプの識別を実行します。
3. リファレンスを体系的に分析します（URL からの場合は、ライブ CSS／DOM と選択的なキャプチャを使用）。ただし、ページタイプの視点からトークンを解釈します。
   • レイアウトのリズムと密度
   • タイポグラフィの階層と読みやすさの要件
   • 色の意味。特に B2B 向け画面におけるステータスカラーと優先度カラー
   • 分類されたアーキタイプに適したコンポーネントパターン
4. ページタイプを考慮してモーションシステムを分析します（Motion DNA のみ。まだ Motion Engine Router は読み込みません）。
   • ランディングページでは、より豊かなエントランスアニメーションを取り入れられます
   • ダッシュボードでは、控えめなトランジションと、フォーカスを維持する動きを優先します
   • 情報密度の高いワークベンチでは、スキャンを妨げる装飾的なモーションを避けます
   • コンシューマー向けアプリでは、すばやく触覚的なフィードバック、明確な画面遷移、完全なモーション低減時のフォールバックが必要です
   • リファレンス／雰囲気からテンポ、イージング、密度、距離、個性、および 1 つのシグネチャーモーションモチーフを抽出します（references/MOTION-SYSTEM.md を参照）。
5. 次の内容を含む、構造化されたデザインシステムを出力します。
   • ページタイプの概要
   • ページのアーキタイプから導き出したデザイン上の制約
   • ビジュアルトークン
   • モーショントークンとシグネチャーモーションモチーフ
   • 該当する場合は、references/CONSUMER-APP-DESIGN.md に記載されたコンシューマー向けアプリのシステムフィールド
6. ユーザーがより充実した美的ガイド（トークンだけでなく、デザインの本質に踏み込んだもの）を求めている場合は、references/AESTHETIC-ANALYSIS.md に従って美的分析ドキュメントも生成します。ただし、ページタイプの制約を優先します。
7. 抽出したデザインシステムをサンプルコンポーネントに適用したスタンドアロンのプレビュー画面を、HTML アーティファクトとして生成します。この時点では、まだプロジェクトには適用しません。プレビューのモーションコードを記述する際は、references/MOTION-ENGINE-ROUTER.md を段階的に読み込みます。Motion DNA をコンパイル → スタックファミリー（web／react／vue）を検出 → 1 つのエンジン階層とスタックバインディングを選択 → 1 つの主要レシピを選択（DNA／シグネチャーモーションモチーフに合わせてパラメーターを変更し、レシピのデフォルトをそのまま使わない）→ 依存関係、モバイル、モーション低減時のフォールバックを用意します。Router が L5 MiniMax Video を選択した場合に限り、references/VIDEO-MOTION.md を読み込みます。
8. ページタイプの分類と抽出値の両方について、ユーザーに確認または調整を依頼します。
9. ユーザーが確認したら、Capability 5（デザインをプロジェクトに適用）に進み、実際のプロジェクトにデザインシステムを統合します。

2. デザインの探索

ユーザーは雰囲気やイメージを持っているものの、具体的なデザインの目標はありません → インタラクティブな会話を通じて、目的のページアーキタイプに合う美的方向性を見つけて定義し、共同で検討するためのスタンドアロンのコンセプトプレビューを生成します。 トリガー：ユーザーが「〜のような雰囲気のものがほしい」「参考画像があります」「https://… を参考にしてください」「どんなスタイルにしたいか、まだ決まっていません」「この色はそのままにして、ほかのスタイルも試してください」などと伝える場合、ムードや風景の写真、求める雰囲気を表す音楽の録音や曲を共有する場合、または具体的な UI の参考資料（URL またはスクリーンショット）と製品の背景情報を示し、それを複数のビジュアルの方向性に展開するようエージェントに求める場合。 ワークフロー:

1. ユーザーにプロジェクトの背景を尋ねます：
   • 何をするものか
   • 対象ユーザーは誰か
   • 主なページの種類は何か。不明な場合は推測します
2. ステージ 0：ページタイプの特定を実行します
3. 参考にしたいものを、希望する形式で共有してもらいます：Web サイトの URL、画像、オブジェクト、風景、音楽の録音や音声クリップ（references/INSPIRATION-SOURCES.mdを参照）。送られた内容に応じて対応し、URL へ誘導しないでください。
4. 具体的な UI の参考資料がある場合は、シグナルを次のように分けます：
   • 維持すべき構造的な DNA：ページタイプ、構成のリズム、モジュールの組み合わせ、階層のロジック
   • 調整可能なスタイルの要素：素材の表現、タイポグラフィの印象、密度の調整、色温度、動きの特徴
5. URL、画像、説明、音楽の録音ごとに、次の美的特性を特定します：
   • 色の雰囲気（暖色系／寒色系／落ち着いた色合い／鮮やか）
   • 質感（滑らか／粗い／有機的／幾何学的）
   • 空間の印象（密度が高い／開放的／構造的／流動的）
   • 感情的なトーン（遊び心がある／真面目／高級感がある／ミニマル）
   • 動きの印象（静止／流れる／キビキビしている／弾む／映画的）
6. シグナルを次の 2 つのグループに分けます：
   • 固定すべきページタイプの制約
   • 変更可能なスタイル上の自由度
7. 3 つの方向性についてタイポグラフィを検討します。それぞれについて、次の項目を明確に定義します：
   • 見出しと本文のフォントの組み合わせ
   • タイポグラフィの印象（エディトリアル／ニュートラル／実務的／温かみがある／プレミアム／遊び心がある）
   • 対象ページタイプに合わせた読みやすさの方針
   • フォントのウェイト戦略と階層の印象
   • 必要に応じて CJK 対応または多言語対応のフォールバックを含むフォールバックスタック
   • 参考画像だけでなく、ユーザーのプロダクトの背景にこのタイポグラフィの方向性が合う理由
8. 調査結果をまとめ、異なる 3 つのデザインコンセプトを作成します。それぞれに次の内容を含めます：
   • 参考資料またはプロダクトの背景を明確に継承していること（参考資料からすでに配色とスタイルが示されている場合、デフォルトで別途スタイルメニューを提示しないでください）
   • 色を変えるだけではない、独自のタイポグラフィの方向性
   • 動きの個性と特徴的な動きのモチーフ 1 つ（この方向性の動きを印象づけるもの）
   • 密度の方針
   • ページタイプに適している理由の明確な説明
   • コンシューマーアプリの画面の場合は、独自のアプリ体験の方針：ナビゲーションモデル、主要なループ、主要な状態の方針、触覚的な操作感
9. 各コンセプトのムードボードを、ユーザーが雰囲気を感じて比較できる独立した HTML 成果物として生成します。references/MOOD-BOARD.mdを参照してください。
10. 各コンセプトについて、自己完結した独立した HTML 成果物としてコンセプトのプレビュー用ページを生成します：

• 実際のページのアーキタイプを反映した、スタイル付きのサンプルカードまたはモジュール
• コンセプト名、カラースウォッチ、タイポグラフィの根拠、フォントのサンプル、ミニレイアウトのデモ
• 以下の探索段階のモーションのルールを使ったモーションのプレビュー（実装を正式化するようユーザーから求められない限り、完全版の Motion Engine Router はまだ読み込まないでください）
• 必要に応じて、見出し、本文、ラベル、データ密度の高いテキストを明確に比較
• コンシューマーアプリの画面では、references/CONSUMER-APP-DESIGN.mdにある現実的なアプリのモジュールを表示します：ナビゲーション、主要画面、詳細／作成フロー、通常とは異なる状態、タップ／シート／タブの動き
• これらは探索用の独立したページであり、ユーザーのプロジェクトは変更しません

11. ユーザーに意見や比較、選択または要素の組み合わせをしてもらいます。他のスタイル（または配色）の探索を明示的に求められた場合に限り、必要に応じた検討を実行します。そのレイヤーで 3 つの案を提示し、他のレイヤーは固定してから再度結び付けることを優先します。references/DESIGN-EXPLORATION.mdを参照してください。
12. ユーザーが決定したら、Capability 1（デザインシステムの抽出）を適用し、モーションのトークンを含む完全なデザインシステムとして選択した方向性を正式化します
13. Capability 5（プロジェクトへのデザイン適用）に移り、確定したデザインを実際のプロジェクトに統合します。適用時は、プロダクション向けのモーションコードのためにreferences/MOTION-ENGINE-ROUTER.mdを読み込みます。references/VIDEO-MOTION.mdは、Router が L5 MiniMax Video を選択した場合に限り読み込みます。

探索段階の仮モーション（Router 読み込み前）

Capability 2 のコンセプトプレビューやムードボードでも、モーションには意図を持たせつつ、軽量に保つ必要があります。

1. コンセプトごとに暫定版 Motion DNAを作成します。テンポ、イージング、密度、移動距離、個性、シグネチャーモチーフを定めます。
2. スタンドアロン HTML では、CSS カスタムプロパティと CSS トランジション／キーフレームのみを使用して実装します（GSAP/OGL/Three の CDN デモは使用しません）。
3. シグネチャーモチーフを1 つと、基本的なフィードバック（ホバー／タップ）を示します。Consumer アプリでは、CSS を使ったシートのせり上がりとタブインジケーターも示します。
4. 3 つのコンセプトでシグネチャーモチーフに変化をつけ、比較の対象を色だけでなく「感触」にします。
5. 探索段階では、ライブラリのデフォルトデモ、何もかもをフェードアップさせる演出、あらゆる要素にバウンスを付ける演出、パーティクルフィールド、紫色のグローループは禁止です。
6. ユーザーが方向性を確認し、本番品質のモーションコードが必要になった時点で、Motion Engine Routerを読み込みます。

3. 空間的な雰囲気の探索

ユーザーが漠然とした美的意図や複数の参考イメージを持っており、その感覚をページレベルのレイアウト判断に反映したい場合です。

トリガー：ユーザーが「このランディングページをもっと落ち着いた印象にして」「エディトリアルで雑誌のような雰囲気にしたい」「このカフェ、映画のワンシーン、アルバムカバーの雰囲気が好き」「レイアウトの構成には https://… を使って」「よくある SaaS ランディングページのようには見せないで」などと言う場合、または UI 以外の参考資料やサイト URL を共有し、それがページにどう反映されるべきかを尋ねる場合です。

ワークフロー：

1. ステージ 0：ページタイプの特定を実行し、製品の目標、UX 上の制約、対象コンテンツ、避けたい参考例を確認します。
2. 構成の参考資料（ページ構成に影響を与える資料）と、雰囲気の参考資料（印象、リズム、密度、強調方法に影響を与える資料）を区別します。
3. 参考資料をそのまま模倣するのではなく、ユーザーが各資料のどこを気に入っているのかを特定します。
4. 参考資料から応用可能な要素を抽出します。
   • コンテンツの密度と余白
   • 階層と視覚的な主役
   • 空間的なリズム、対称性／非対称性、セクション間の遷移
   • カードの使い方、画像の見せ方、操作のテンポ、レスポンシブ対応方針
5. そのまま UI の判断に反映すべきではない、応用できない要素を明示します。例：海岸沿いの道路の写真は、開放感、広いネガティブスペース、ゆったりしたリズム、控えめな密度を示唆する場合がありますが、ヒーローに道路の写真を置くべきという意味ではありません。
6. 製品の制約と参考資料から、ページのSpatial DNAを動的に導き出します。あらかじめ定義された雰囲気のテンプレートや固定のスタイル分類は使用しません。
7. 配置、リズム、階層、レスポンシブ時の動作を考えるための内部的な思考の足場として、非表示の構成グリッドを使用します。ユーザー向けの成果物や固定テンプレートとして提示してはいけません。
8. 本番コードを変更する前に、スタンドアロンのプレビューとして実質的に異なる 3 つのレイアウト案を作成します。デフォルトではモード A：比較可能な完成版レイアウト案を 3 つ提示します。各案には、ユーザーが読み取れる小さなレイアウトスケッチまたはサムネイル、スケッチの凡例／コンテンツマップ、Spatial DNA の要約、セクションの順序、主なレイアウト判断、トレードオフ、レスポンシブ対応方針が必要です。
9. ユーザーが単一の推奨案を明示的に求めていない限り、内容の薄い 3 枚の案カードを見せてから 1 案だけを詳しく説明してはいけません。1 案を推奨する場合は、推奨案であることを明示しつつ、3 つの案すべてを完成版として提示します。
10. 凡例なしで「copy」「cards」「idx」「specimen」「CTA」のような説明のない構成上の略記を使ってはいけません。各ブロックにどのコンテンツが含まれ、なぜ存在するのかをユーザーが理解できるようにします。
11. レンダリング結果を確認し、ありきたりな印象、製品との不一致、参考資料の表面的な模倣、ユーザーにとっての分かりにくさ、3 つの案の詳細度の不均衡があれば修正します。

4. ムードボードの生成

ユーザーがインスピレーションや美的な要素を統合して、厳選したビジュアルコラージュを作成したい場合 -> 対象のページタイプを尊重した、インタラクティブな HTML ムードボードを生成します。

トリガー：ユーザーが「ムードボードを作成して」「ビジュアルの方向性をボードで見たい」「インスピレーションボードを作って」「これらの参考資料をムードボードにまとめて」などと言った場合、または複数の参考画像や要素を集めており、デザインシステムの抽出に進む前に、まとまりのあるビジュアルの要約を求めている場合です。

ワークフロー：

1. Design Exploration、ユーザー提供の画像、または直接の説明から、すでに確立されている美的な要素を集めます
2. まだ実施していない場合は、ステージ 0：ページタイプの識別を実行します
3. 内容を厳選します。すべての参考資料をボードに載せる必要はありません。対象のページの類型に一貫したストーリー性をもたらす要素を選びます。
4. プロジェクトの空間的な個性とページタイプを反映するムードボードのレイアウトパターンを選びます：
   • ランディングページ／ブランド：大きなヒーロー要素と、より強いビジュアルストーリーテリング
   • B2B／データ中心：UI の断片、密度のサンプル、タイポグラフィのリズム、状態を示す色の使い分け
   • コンシューマーアプリ：モバイル UI の断片、タブ／フィード／詳細のリズム、空の状態やオンボーディングのトーン、触感を想起させるモーションの手がかり
5. 次の内容を含む、自己完結型の HTML ムードボードを生成します：
   • テーマのタイトルとムードを表すキーワード
   • 対象のページタイプと密度に関する注記
   • 主役となるビジュアル、または代表的な UI の断片
   • 使用比率を反映した色見本によるカラーの方向性
   • 提案するフォントで実際のテキストを表示したタイポグラフィの見本
   • テクスチャと素材のサンプル
   • 空間とモーションの手がかり
   • デザイン原則または指針となる声明
6. ユーザーが複数の方向性から選んでいる場合は、コンセプトごとに 1 つずつ、比較用のムードボードを複数生成します
7. ムードボードを提示し、ユーザーに「これはどんな感じがしますか？」と直感的な反応を促します。「これで正しいですか？」とは尋ねません
8. ユーザーが方向性を確認したら、ムードボードをデザインシステムの抽出（Capability 1）の素材として使用します

5. デザインをプロジェクトに適用する

ユーザーがデザインの方向性を確認しました（探索コンセプト、デザインシステムのプレビュー、またはムードボードから）→ 確定したデザインシステムをユーザーの実際のプロジェクトに適用します。

トリガー：ユーザーが「このデザインを適用して」「これを使って」「この方向性で進めよう」「これをプロジェクトに組み込んで」「コンセプト B をプロジェクトに適用して」といった内容を伝える場合、またはプレビューに満足し、コードベースへの適用を希望する場合です。

確認済みの方向性を適用する作業には、異なる 2 つのレイヤーがあります。ユーザーがどちらを希望するか確認してください。多くの場合、両方を適用します。

• トークンの適用：ビジュアルおよびモーションデザインのトークン（色、タイポグラフィ、スペーシング、角丸、シャドウ、モーション）。これらはフレームワークに依存しない値です。
• レイアウト／構造の適用：確認済みの空間／レイアウト DNAとセクション構成（Capability 3 および references/SPATIAL-VIBE.md を参照）。これにより、選択したレイアウトの方向性を単なる値ではなく、実際のページ構造に反映します。

ワークフロー：

1. 適用するレイヤー（トークン、レイアウト、または両方）とプロジェクト内の適用先を確認します
2. ユーザーのプロジェクトを調査し、既存のフレームワーク、CSS のアプローチ、ファイルの規則、既存のデザイントークンやページ構造を把握します
3. 適用するトークンとコンポーネントが対象の画面に沿うよう、確認済みのページタイプ分類を再確認します
4. トークンを適用する（対象範囲内の場合）：ユーザーの技術スタックに基づいて適切なトークンファイル（CSS カスタムプロパティ、Tailwind 設定、JSON トークン）を生成し、プロジェクトに統合します。プロジェクトの規則を尊重し、新規ファイルを作成するか既存ファイルにマージします
5. レイアウトを適用する（対象範囲内の場合）：確認済みの空間／レイアウト DNA とセクションの順序をプロジェクトの構造に反映します。セマンティックな骨組み、セクション構成、グリッド／スペーシングの関係、レスポンシブ時の折りたたみロジックを含めます。汎用的なページテンプレートを使うのではなく、選択したレイアウトの方向性を再利用し、適用したトークンをその構造に組み込みます
6. 作成または変更した内容を明確にまとめ、トークンの変更と構造の変更を分けて説明します
7. ユーザーにレビューと反復を促します。適用後も共同作業を続けます

重要：この機能は、エージェントがユーザーのプロジェクトファイルを変更する唯一のタイミングです。それ以前の探索（コンセプトのプレビュー、ムードボード、デザインシステムのプレビュー、レイアウトの方向性のプレビュー）で作成されるのは単独の成果物であり、プロジェクトには手を加えません。

ユーザーがビジュアルアセット付きの方向性を確認した場合は、references/APPLY-DESIGN.md のステップ 3.5 に従って、画像とアセットマニフェストもデプロイしてください。

Consumer アプリの画面では、Apply の際に references/CONSUMER-APP-DESIGN.md にも従い、モバイルファーストのレイアウト、ナビゲーションモデル、タップ領域、安全領域のスペーシング、キーボード／入力の動作、状態マトリクス、承認済みの表現豊かなアセット用スロットを確認してください。

6. ビジュアルアセットの生成

ユーザーが、確認済みまたは進行中のデザインの方向性と同じスタイル DNA を持つ、プロダクトに沿ったイラスト（ヒーロー、機能紹介、空の状態、OG 画像）を希望しています → ホストの画像ツールでアセットを生成し、アセットマニフェストを記録し、探索成果物に埋め込み、Apply の際にデプロイします。

トリガー：ユーザーが「このコンセプトのヒーロー画像／イラストを生成して」「ムードボードのプレースホルダーを実際の画像に置き換えて」「空の状態のイラストを作成して」「アセット付きで適用して」といった内容を伝える場合、または現在のデザイン探索やデザインシステムに合ったビジュアルを求める場合です。

同梱のビジュアル参照スターターセット

すぐに画像を使って試せるよう、このスキルには assets/examples/visual-reference-directions/ に3つのビジュアル参考例が含まれています。ユーザーから同梱のスターターセットを使うよう依頼された場合は、画像を確認し、それぞれ対応する方向性の大まかな参考としてのみ使用してください。方向性は、エディトリアルな建築表現（editorial-cobalt-glass.png）、触感のある素材（tactile-amber-membrane.png）、または静かな自然素材（material-paper-glass.png）です。これらは出発点であり、ブランドの規範ではありません。新たに、製品に適したアセットを作成し、確認を得る前にユーザーのプロジェクトへアセットを追加しないでください。 ワークフロー：

1. まだ実施していない場合は、ステージ 0：ページタイプの識別を実行します。ページタイプによってアセットパックが決まります（references/VISUAL-ASSET-GENERATION.md を参照）。
2. プロダクトのコンテキスト、DESIGN.md、トークン、美的ガイド（探索時に作成したもの、または references/AESTHETIC-ANALYSIS.md）から StyleContext を組み立てます。
3. 役割に基づいたアイコン戦略を決定します：
   • 小さな UI クロームアイコンには、プロジェクトで固定されているアイコンライブラリ、または references/ICON-USAGE.md に従ったカスタム SVG を使用します。
   • マーケティング、ソーシャル、機能のアイコンには、表現力が高まる場合やユーザーから要望があった場合、生成した SVG／PNG／WebP のイラストファミリーを使用できます。
   • ユーザーによる上書き（library_only、custom_svg_only、generated_icons、raster_icons）が可能で、内容を記録します。
4. 各ビジュアルアセットについて、プロンプトを作成する前に表示サイズと背景モードを指定します。UI に合成する生成イラストアイコン／オブジェクトは、デフォルトで透明背景にします。また、ユーザーが明示的に上書きしない限り、64px 未満には画像生成を使用しません。
5. 線の表現、遠近法、素材、ライティング、背景のモード／複雑さ、構図のシステム、被写体の方針、安全領域、配置の意図を盛り込んだ Visual Family Spec v1 を作成します。
6. 画像ごとに Asset Placement Spec を作成し、各アセットに実際の UI 上の役割を持たせます。スロット、目的、サイズのルール、コピー／CTA との関係、安全領域、レスポンシブ時の動作を記載します。
7. 画像ごとに Asset Spec を作成します（役割、アスペクト比、目標表示サイズ、背景モード、構図、プリセット、スタイル参照）。
8. Prompt Compiler のルールに従ってプロンプトをコンパイルします。最初にヒーローまたはファミリー内で最も強いアンカーを生成し、続けてそのアンカーをスタイル参照として兄弟アセットを生成します。
9. デフォルトではホストの画像生成ツールを呼び出します。MiniMax は、ユーザーが明示的に選択した場合に限り静止画像に使用します。その場合は、生成前に references/MINIMAX-IMAGE-GENERATION.md を読み込みます。
10. 一貫性 QA と配置適合性チェックを実行します（再試行は最大 2 回）。失敗した場合は、references/MOOD-BOARD.md に従って CSS のプレースホルダーに切り替えます。
11. 探索用 HTML の隣に design-assets.manifest.json を作成します。ムードボード、コンタクトシート、配置プレビュー、コンセプトプレビューには <img> のパスを埋め込みます。
12. マニフェストバリデーターを実行します。ファイルの存在、寸法／アスペクト比、目標表示サイズ、背景モード、ファイルサイズ、代替テキスト／装飾要素のステータス、プレビュー／最終状態、役割／ページへの適合性、スタイルの系統、配置フィールド、アイコンの役割に関する制約を検証します。
13. Apply の前にレビュー用画面を生成します。バリエーション用のコンタクトシート、複数の役割にまたがる組み合わせ用のムードボードウォール、コピー／CTA／レイアウトへの適合性を確認する配置プレビューを作成します。
14. 探索中はプレビュー解像度を使用します。Apply（Capability 5）では最終解像度で再生成またはエクスポートし、確認／検証済みのアセットのみを public/design-assets/（またはフレームワークに相当する場所）にコピーします。
15. デザインシステムの出力と DESIGN.md を更新し、icon_system、illustrated_icon_system、ビジュアルファミリーのルール、レビュー用画面のパス、選択した組み合わせ、配置に関する注記、検証ステータス、マニフェストのパス、再生成に関する注記を記録します。
16. デフォルトのアセット範囲：イラスト、ラスター形式のヒーロー画像、マーケティング／ソーシャル向けの表現力豊かなイラストアイコンファミリー、およびページタイプが Consumer app の場合のアプリ内コンシューマー向けアセット（空状態、オンボーディング、バッジ）。

重要：ユーザーがページタイプのデフォルト設定を明示的に上書きしない限り、情報量の多い B 端末のワークベンチ画面には、フルブリードのヒーロー画像を生成しないでください。UI ナビゲーションアイコンは引き続き references/ICON-USAGE.md に従います（まずライブラリとカスタム SVG を使用）。

7. ローカルデザインコンテキスト（プロファイル＋ターゲット）

ユーザーは、ウェブサイトの URL やスクリーンショットから再利用可能なブランドのビジュアル言語を抽出してローカルに保存し、必要に応じてさまざまなメディアエージェント向けに適応したいと考えています。Design Context プロファイルを作成または更新し、ターゲットのルールを生成または再利用して、統合された引き継ぎパッケージを出力します。

トリガー：ユーザーが「このサイトのデザインをプロファイルとして保存して」「この URL／スクリーンショットからブランドコンテキストを抽出して」「vibe-to-ui context --profile vibe-to-ui --target web」「このブランド用の LinkedIn ルールを教えて」「このプロファイルから印刷用パンフレットのコンテキストを出して」「ローンチ動画用の Hyperframes コンテキスト」などと言った場合、または保存済みのブランドを別のプロジェクトやメディアで再利用したいと依頼した場合です。

コマンドの概要（このパッケージの Node CLI — 独自に mkdir を実行するより、プログラムによるライフサイクル管理を優先してください）：

vibe-to-ui context --list
vibe-to-ui context --profile <profile> --init
vibe-to-ui context --profile <profile> --target <medium>
vibe-to-ui context remote connect <git-url>
vibe-to-ui context remote status
vibe-to-ui context sync

<medium> は任意のケバブケースのメディア ID です。例（許可リストではありません）：web、social-cover、hyperframes、linkedin、print-brochure。

node <skill>/bin/vibe-to-ui.js ... または、パッケージの bin が利用可能な場合は npx vibe-to-ui ... として実行してください。ルートは常に ~/.vibe-to-ui です（環境変数による上書きはできません）。references/DESIGN-CONTEXT.md を参照してください。

ワークフロー：

1. ケバブケースの プロファイル ID（ブランド／製品／クライアント。メディアではありません）を決定します。vibe-to-ui context --profile <id> --init を優先してスケルトンを作成してください（共有シードのみで、まだ targets/ はありません）。
2. ブランドの抽出（URL／スクリーンショット／画像）は、現時点では引き続きエージェント主導です。初期化したプロファイルの brand.md／tokens.json／decisions.md／sources/ に書き込んでください。
3. --target <name> の場合：CLI を実行して targets/<name>.md を作成または再利用し、統合された引き継ぎパッケージを出力します。references/DESIGN-CONTEXT.md のガイドを使い、ブランドマスターからターゲットのスタブコンテンツを作成してください。ユーザー定義のメディアを拒否してはいけません。
4. チーム間／デバイス間で共有する場合は任意で、プライベート Git リポジトリに remote connect してから sync を実行します（tokens.json を検証し、コミット、rebase-pull、プッシュを行います。競合時は上書きせずに中止します）。remote status で ahead／behind を確認してください。
5. プロジェクト内で作業する場合は、プロジェクトに DESIGN.md があれば、それも読んでください。任意で、Iteration Context に design_context_profile: <profile> を記録できます。DESIGN.md をプロファイルで置き換えてはいけません。

必ず守ること：~/.vibe-to-ui/ 配下のユーザーデータは、スキルのライフサイクルの対象外です。スキルの更新や再インストールで、ユーザーデータを上書きしてはいけません。リモート同期で再利用するのはユーザー自身の Git 認証情報のみです。この MVP には OAuth、自動マージ、クラウドアカウントはありません。

8. デザインインスピレーションライブラリ

ユーザーは、プロダクトサイト（複数ページ）やスクリーンショットから、美的な事例、判断、応用可能なルールを集め、後からエージェントが検索・引用できるグローバルライブラリに蓄積したいと考えています。事例をブランドの規範として扱ったり、プロジェクトを自動で作成したりすることは望んでいません。

トリガー：ユーザーが「これをインスピレーションとして保存して」「インスピレーションライブラリに追加して」「この URL を分析してインスピレーションにして」「このプロダクトのビジュアルシステムを集めて」「vibe-to-ui inspiration add …」「このインスピレーションを自分のプロフィールにリンクして」「このインスピレーションシードを DESIGN.md に適用して」などと言う場合や、ブランドプロフィールとは別に、プロジェクトをまたいで参照できるアーカイブの保存を求める場合。

コマンド一覧：

vibe-to-ui inspiration add <url> [--product <id>] [--page <slug>]
vibe-to-ui inspiration add --image <path> [--product <id>] [--page <slug>]
vibe-to-ui inspiration import-captures <product>/<page> --from-captures <dir>
vibe-to-ui inspiration rebuild-preview <product>/<page>
vibe-to-ui inspiration rebuild-product <product>
vibe-to-ui inspiration list
vibe-to-ui inspiration show <product>[/<page>]
vibe-to-ui inspiration link <product> --profile <profile>
vibe-to-ui inspiration apply <product> --project <path>              # product seed (default)
vibe-to-ui inspiration apply <product> --page <slug> --project <path>
vibe-to-ui inspiration apply <product> --project <path> --confirm

URL のスクリーンショットはエージェントが担当します（Browser Use / Computer Use）。CLI はブラウザーを起動しません。

ワークフロー：

1. add <url> はプロダクトとページを特定し、メタデータを取得して pages/<page>/ を用意し（captureCoverage: awaiting-agent）、プロダクトのインデックスアーティファクトを更新します。関連する URL は同じ --product でまとめます。
2. 全スクロールキャプチャ（すべての URL ページで必須）：Browser Use / Computer Use で、そのページの captures/ に fullpage.jpg とページ末尾まで連続した frame-01…N を保存し、短いモーション記録を motion.md に書き込みます。その後 rebuild-preview <product>/<page> を実行します。ヒーロー部分だけのキャプチャを完全なものとして扱わないでください。
3. ページタイプを分類し、全スクロールのビジュアルポジショニング表を埋め、美的カテゴリー 6 項目中 4 項目以上を網羅し、observed / inferred / transferable / brand-specific のタグを付けます。annotations.json では、すべてのビューポートフレーム（frame-01…N）に 1～3 件の注記を付け（最大 3 件。fullpage はアンカーを省略可）、synthesis を記入します。ライブラリに追加するすべてのテキスト（分析、統合、フレーム注記、モーション、シード）は、ユーザーのプロンプトと同じ言語で記述します（デフォルトでソースページの言語に合わせる必要はありません）。サイトに該当するページがある場合は、代表的なページを 2～4 件集めてから rebuild-product <product> を実行し、ページ横断のデザイン DNA をまとめます。
4. link <product> はプロフィールの inspiration-refs.json エントリ（reference-only）を書き込みます。事例をプロフィールにコピーしたり、トークンを書き換えたりすることはありません。
5. apply <product> はまずプロダクトの design-seed.md のマージ内容を表示します（単一ページの場合は任意で --page を指定）。書き込みは --confirm を明示した後にのみ行います。

詳細：references/INSPIRATION-LIBRARY.md。

機能の組み合わせ

これらの機能は自然に組み合わせられます。ワークフローは探索 -> 選択 -> 適用というパターンに従います。エージェントが共同で検討するための単独プレビューを作成し、ユーザーが方向性を確認してから、デザインをプロジェクトに適用します。

ビジュアルの方向性（機能 2）と空間の方向性（機能 3）を組み合わせる

機能 2（デザイン探索）と機能 3（空間的な雰囲気の探索）は、曖昧な感覚、インスピレーション画像、音楽をどちらもトリガーとして受け付ける点で共通していますが、答える問いは異なります。

• 機能 2 が生み出すのはビジュアルコンセプトです。色、タイポグラフィ、マテリアル、モーションの個性を扱います。
• 機能 3 が生み出すのは空間コンセプトです。レイアウトの文法、密度、階層、リズム、セクション構成を扱います。

実際のページには両方が必要であり、連携して機能します。組み合わせる際のルールは次のとおりです。

• ユーザーが新しいページを作成する際は、既存のページをスタイル変更するだけでなく、両方を検討します。 レイアウトのない色（または色のないレイアウト）は、方向性が半分しか定まっていない状態です。
• 増やすのではなく、組み合わせます。 3つのビジュアルコンセプトと3つのレイアウトの方向性を、関連性のない9つの選択肢として提示してはいけません。少数の一貫性のあるコンセプトにまとめ、それぞれで1つのビジュアルの方向性と1つの空間的な方向性を組み合わせます（例：「コンセプトA＝ニュートラルで寒色系のパレット＋エディトリアルな非対称レイアウト」）。
• 両方を同じシグナルから導き出します。 同じキーワード、音楽、参考資料をビジュアルと空間の両方の表現に反映させることで、1つのコンセプトが、無関係な2つのレイヤーではなく、意図のある1つのアイデアとして伝わります。
• 最も曖昧な要素から順に進めます。 ユーザーが雰囲気を決めかねている場合は、まずビジュアルコンセプトを検討します。雰囲気はイメージできてもページの形が定まらない場合は、まず空間的な方向性を検討します。どちらの場合も、正式に決定する前に両者をすり合わせます。
• 両方をデザインシステムのドキュメントに記録します。 ビジュアルトークンはそれぞれのセクションに、選択したレイアウトは空間・レイアウトのDNAセクションに記録し、Capability 5で両方が一体となって適用されるようにします。
• リファレンスに基づく探索 -> 選択 -> 適用：ユーザーのプロダクト背景と具体的なリファレンスから始め、文脈に沿ったビジュアルの方向性を3つ導き出します。ユーザーが選択したら、デザインシステムとして形式化し、プロジェクトに適用します
• 探索 -> 選択 -> 適用：雰囲気を探り、コンセプトのプレビューとムードボードを3つ生成します。ユーザーが選択したら、デザインシステムとして形式化し、プロジェクトに適用します
• 探索 -> ムードボード -> 選択 -> 適用：雰囲気を探り、ページタイプを分類し、検証用のムードボードに落とし込みます。ユーザーが方向性を確認したら、デザインシステムを抽出してプロジェクトに適用します
• デザインの復元 -> プレビュー -> 適用：完成したデザイン案からデザインシステムを抽出し、ページタイプを分類して、単独で表示できるプレビューページを生成します。ユーザーが確認したら、プロジェクトに適用します
• ムードボード -> 抽出 -> 適用：リファレンスからムードボードを生成し、確認済みの方向性をデザインシステムとして形式化してプロジェクトに適用します
• 探索 -> ムードボード：デザイン探索中の中間チェックポイントとしてムードボードを生成し、ページタイプへの忠実さを損なうことなく、ユーザーが方向性を感じ取れるようにします
• 空間的な雰囲気 -> ムードボード -> 選択 -> 適用：UI以外のインスピレーションをSpatial DNAに変換し、ムードボードで感覚を具体化します。方向性を選んだら、形式化して適用します
• 構造のリファレンス + 雰囲気のリファレンス -> 適用：一方のリファレンスをページ構成に、もう一方を空間的な雰囲気に使用し、対象のページタイプを通じて両者を調和させます
• レイアウト + デザインシステム -> 適用：あるサイトのレイアウトを分析してページタイプを分類し、類型が適合する場合は、別のソースのデザインシステムを適用します
• レイアウト + ムードボード：あるリファレンスからレイアウトを抽出し、対象の類型に反しないよう、ムードボードのビジュアルの方向性を適用します
• コンシューマーアプリのUI/UX -> プレビュー -> 適用：アプリのプラットフォームとライフサイクル段階を分類し、アプリの体験の方向性を3つ探ります。ナビゲーション、主要画面、フロー、状態マトリクス、触覚的なモーションをプレビューし、トークンを形式化して、モバイルファーストのプロジェクトコンポーネントに適用します
• ソース -> Design Contextプロファイル -> 必要に応じてターゲットを生成 -> 複数媒体への引き継ぎ：URLやスクリーンショットから~/.vibe-to-ui/profiles/<profile>/に抽出します。初回のリクエスト時にtargets/<medium>.mdを生成します（web、social-cover、hyperframesなどの任意の媒体ID、またはlinkedin、print-brochureのようにユーザーが定義したIDを指定できます）。ブランド、トークン、決定事項、ターゲットを統合して利用側のエージェントに渡し、2回目以降の呼び出しでは既存のターゲットを再利用します
• Design Context + プロジェクトへの適用：有効なプロファイルを読み込んでブランドの忠実さを保ち、プロダクトとページのコンテキストにはプロジェクトのDESIGN.mdを使用してから、並行するトークンシステムを新たに作らずにApply（Capability 5）を実行します
• インスピレーションライブラリ -> プロファイルをリンク -> 必要に応じてDESIGN.mdに適用：inspirations/<product>/にプロダクトページ（全体のスクロール画像）を収集します。プレビューページとプロダクトの統合結果を作成し、必要に応じてlink <product>をreference-onlyとして実行します。確認後に限り、プロダクトのシードをプロジェクトのDESIGN.mdに統合します
• 完全なパイプライン：ページタイプを特定 -> 雰囲気とリファレンスを探索 -> 該当するものに応じて、ビジュアルの方向性、Spatial DNA、コンシューマーアプリのUI/UXニーズ、ビジュアルアセットの方向性を導き出す -> 比較可能な方向性を3つプレビュー -> 選択 -> デザインシステムを抽出 -> 必要に応じてDesign ContextプロファイルやInspiration Libraryの事例として保存 -> トークン、レイアウト、確認済みアセットをプロジェクトに適用

出力形式のガイドライン

すべてのデザインシステムの出力には、以下を含めてください。

• ページタイプの概要：主要なタイプ、副次的な修飾要素（該当する場合）、密度、確信度、根拠、デザイン上の影響
• コンシューマーアプリの概要（該当する場合）：プラットフォームの想定、ライフサイクル段階、主要なループ、ナビゲーションモデル、ジェスチャーモデル、状態に関するリスク、状態マトリックス
• ドキュメント用の、人が読みやすい Markdown の概要
• 単独で表示できるビジュアル成果物を標準で用意：ワークフロー中に自動生成する、自己完結型の HTML プレビューページ
• 少なくとも次のいずれかの形式による機械可読なトークン：
  • CSS カスタムプロパティ（:root { --color-primary: #xxx; }）
  • Tailwind CSS の設定（tailwind.config.js の theme 拡張）
  • JSON トークンファイル（フレームワークに依存しない用途向け）
• モーショントークン：ビジュアルトークンとあわせて、duration、easing、animation の定義を含めてください

Spatial Vibe の出力には、以下を含めてください。

• ページタイプの分類と UX 上の制約
• 構造の参考資料と雰囲気の参考資料
• ユーザーが各参考資料のどこを気に入っているか
• 応用できる要素と応用できない要素
• 動的に導出される Spatial DNA
• 構造の忠実度をそろえた、単独で表示できるレイアウト案のプレビューを3種類
• 各案について、ユーザーが読める簡易レイアウトスケッチまたはサムネイル、スケッチの凡例／コンテンツマップ、セクションの順序、主要なレイアウト上の判断、トレードオフ、レスポンシブ対応方針
• レンダリング結果を確認した際の所見と、行った修正の記録

アイコン使用のガイドライン

生成する UI コードでは、絵文字をビジュアル要素として使用しないでください。 小さな UI アイコンは、プロジェクトにアイコンライブラリがある場合、必ずそのライブラリに統一してください。適合する、またはページの美観に調和するライブラリアイコンがない場合は、デザインシステムのトークンを継承し、美観の本質に合致して、references/ICON-USAGE.md のカスタム SVG QA チェックリストに合格するカスタム SVG アイコンコンポーネントを作成してください。小さなアイコンを、小さな UI スクリーンショット、図、ダッシュボード、複数オブジェクトのシーンのようにしないでください。アイコンによって情報のスキャンや理解が促進されない場合は、タイポグラフィ、ラベル、余白、階層で意味を伝えてください。生成したラスターアイコンやイラストアイコンは、ユーザーが明示的に標準設定を上書きしない限り、マーケティング、機能紹介、空状態、オンボーディング、ソーシャル、ブランド関連の画面にのみ使用してください。DESIGN.md がある場合は、アイコンの方針を記録してください。

重要な注意事項

• まず探索し、その後に適用する：デザインの探索中に、ユーザーのプロジェクトファイルを変更してはいけません。コンセプトのプレビュー、ムードボード、デザインシステムのプレビューはすべて、独立した成果物として生成してください。ユーザーが（Capability 5 を通じて）方向性を明示的に確認した場合にのみ、プロジェクトに適用してください。
• ユーザーがデザインの方向性、抽出、または空間的な雰囲気の探索を求め、明示的にオプトアウトしていない場合は、対応する HTML のビジュアル成果物を同じ工程で自動的に作成してください。
• ユーザーが UI の参照と雰囲気の参照の両方を提示した場合は、一から再設計するよりも、**「まず参照に合わせ、その後に雰囲気を調整する」**ことを優先してください。
• パレット、スペーシングスケール、タイポグラフィスケール、またはモーションの表現を確定する前に、必ずページタイプを分類してください。
• 雰囲気を重視するページでは、プロダクトのコンテキストが明確に情報量の多い類型を示していない限り、デフォルトでモジュールを少なくし、情景を伝える画像を大きくし、情報密度を低くすることを優先してください。
• B 端末向けの情報量が多いページでは、状態を示す色を明確にし、テーブルやフォームの視認性を高め、スペーシングをコンパクトに保ち、動きを控えめにしてください。
• コードトークンを生成する前に、必ずユーザーが使用している CSS フレームワークまたは技術スタックを確認してください。
• 色を抽出する際は、16 進数値と意味的な名称（該当する場合は primary、surface、accent、success、warning、danger など）の両方を提示してください。
• タイポグラフィについては、絶対サイズだけでなく、フォントファミリーとスケール比の両方を記載してください。
• スペーシングは、一貫したスケール（例：4px を基本単位とする）で表現してください。
• モーションのトークンには、必ず prefers-reduced-motion のフォールバックを含めてください。アクセシビリティは譲れません。
• 探索中は、探索用暫定モーション（CSS ＋ 暫定 DNA ＋ シグネチャーモチーフ）を使用してください。ムードボードや初期コンセプトの雰囲気確認では、Motion Engine Router を読み込まないでください。
• モーションの実装コード（デザインシステムのプレビュー Step 7、確認済みコンセプトの製品化、または Capability 5 Apply）を書く際は、references/MOTION-ENGINE-ROUTER.md を読み込んでください。対象が web、React、Vue のいずれかを判定し、正しいスタックへのバインディングを備えた、最もシンプルなエンジン階層を使用してください。ネイティブ動画または生成動画を提案する場合は、マークアップを書く前に Video Intent Route を実行し、references/VIDEO-MOTION.md を読み込んでください。方向性を示すオープニングでは、最後のフレームを保持するワンショットの hero-take をデフォルトとし、loop は認定済みの環境音的なシームに限り使用できます。Router が L5 MiniMax Video を選択できるのは、自然な動き、複雑な変形、またはコードではうまく表現できない連続的な映画風の動きの場合のみです。MiniMax のみを使用し、他のプロバイダーで代用してはいけません。Motion DNA とシグネチャーモチーフに基づいてレシピのパラメーターを変更し、ライブラリのデフォルトを変更せずに使ってはいけません。エンジンを混在させたり、React 用パッケージを Vue に（またはその逆に）誤って接続したり、装飾的な効果を重ねたり、デモの美的表現をコピーしたりしてはいけません。
• ビジュアル分析に不確実性がある場合は、正直に伝えてください。信頼度の低い抽出にはその旨を明記し、ユーザーに確認を促してください。