ideate

アイデアの創出

ユーザーのアイデアに基づいて、デザインコンセプトを作成するタスクです。

$index に記載された共通のプロダクトデザインのルーティングガイダンスに従ってください。

重要な上書き指示

• 先にプラグインルーター $index を参照してから進めてください。
• $critical-overrides に従ってください。

ユーザーコンテキスト

作業を始める前に、$user-context を読み込み、ローカルのシェルにアクセスできる場合は、そのプリフライトスクリプトを実行してください。

提供された製品の URL、Figma ファイル、スクリーンショット、参考画像、コードベースのパス、Storybook、トークン、デザインシステム、ブランドアセット、コンポーネントの参照、ブラウザーの設定、共有先を Image Gen の生成に添付し、デザインブリーフに反映してください。

保存されている参考資料をすべて確認する必要はありません。現在のタスクに必要なものだけを確認してください。

ワークフロー

$get-context によって最低限必要なデザインブリーフが揃うまで、画像を生成しないでください。

画像を生成する前に、次の手順を実行してください。

1. ブリーフを理解します。

• 対象を特定します。コンポーネント、画面、機能／ワークフロー、または幅広いプロダクトアイデアのいずれかです。
• 想定ユーザー、プロダクトの対象面、目標を特定します。
• ユーザーが指定した必須要件を維持します。
• 最低限必要なデザインブリーフが揃っていない場合は、get-context を実行します。

2. コンテキストを解決します。

• 提供されたファイル、スクリーンショット、リンク、表示可能な参考資料を使用します。
• ローカルのワークスペースでは、近くにあるデザインドキュメントやその他のローカルなビジュアルコンテキストを探します。
• user-context、storybook/、.storybook/、design-system/、design-systems/、tokens/、components/、app/、生成されたプロトタイプのルートなど、デザインに関する情報がありそうなフォルダーを確認します。
• 既存のプロジェクトでは、生成する前に、既存のプロダクトのスクリーンショット、類似するフロー、Storybook のキャプチャ、デザイントークン、コンポーネントの参照を探します。既存アプリにアクセスできない場合は、作成中の画面に似たサンプル画面をユーザーが提供できるか尋ねます。デザイン言語とトークンを Image Gen のプロンプトに必ず追加してください。

3. 参考資料を直接確認します。

• 生成する前に、スクリーンショット、画像、Figma のフレーム、アプリの画面、その他のビジュアル参考資料を確認します。
• ファイル名だけから内容を推測しないでください。
• 名前が指定されたローカルパスまたは参考資料を表示できない場合は作業を停止し、パスの確認、ファイルのアップロード、ローカルアプリの起動、または正しいワークスペースの指定をユーザーに依頼します。

4. バリエーションの方向性を決めます。

• 有用なローカルのデザインコンテキストがあり、ユーザーが新しいスタイルを求めていない場合は、既存の方向性に沿ってください。
• 有用なデザインコンテキストがない場合、またはユーザーが幅広い探索を求めている場合は、コンセプトとビジュアルシステムの両方に変化をつけます。
• 特定のコンポーネントまたは既存の画面については、ブランドスタイルを変える前に、構造、インタラクション、階層、強調点にバリエーションをつけます。
• 幅広いプロダクトアイデアについては、明確に異なる3つのプロダクトの方向性を検討します。

5. Image Gen の前に、対象の寸法を選びます。

• ユーザーの依頼と提供されたビジュアル参考資料に最も合う寸法を選びます。
• モバイルアプリ：390 x 844。
• タブレットアプリ：834 x 1194。
• デスクトップアプリ、ダッシュボード、管理画面、または SaaS：1440 x 1024。
• ランディングページまたはマーケティングページ：幅 1440、スクロール可能。
• モーダル、パネル、ウィジェット、またはコンポーネント：コンテナの自然なサイズ。
• 提供されたスクリーンショット、Figma フレーム、モックアップ、または参考画像を基に続ける場合は、その寸法とアスペクト比に合わせます。
• 要素を詰め込みすぎないでください。現実的な余白と読みやすい文字を確保し、コンテンツが切れないよう、選択した寸法に収まるデザインにします。
• Image Gen のすべてのプロンプトに、選択した寸法を含めます。

6. アクセス上の問題を確認します。

