ideate

Ideate

你的任务是为用户的想法生成设计概念。

遵循 $index 中的共享产品设计路由指南。

关键覆盖规则

• 继续之前，请先参阅插件路由器 $index。
• 遵循 $critical-overrides。

用户上下文

开始之前，加载 $user-context，并在本地 shell 可用时运行其预检脚本。

将提供的产品 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. 确定变化模式。

• 如果存在有用的本地设计上下文，且用户没有要求采用新风格，则沿用现有方向。
• 如果不存在有用的设计上下文，或用户要求进行广泛探索，则同时变化概念和视觉系统。
• 对于特定组件或现有界面，优先变化结构、交互、层级和重点，再考虑变化品牌风格。
• 对于宽泛的产品创意，探索三个差异明显的产品方向。

5. 在使用 Image Gen 之前选择目标尺寸。

• 选择最符合用户需求和任何已提供视觉参考的尺寸。
• 移动应用：390 x 844。
• 平板应用：834 x 1194。
• 桌面应用、仪表板、管理后台或 SaaS：1440 x 1024。
• 落地页或营销页面：宽度为 1440，并支持滚动。
• 模态框、面板、小组件或组件：采用容器的自然尺寸。
• 如果用户希望以提供的截图、Figma 画框、模型图或参考图像为基础继续设计，则保持其尺寸和宽高比。
• 避免内容拥挤。确保设计适配所选尺寸，间距合理、字体清晰且内容不被裁切。
• 在每条 Image Gen 提示词中注明所选尺寸。

6. 检查访问障碍。

• 如果因身份验证、权限、登录过期、缺少范围、结果少得异常或本地状态不可用，导致无法访问某个连接器、参考资料或文件，请停止。
• 明确说明访问障碍，并询问用户是要排查访问问题，还是在不使用该来源的情况下继续。
• 不要在忽略用户指定的参考资料后，仍然生成图像。

7. 调用 Image Gen 时，将用户提供的图像和模型图与设计简报一并附上。
8. 生成 3 个相互独立的方案，每个方案的信息层级、布局策略、交互模式或产品定位都应各不相同。

必须遵守以下规则：

• 使用下方的图像生成提示词。
• 使用内置的图像生成工具。
• 除非用户另行指定数量，否则恰好生成 3 张独立图像。
• 分别独立发起每次图像生成调用。不要使用 Promise.all 批量发起调用，不要将结果收集到有序数组中，也不要按请求顺序重放结果。
• 每个方案都必须对应一个独立的图像生成结果。不要在一张图中放入多个构想。
• 生成前，为每个方向取一个有辨识度的描述性名称，但不要称其为 option 1、option 2 或 option 3，也不要在图像生成提示词中添加预设的数字标签。并行生成的结果可能与请求顺序不同。
• 只有在图像生成结果出现在对话中后，才能为方案编号。唯一有效的方案顺序，是这些生成图像结果在当前对话中的显示顺序。忽略预设的构想顺序、原始请求链、提示词提交顺序、Promise.all 结果顺序、批次顺序、数组索引、重试顺序以及假定的完成顺序。
• 所有结果返回后，按显示顺序为每个可见方案分配对应编号。最终的选择消息中不要为方案命名或描述。
• 如有用户提供的截图、文件、应用截屏、Figma 参考和视觉素材，请将其作为情绪板灵感附上。
• 如有现有产品截图、类似流程、Storybook 截图、设计令牌和组件参考，请将其作为依据素材附上。
• 如果模拟数据包含日期或时效性信息，请确定当前的确切日期，并将其写入每条图像生成提示词。根据该日期确定可见日期；保留用户或源设计要求的日期。
• 如果有截图、图像或视觉文件，请将实际图像附加到图像生成调用中。不要只用文字描述代替。
• 如果无法附加图像，请明确说明，并询问用户是否愿意继续仅使用文字描述。
• 每张图都必须遵循设计需求中的硬性约束。
• 生成方案后，暂停等待用户选择，再开始任何构建工作。
• 用户之后选择方案 N 时，应将其对应到最近一组构想中第 N 个显示的生成图像结果，而不是原先预设的构想顺序。如果无法准确确认对应结果，不要猜测并开始构建；请让用户说出构想名称，或重新附加／选择图像。
• 所选方案将作为 $image-to-code 的视觉目标。

反馈循环

如果用户在看到方案后给出反馈，请根据反馈生成修改后的方案。

如果用户选择方案并给出反馈，请先根据反馈生成修改后的方案，再开始构建。

如果用户喜欢多个方案中的不同部分，请将这些选择融合为新的图像生成设计，并在开始构建前展示该设计。

图像生成提示词

根据当前设计需求调整此提示词，附上所有可用的图像参考，然后发送给图像生成工具：

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 调用都已返回后，再发送询问用户选择的最终消息。

只有当所有请求生成的图像都恰好在主聊天中可见一次时，才能发送最终选择消息。

如果可见的 Image Gen 输出少于请求数量，请重新生成缺失的图像。不要发送选择消息。

按照图像在对话上下文中出现的顺序为返回的 Image Gen 输出编号：

• 第一个 Image Gen 输出 = 选项 1
• 第二个 Image Gen 输出 = 选项 2
• 第三个 Image Gen 输出 = 选项 3

忽略计划中的概念顺序、原始请求链、请求顺序、Promise.all 结果顺序、批次顺序、数组索引、重试顺序和工具提交顺序。

不要命名或描述这些选项。默认生成三张图像时，只发送：

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

只有当用户要求的数量不同时，才调整数字。

如果用户选择了一个数字，在路由到 $image-to-code 之前，先确认所选选项，例如：正在构建选项 2！ 映射明确时，不要询问确认。

完成的标准是：已生成所请求数量的独立图像，并已询问用户选择其中一张。