指令用途
/prototype 用來建立拋棄式原型回答設計問題。它是依設計問題分支運作的：
- 狀態/邏輯的健全性檢查 —— 產生單一獨立可分享的 HTML 檔（純 HTML/CSS/JS，無 build、無 server），非開發者也能雙擊開啟，用自己的領域語言驅動：標示清楚的狀態面板、隨時可用的自由探索按鈕，以及一組分頁的引導式 walkthrough，每個都是一個情境，底下列出要按的按鈕順序。
- UI 探索 —— 從同一條路由切換多個截然不同的 UI 變體，看不同設計方向各自如何表現。
可抽離的純邏輯模組仍可整併進真實程式碼；HTML 外殼才是拋棄式的部分。
「拋棄」不再等於「刪除」。 一旦原型回答了它的問題之後，它會被捕獲為可執行的證據，放在 prototype/<name> 的拋棄式分支上（離開 main），並在實作 issue 上留下脈絡指標。這樣 main 分支只保留已驗證的決策，而探索痕跡仍可被找到。最終的答案（裁決 + 問題）仍會被持久地記錄在 issue/ADR/commit 中。
運作流程
- 釐清設計問題：確認要回答的問題是什麼（狀態/邏輯健全性，還是 UI 探索）。
- 選擇分支：
- 狀態/邏輯 → 單一 HTML 檔，含狀態面板、自由探索按鈕、分頁引導式 walkthrough。
- UI 探索 → 多個可從同一條路由切換的 UI 變體。
- 建立原型：把邏輯抽成可獨立測試的模組，外層為可拋棄的 HTML 外殼。
- 設定 walkthrough：為每個情境撰寫按鈕順序，讓非開發者也能照著走。
- 驗證與裁決：互動後記錄裁決（問題 + 答案）。
- 保存證據：在
prototype/<name>拋棄式分支上保存可執行原型，並在實作 issue 上留下脈絡指標。 - 持久記錄：把裁決寫進 issue / ADR / commit。
實戰對話範例
範例一：狀態機健全性檢查
- You:
我想確認購物車的折扣疊加邏輯走得對，各種優惠券組合會怎樣。
- AI:
這是個狀態/邏輯健全性檢查。我會建立一個單一 HTML 檔：
- 標示清楚的狀態面板（購物車內容、已套用折扣、總價）
- 自由探索按鈕（加商品、套優惠券、移除、結帳）
- 分頁的引導式 walkthrough：「只套滿額折扣」、「滿額 + 會員」、「疊三代券」等情境
我把折扣邏輯抽成獨立模組，之後可以直接整併進真實程式碼。原型放
prototype/cart-discount分支，實作 issue 上留指標。
範例二：UI 方向探索
- You:
我不確定儀表板該用側欄還是頂部導覽，想看看各自表現。
- AI:
這是 UI 探索。我會從同一條路由提供可切換的多個 UI 變體：
- 變體 A：側欄導覽
- 變體 B：頂部導覽
- 變體 C：混合式（頂部分類 + 側欄細項）
你可以逐一切換比較，決定哪個方向再往下做。
原型的兩個核心觀念
一、Demo 是單一可分享 HTML 檔
純 HTML/CSS/JS，沒有 build 步驟、沒有 server。非開發者雙擊即可開啟，並用自己的領域語言驅動：標示的狀態面板、隨時可用的自由探索按鈕，以及分頁的引導式 walkthrough。
二、原型是一手證據
拋棄不代表刪除。原型被捕獲為 prototype/<name> 拋棄式分支上的可執行證據（離開 main），實作 issue 上留下脈絡指標。裁決（問題 + 答案）則持久記錄在 issue / ADR / commit 中。
何時應該使用
- 設計問題需要互動才能回答：光用說的不夠，要實際跑跑看。
- 想讓非開發者親自操作驗證：單一 HTML 檔他們能自己開。
- 比較多個截然不同的 UI 方向：不確定哪個方向時。
何時不應該使用
- 能用測試回答的問題：寫測試更快、更可靠。
- 已經明確知道要做什麼：直接實作，不需要原型。
- 只是要看現有程式碼行為：用
/diagnosing-bugs的反饋迴圈。
與其他技能的關係
/prototype 是一個隨時可用的獨立技能。它的鄰居是 /diagnosing-bugs（兩者都建立反饋迴圈，但 prototype 為前瞻設計，diagnosing-bugs 為回溯除錯）。不確定該用哪個 skill 時，用 /ask-matt 來路由。