Umby Discover: 精准简报与创意方向
适用基本规则。 在做出任何更改前，请先阅读
../umby-beast-code/references/standing-rules.md：审批关卡、未经明确许可不得部署或合并、特性分支需附带预览、受保护代码、每个 URL 必须保留或重定向、仅使用真实证明、以及工作日志。
通用的提示词会迫使 AI 猜测，而 LLM 的猜测结果不过是互联网上的统计平均值。你的任务是在编写任何组件代码之前，锁定一个具体的、有明确观点的、在品类中领先的产品与视觉身份，同时避免让用户经历繁琐的 20 题问卷调查。
第一步：分离可观察事实与缺失意图
- 首先检查工作区文件（
package.json、现有的 CSS 令牌、品牌资产、README.md、现有路由）。永远不要问仓库里已有答案的问题。 - 根据“非拼凑简报五支柱”框架评估用户的请求：
- 支柱一 — 任务与首要行动： 谁来到了这里？他们带着什么疑虑？我们希望他们完成的唯一行动是什么？
- 支柱二 — 审美原型与张力： 这在视觉上属于什么类型？（请阅读
references/aesthetic-archetypes.md了解 12 种非 AI 原型。） - 支柱三 — 证明与内容现实： 我们是否有真实的产品数据、指标、摄影作品或实时的交互机制？还是应该构建一个诚实的交互模拟器，而不是使用虚假的“10,000+ 客户”这样的填充内容？
- 支柱四 — 表面范围与技术栈： 哪些页面/流程属于第一阶段？适用于哪些技术栈约束（Astro 静态速度 vs. Next.js 交互应用 vs. Shopify 无头）？
- 支柱五 — 既有项目约束（仅限更新项目）： 哪些 URL、Logo、品牌十六进制色、结算或认证合约是神圣不可侵犯的？
第二步：运行 4-5 个问题的摄入门
如果上述支柱中有 2 个或以上确实缺失（且用户未要求立即自主执行），则在编写 UI 代码前暂停，并从 references/question-bank.md 中挑选 3 到 5 个尖锐问题进行提问。
提出优秀发现问题的规则
- 在可用时使用宿主问题 UI： 如果你所处的环境提供了结构化的多选问题工具（例如
ask_question），请使用它，每个问题提供 3-4 个具体、对比鲜明的选项，并将你推荐的选项放在最前面，加上(推荐)前缀。否则，提供一个干净、带编号的纯文本列表。 - 提供具体的对比选项，而非开放式作业： 永远不要问“你喜欢什么颜色和字体？”。相反，提供尖锐的方向性配对，例如：“(推荐) 精确暗色巨石 (Linear / Raycast 档次：曜石黑
#0b0c0e、锐利的发丝级边框、单一电光色强调、交互式产品展示台)” vs. “编辑式高亮 (Stripe Press / Mercury 档次：暖白色#faf9f6、编辑式衬线展示字体 + 清晰的 Grotesk 正文字体、充裕的日光感间距)”。 - 最多 5 个问题： 一轮尖锐的问题令人振奋；三轮吹毛求疵则感觉像是功能故障。
第三步：锁定创意与功能契约
一旦用户回答（或者在获得明确自主授权后立即使用你最佳匹配的原型），编写一份紧凑的设计与产品契约（可以作为 12-15 行的内联内容，如果涉及多路由项目，则保存到 .umby/DESIGN_BRIEF.md）：
- 受众与疑虑： 一句话，描述谁访问了页面以及页面必须在 5 秒内克服的确切怀疑。
- 首要视图操作： 确切的一个主要 CTA 动词短语（例如：
"启动交互式沙盒"、"加入 250g 装 · ¥168"）。 - 所选原型与 3 个工艺基准： 来自
references/aesthetic-archetypes.md的命名原型 + 3 个以其品质标杆（绝不复制 IP/资产）作为构建锚点的真实世界产品。 - 字体搭配与尺度： 展示字体族 + 正文字体族 + 等宽字体族，包含明确的字重和字距规则。
- OKLCH 色彩锚点： 基础表面明度/色调、主要墨色、发丝级边框透明度、以及一个高确信度的强调色。
- 区块节奏序列： 有序列表，列出 5-8 个页面节拍，要求相邻的两个区块不能使用相同的网格几何结构。
- 反目标（明确排除项）： 本项目中禁止的 3 个特定陈词滥调（例如：“没有紫蓝 SaaS 发光效果、没有三列 Lucide 图标功能行、没有未经验证的客户头像”）。
将这份锁定的契约直接传递给 ../umby-architect/SKILL.md 和 ../umby-craft/SKILL.md。