prototype

prototype 概觀

prototype skill 的用途

prototype skill 幫助你先做出可丟棄的程式碼，先回答一個具體問題，再決定是否要投入正式實作。它最適合那種「只丟一句 prompt 還不夠」的情境：你需要用可執行、而且容易捨棄的東西，來測試狀態轉換、資料結構，或 UI 方向。

適合安裝 prototype skill 的人

如果你常說「prototype 這個」、「給我幾個方案看看」或「我不確定哪種結構才對」，就很適合安裝 prototype skill。它特別適合在既有 repo 裡工作的 agent，因為原型應該要貼近本地慣例，而不是從一個空白沙盒重新開始。

它為什麼不一樣

這個 prototype skill 不把自己當成通用的腦力激盪 prompt。它會逼你在一開始就做分支選擇：要嘛是偏邏輯的 terminal prototype，要嘛是帶多個視覺變體的 UI prototype。這個決策就是它的核心價值，因為它能避免把時間花在錯的 prototype 類型上。

最適合與不適合的情境

prototype 適合用在設計探索、商業規則邊界案例、狀態機不確定性，或是「這東西應該長什麼樣子？」這類工作。如果你已經知道最終實作長什麼樣，或你只需要文字說明而不是可執行的 prototype，就不要用它。

如何使用 prototype skill

安裝並找到原始來源

使用 npx skills add mattpocock/skills --skill prototype 安裝 prototype skill。接著先讀 SKILL.md，再依問題類型閱讀 LOGIC.md 或 UI.md。如果你需要更完整的脈絡，也可以掃一下 repo 裡的 README.md、AGENTS.md、metadata.json，以及附近的 rules/、resources/ 或 references/ 資料夾。

選對分支

prototype skill 的核心使用判斷很簡單：邏輯問題看 LOGIC.md；視覺問題看 UI.md。如果 prompt 很模糊，就從周邊程式碼推斷：後端或模型密集的程式通常偏向 logic，而頁面或元件通常偏向 UI。如果使用者在場，先問一個澄清問題再開始做。

把模糊想法轉成可用的 prompt

一個夠強的 prototype guide prompt 會把問題、目標表面，以及限制條件說清楚。比起說「prototype billing」，「原型測試這個訂閱狀態機是否能處理取消、寬限期與恢復流程」更有用。做 UI 時，要說明它屬於哪個畫面、哪些既有資料必須保持真實，以及你想要幾個變體。問題越具體，skill 產出錯誤 artifact 的機率就越低。

先讀哪些檔案

先看 SKILL.md，理解分支規則與共通限制。接著，如果你需要一個小型互動式狀態探索工具，就讀 LOGIC.md；如果你需要同一路徑上的多個版型，就讀 UI.md。這些檔案之所以是做出實際安裝判斷的最快路徑，是因為它們展示的是工作流程，而不只是概念。

prototype skill 常見問題

prototype 只適合前端嗎？

不是。prototype skill 是刻意拆成兩條分支：一條用於 UI 探索，另一條用於商業邏輯或狀態建模。如果你要測試「這東西應該長怎樣」，用 UI 分支；如果你要測試「這個狀態變化合理嗎」，就用 logic 分支。

它和一般 prompt 有什麼不同？

一般 prompt 可以要求 mockup，但 prototype skill 會加入一套降低猜測成本的工作流程：先選分支、保持成果可丟棄，並把輸出推向你真的可以檢視的東西。當選錯設計的代價很高時，這種做法會實用得多。

prototype skill 對新手友善嗎？

可以，只要你能清楚描述問題。當需求很模糊時，它就沒那麼新手友善，因為這個 skill 依賴你選對分支，並且要符合 host project 的慣例。如果你不知道 runtime 或頁面形狀，預期就要多提供一些背景資訊。

什麼時候不該把 prototype 用在 Prototypes？

不要把它用在最終正式實作、廣泛的架構重整，或是你其實只需要文案撰寫／發想的情境。prototype skill 最強的是產出一個可丟棄的成果，幫你做決策；它不是拿來直接交付的精緻成品。

如何改善 prototype skill

提問題，不要先下結論

要改善 prototype skill 的輸出，最有效的方法是把你要解決的不確定性講清楚。不要說「做一個更好的 checkout」，而要說「測試單頁 checkout 能不能在不顯得擁擠的情況下，同時處理 coupon 輸入、運送方式選擇和付款錯誤。」這樣才真的給了 skill 一個決策目標。

提供最少但真實的脈絡

想讓 prototype guide 的結果更好，就要包含 host route、相關的資料結構、必須保留的既有元件，以及像 framework、runtime、或 no-new-dependencies 之類的限制。當 skill 能夠貼近真實環境，而不是憑空想像一個環境時，prototype 品質通常會明顯提升。

留意最常見的失誤模式

最大的失誤模式，是太早選錯分支。如果 prototype 做的是錯的事情，即使輸出看起來很精緻，最後仍然毫無用處。拿不定主意時，要求 skill 在最上方先寫出它的假設，並把 prototype 的範圍縮得只對應那個假設。

每次只加一個更精準的限制

第一次做完之後，要改善 prototype install 的結果，通常不是一次要求「更多選項」，而是每次只改一件事：減少變體、讓資料更真實、把邊界案例收得更嚴格，或把目標畫面說得更明確。這通常比要求「更多方案」有效，因為這個 skill 的設計目標是回答問題，而不是追求最大覆蓋面。