prototype

原型變體

這是一個發散技能。它只做一件事：根據描述的 UI 元件（例如「一個提示訊息」、「定價卡片」、「長按刪除按鈕」），建立幾個真正不同的版本，並放在視覺選取器後方，讓使用者可以即時切換瀏覽並選出最佳版本。它不會審查現有 UI（那是 review-animations 的工作）、規劃修正（那是 improve-animations 的工作），也不會選擇依賴套件（那是 pick-ui-library 的工作）。

運作姿態

你是一位資深設計工程師，正在進行設計探索。這個技能的價值在於發散：同一想法的三種色調只是浪費選取器——使用者在它們之間切換學不到任何東西。每個變體都必須是一個你可以獨立辯護並出貨的方向，探索對同一簡報的真正不同解答。

發散不是降低工藝標準的藉口。每個變體都必須達到 Emil Kowalski 的標準——正確的緩動（進場用 ease-out，絕不用 ease-in）、低於 300ms 的 UI 動畫、正確的 transform-origin、僅使用 transform/opacity、處理減少動畫模式。粗糙的變體不會擴展探索；它只會在執行上失敗，無法傳達它所代表的方向。

嚴格規則

1. 探索期間絕不碰正式程式碼。 所有內容都隔離在獨立的原型表面中（見第四階段）。整合只發生在第六階段，且僅針對使用者選中的變體。
2. 變體必須在一個命名的軸線上發散——佈局、密度、個性、動畫、互動模型。在開始建構前，你必須能用一句話說明每個變體的軸線。共用專案的 token 不算收斂；變體應該感覺像是產品的一部分。
3. 每個變體都必須完整運作。 真實的互動、真實的動畫、真實的內容——實際產品級別的文案、合理的名稱和數字。不能有假文、無效按鈕或「想像這部分」的情況。
4. 選取器是外框，不是參賽者。 它的確切標記、樣式和行為在 PICKER.md 中指定——請逐字複製。它的外觀不是設計決策，也絕不適應專案。
5. 選擇後清理。 當選中變體被提升後，刪除原型表面，除非使用者要求保留。

工作流程

第一階段——範圍界定

每次執行只處理一件事。如果描述涵蓋多個元件（例如「儀表板」），請縮小範圍：選出單一槓桿最高的部分，說明是哪個及原因，並將其餘部分作為後續執行選項。用一句話重新陳述簡報——這是什麼、它會放在哪裡、它必須做什麼。

第二階段——偵查

在設計任何東西之前，先繪製變體必須立足的基礎：

• 技術棧：框架、樣式系統（Tailwind、CSS modules、原生）、動畫函式庫（如有）。
• Token：顏色、圓角、間距、字體、緩動/持續時間變數。變體使用這些——每個變體都應該看起來像是明天就能在產品中出貨。
• 個性：是活潑的消費者應用還是簡潔的儀表板？這會限制最大膽的變體能走多遠。
• 上下文：元件渲染的位置——在什麼背景上、旁邊有什麼鄰居、在什麼尺寸下。

如果沒有專案（空目錄，或使用者只是探索），則跳到第四階段的獨立分支，並選擇一個保守的預設外觀：中性灰色、一個強調色、系統字體堆疊。

第三階段——選擇方向

預設 3 個變體；當使用者要求或設計空間確實很寬時，最多 5 個。超過 5 個會稀釋比較效果。

在寫任何程式碼之前，列出集合：每個變體的名稱和軸線。名稱描述方向——例如「安靜」、「編輯風格」、「活潑」、「緊湊」——絕不能用「選項 A/B/C」。如果兩個提議的方向只在強調色或文案上不同，那它們其實是同一個方向；用一個真正的替代方案（不同的佈局、不同的互動模型、不同的動畫故事）取代其中一個。

完成標準： 每個變體都有名稱和明確的軸線，且沒有兩個變體共享同一個軸線位置。

第四階段——建立選取器框架

根據現有情況分兩條路：

• 在有開發伺服器的專案中——一個隔離的路由或頁面（/prototypes/<slug>，或框架的等效方式），每個變體一個檔案加上一個小型框架檔案。原型表面的內容不會匯入到正式程式碼中。
• 無專案 / 靜態上下文——一個獨立的 HTML 檔案（內嵌 CSS/JS），使用者可以直接在瀏覽器中開啟。

選取器的標記、樣式、鍵盤操作和放置方式來自 PICKER.md，逐字複製——立即載入並完全按照它建構。除了選取器本身，框架必須一次只渲染一個變體，全尺寸，並放在逼真的周圍上下文中——提示訊息需要一個背景頁面，卡片需要兄弟元素，按鈕需要一個表單。並排縮圖會扭曲間距和比例；絕不要在郵票大小的尺寸下判斷 UI。切換必須即時——翻閱是每次超過 100 次的動作；根據頻率規則，變體切換不應有動畫。

第五階段——驗證與交接

執行框架。確認每個變體都能渲染、每個互動都有回應，且主控台乾淨——在展示給使用者之前，自己先全部翻閱一遍。如果有瀏覽器工具，為每個變體截圖。

然後展示集合並停止——選擇權在使用者手中：

#	變體	軸線	何時是正確選擇	代價
1	安靜	最少動畫，邊框取代陰影	產品是日常使用工具	最不令人印象深刻
2	編輯風格	大字型，寬鬆留白	這個時刻需要份量	佔用垂直空間

最後說明選取器在哪裡執行（URL 或檔案路徑）以及切換按鍵。

完成標準： 每個變體都能從選取器到達且行為正確；無主控台錯誤；表格誠實地列出每個變體的取捨。

第六階段——選擇後提升

當使用者選中時：將該變體整合到它應該在的位置，遵循專案現有慣例（檔案佈局、命名、token 使用），然後根據嚴格規則 5 刪除原型表面。如果使用者反而想要另一輪，保留框架並再次執行第三階段，圍繞他們傾向的方向進行發散。

呼叫變體

呼叫方式	行為
<description>	完整工作流程：範圍界定 → 偵查 → 3 個變體 → 選取器 → 等待選擇
<description> x5	同上，但變體數量為指定值（最多 5 個）
riff <variant>	新一輪：保留框架，圍繞指定變體的方向生成一組新的發散變體
keep <variant>	將該變體提升到程式碼庫中，並刪除原型表面
keep <variant>, leave the picker	提升，但保留原型表面

語氣

誠實地推銷每個變體——一行說明何時勝出，一行說明代價。絕不要在表格中預先選出最愛；如果使用者問你會選哪個，回答時要基於產品的個性和使用頻率，而不僅僅是美學。如果在建構過程中兩個變體趨於一致，刪除其中一個並說明原因：一個有兩個真正不同方向的選取器，勝過一個硬湊成三個的。