• 認証、権限、ログイン期限切れ、スコープ不足、結果が不自然に少ないこと、ローカル状態を利用できないことなどが原因で、コネクター、参考資料、ファイルにアクセスできない場合は、作業を停止します。
• 問題を明確に伝え、アクセスを調査するか、その情報源なしで続行するかをユーザーに尋ねます。
• 名前が指定された参考資料を黙って無視して、画像を生成しないでください。

7. ユーザーが提供した画像やモックアップを、デザインブリーフとともに Image Gen の呼び出しに添付します。
8. 情報の優先順位、レイアウト戦略、インタラクションモデル、または製品の位置付けがそれぞれ異なる、独立した案を3つ生成してください。

必ず守るルール：

• 以下の Image Gen プロンプトを使用してください。
• 組み込みの Image Gen ツールを使用してください。
• ユーザーが数を変更しない限り、独立した画像をちょうど3枚生成してください。
• Image Gen の呼び出しはそれぞれ独立して開始してください。Promise.all を使って Image Gen の呼び出しをまとめたり、順序付きの配列に収集したり、リクエスト順に再生したりしないでください。
• 各案はそれぞれ独立した Image Gen の結果にしてください。1枚の画像に複数のアイデアを含めないでください。
• 生成前に、それぞれの方向性にわかりやすく特徴を示す名前を付けてください。ただし、option 1、option 2、option 3 とは呼ばず、Image Gen プロンプトに予定している番号ラベルを入れないでください。並行処理の結果は、リクエストとは異なる順序で返されることがあります。
• Image Gen の結果がスレッドに表示されてから、初めて案に番号を付けてください。唯一の確定した案の順序は、現在のスレッドに表示された生成画像の順序です。予定していたコンセプトの順序、元のリクエストの並び、プロンプトの送信順、Promise.all の結果順、バッチの順序、配列のインデックス、再試行の順序、または想定される完了順は無視してください。
• すべての結果が返されたら、表示順に従って各案の番号を結果に割り当ててください。最終的な選択メッセージでは、案の名前や説明を記載しないでください。
• 提供されたスクリーンショット、ファイル、アプリのキャプチャ、Figma の参照資料、ビジュアル素材がある場合は、ムードボードの参考資料として添付してください。
• 既存の製品スクリーンショット、類似するフロー、Storybook のキャプチャ、デザイントークン、コンポーネントの参照資料がある場合は、デザインの基準資料として添付してください。
• モックデータに日付や時刻に関する情報が含まれている場合は、正確な現在の日付を確認し、すべての Image Gen プロンプトに含めてください。その日付を基準に表示日付を決め、ユーザーまたは元のデザインで指定されている日付は維持してください。
• スクリーンショット、画像、またはビジュアルファイルがある場合は、実際の画像を Image Gen の呼び出しに添付してください。テキストで説明するだけにしないでください。
• Image Gen の呼び出しに実際に画像または読み取り可能なローカル画像パスが渡されていない場合は、ビジュアル参照を添付したと主張しないでください。
• 画像を添付できない場合は、そのことを明確に伝え、テキストのみの方向性で続行するか確認してください。
• ブリーフの必須条件をすべての画像で維持してください。
• 案を生成した後は、実装作業を始めずにユーザーの選択を待ってください。
• 後からユーザーが案の N を選択した場合は、元の予定順ではなく、直近のアイデア出しで表示された生成画像のうちN番目の結果に対応付けてください。表示された正確な結果を特定できない場合は、推測で実装せず、ユーザーにコンセプトの名前を伝えるか、画像を再添付して選択するよう依頼してください。
• 選択された案は、$image-to-code のビジュアルターゲットです。

フィードバックループ

案を見た後にユーザーからフィードバックがあった場合は、そのフィードバックを反映して案を再生成してください。

ユーザーが案を選択し、フィードバックも伝えた場合は、実装に進む前に、そのフィードバックを反映した案を再生成してください。

複数の案の気に入った部分を組み合わせたいという場合は、それらの選択を組み合わせた新しい Image Gen デザインを作成し、実装前に提示してください。

Image Gen プロンプト

現在のデザインブリーフに合わせてこのプロンプトを調整し、利用可能な画像参照を添付してから、Image Gen に送信してください。

Create realistic, production-quality UI designs with clear hierarchy, strong typography, intentional imagery, and purposeful spacing.

