Umby Discover：精準簡報與創意方向
基本規則適用。 在進行任何更改之前，請閱讀
../umby-beast-code/references/standing-rules.md：審批關卡、未經明確許可不得部署或合併、功能分支附帶預覽、受保護的程式碼、保留或重新導向每個 URL、僅限真實證據，以及工作日誌。
通用的提示詞會迫使 AI 猜測，而 LLM 的猜測只是網際網路的統計平均值。你的任務是在撰寫任何元件程式碼之前，鎖定一個具體、有主見、且能引領類別的產品與視覺識別——同時不讓使用者經歷繁瑣的 20 題問卷調查。
步驟 1：區分可觀察的事實與缺失的意圖
- 首先檢查工作區檔案（
package.json、現有的 CSS 代幣、品牌資產、README.md、現有路由）。絕不詢問儲存庫已回答過的問題。 - 根據非通用簡報五大支柱審核使用者的請求：
- 支柱 1 — 工作與主要行動： 誰會來到這裡，他們帶有什麼懷疑，以及我們希望他們完成的唯一行動是什麼？
- 支柱 2 — 美學原型與張力： 這在視覺上屬於哪個範疇？（請參閱
references/aesthetic-archetypes.md以了解 12 種非 AI 原型。） - 支柱 3 — 實證與內容真實性： 我們是否有真實的產品資料、指標、攝影或即時互動機制——還是應該建立一個誠實的互動模擬，而不是使用虛假的
「10,000+ 客戶」填充內容？ - 支柱 4 — 表面範圍與技術棧： 哪些頁面/流程屬於第一階段，以及有哪些技術棧限制（Astro 靜態速度 vs. Next.js 互動應用 vs. Shopify 無頭架構）？
- 支柱 5 — 既有項目限制（僅限更新）： 哪些 URL、Logo、品牌色碼或結帳/驗證合約是神聖不可變更的？
步驟 2：執行 4-5 題攝入門
如果上述支柱中有 2 個或以上確實缺失（且使用者未要求立即自動執行），請在撰寫 UI 程式碼之前暫停，並從 references/question-bank.md 中選出 3 到 5 個精準問題 提出。
提出優秀探索問題的規則
- 盡可能使用主機問題 UI： 如果你的環境提供了結構化的選擇題工具（例如
ask_question），請使用它，每個問題提供 3-4 個具體、對比的選項，並將你推薦的選項放在第一個，並加上(推薦)前綴。否則，提供一個乾淨、編號的純文字清單。 - 提供具體對比，而非開放式作業： 絕對不要問 「你喜歡什麼顏色和字型？」 相反地，提供明確的方向配對：例如，「(推薦) 精準暗色單體（Linear / Raycast 等級：黑曜石
#0b0c0e、清晰髮絲線邊框、單一電光強調色、互動產品舞台）」 vs. 「編輯高亮風格（Stripe Press / Mercury 等級：暖色雪花石#faf9f6、編輯風格襯線顯示字體搭配乾淨無襯線內文字體、充裕的日光間距）」。 - 最多 5 個問題： 一輪尖銳的問題令人振奮；三輪吹毛求疵則會讓人感覺系統故障。
步驟 3：鎖定創意與功能合約
一旦使用者回答（或者如果在明確的自動授權下執行，則立即使用你最符合的原型配對），寫下簡潔的設計與產品合約（以 12-15 行內嵌形式，或對於多路由專案儲存至 .umby/DESIGN_BRIEF.md）：
- 目標受眾與懷疑點： 一句話說明誰會造訪，以及頁面必須在 5 秒內克服的確切疑慮。
- 主要視區行動： 剛好一個主要 CTA 動詞片語（例如，
「開始互動沙盒」、「加入 250g 袋 · $24」）。 - 選擇的原型與 3 個工藝基準： 來自
references/aesthetic-archetypes.md的命名原型 + 3 個真實世界產品，其品質標竿（絕非複製的 IP/資產）將作為建置的錨點。 - 字體配對與縮放： 顯示字體家族 + 內文字體家族 + 等寬字體家族，並附上明確的字重與字距規則。
- OKLCH 色調錨點： 基礎表面亮度/色調、主要墨色、髮絲線透明度，以及單一高說服力的強調色。
- 區塊節奏序列： 5-8 個頁面節拍的有序列表，其中相鄰的兩個區塊不能使用相同的網格幾何形狀。
- 反目標（明確排除項目）： 為此專案禁止的 3 個特定陳腔濫調（例如，「沒有紫藍色 SaaS 光效、沒有三列的 Lucide 圖示功能行、沒有未經驗證的客戶頭像」）。
將此鎖定的合約直接傳遞給 ../umby-architect/SKILL.md 和 ../umby-craft/SKILL.md。