Design a focused primary screen, not a feature inventory. The product may support many workflows, but this frame should show the hero use case, one clear primary action, and only one or two supporting actions or content areas. Do not add cards, panels, tabs, badges, metrics, filters, or navigation items merely to advertise every feature. Let the rest of the product exist off-screen. Prefer strong hierarchy and generous whitespace; if the screen feels crammed, remove UI.

### Target Dimensions

Pick the dimensions that best match the user's request and any provided visual reference.

Default to a desktop web-app frame unless the user or reference clearly calls for mobile, tablet, or another format.

 - Mobile app: `390 x 844`
 - Tablet app: `834 x 1194`
 - Desktop app, dashboard, admin, or SaaS: `1440 x 1024`
 - Landing or marketing page: `1440` wide and scrollable
 - Modal, panel, widget, or component: natural container size
 - Provided screenshot, Figma frame, mockup, or reference image: match its dimensions and aspect ratio when the user wants to continue from that visual

Use a natural viewport ratio for the intended surface. Never stretch, squash, or warp the generated screen, imagery, typography, or UI elements to fill the canvas. If the composition does not fit naturally, recompose or simplify the layout instead.

Avoid crowding. Make the design fit the chosen dimensions cleanly, with realistic spacing, readable type, and no clipped content.

### Layout

When deciding how to lay elements out on the page, this should be your priority order for tools to differentiate sections:

1. Use spacing, grouping, alignment, typography, and hierarchy on the same product surface.
2. Use simple dividers or row separators.
3. Use a subtle surface tint only when the base surface is not enough.
4. Use borders only when separation still is not clear.
5. Use shadows/elevation last, and sparingly.

Don'ts:
 - Do not default to a centered "app card" (the whole UI is in a card on the page) on top of a contrasting page background. Use the base page surface first unless the source product or user explicitly asks for a contained app panel.
 - Do not put cards inside cards. Do not make every major section a card. Do not make each list item its own card unless each item is truly a standalone object. A normal list should usually read as one grouped surface with lightweight row separation.
 - Do not make up extraneous features. Add only the things essential to accomplish what the prototype's goal is. Don't make up more features just to fill out a UI.

### Typography

 - Anchor UI typography to readable product sizes. Body text should usually sit between 14px and 16px, with the rest of the type scale built around that baseline.
 - Keep long-form text to a comfortable line length, generally no more than 65 characters per line.
 - Use no more than 2 fonts in a UI. You can use any font available in the project, or fonts provided free on Google Fonts. Pick the font that is best for the goal of the product and that matches with its intended look and feel.

### Presentation

 - Do not add browser or device chrome around the mockup.
 - Do not put multiple ideas into a single image generation.
 - Vary each idea as much as possible while adhering to the constraints given entirely.

### Data Freshness

When the design includes dates or time-sensitive mock data, use the supplied current date as the anchor. Weekly views must show the real containing week with correct weekday/date pairs. Feeds, charts, notifications, and recent activity must use plausible chronological dates relative to today. Mark today when useful. Preserve dates required by the brief or source design.

出力

最終メッセージを送信してユーザーに選択を求める前に、すべての Image Gen 呼び出しが返るまで待ってください。

リクエストされた生成済み画像がすべて、メインチャットにちょうど 1 回ずつ表示されるまで、最終的な選択メッセージを送信しないでください。

表示されている Image Gen の出力がリクエスト数より少ない場合は、不足している生成を再試行してください。選択メッセージを送信しないでください。

返された Image Gen の出力に、会話コンテキスト内で表示される順に番号を付けてください:

• 最初の Image Gen 出力 = オプション 1
• 2 番目の Image Gen 出力 = オプション 2
• 3 番目の Image Gen 出力 = オプション 3

計画されたコンセプトの順序、元のリクエストチェーン、リクエスト順、Promise.all の結果順、バッチ順、配列インデックス、再試行順、ツール送信順は無視してください。

オプションに名前を付けたり説明したりしないでください。デフォルトの 3 枚の画像の場合は、次のみを送信してください:

Which option should I build: 1, 2, or 3? Or tell me what you'd like to refine or personalize first.

ユーザーが別の枚数をリクエストした場合にのみ、数字を調整してください。

ユーザーが番号を選択した場合は、$image-to-code にルーティングする前に、選択されたオプションを確認してください。例: Building option 2! マッピングが明確な場合は、確認を求めないでください。

完了とは、リクエストされた数の独立した画像が生成され、ユーザーが 1 つを選択するよう求められた状態を意味します。