shape

shape skill 概覽

shape 的作用是什麼

shape skill 是一套以規劃優先的 UX/UI 工作流程，重點是在任何程式碼開始撰寫前，先把功能定義清楚。它不會一開始就直接跳進版面或元件，而是先進行結構化的探索式訪談，再把回答整理成設計 brief。這讓它特別適合這類情境：團隊大致知道要做什麼，但還沒釐清使用者目標、限制條件、各種狀態、邊界案例，或實作方向。

哪些人適合安裝 shape skill

shape skill 最適合重視產品決策的開發者、設計師、前端工程師，以及仰賴 AI 協作的團隊，他們希望在做 prototype 前先把關鍵決策想清楚。尤其在 shape for UI Design 的情境下，如果功能本身還很模糊，它會特別有價值，例如新流程、dashboard、表單、onboarding、settings，或任何那種如果只是「直接生成一個 UI」就很可能忽略使用者真正需求的介面。

為什麼大家會選 shape，而不是一般 prompt

一般 prompt 常常會直接產出 mockup 或元件點子；shape 則是刻意把節奏放慢。它的核心差異在於：先強制收集上下文，再產出之後可以交接給實作型 skill 的設計 brief。repo 對它的定位寫得很清楚：這是設計規劃工具，不是寫程式工具。若你想少一點流於表面的 UI 建議，多一些有根據、能說服團隊的產品決策，這條界線反而很有價值。

如何使用 shape skill

安裝情境與必要前置條件

請透過你的 skills workflow，從 pbakaus/impeccable repository 安裝這個 skill，例如：
npx skills add pbakaus/impeccable --skill shape

採用 shape skill 時，最重要的細節是 SKILL.md 裡寫明的前置條件：shape requires /impeccable first。skill 明確要求你先呼叫 /impeccable、遵循它的 Context Gathering Protocol；如果目前還沒有設計相關上下文，就要先執行 /impeccable teach，之後再使用 shape skill。如果你跳過這一步，其實就已經偏離它原本設計的工作流程。

要讓 shape 發揮效果，需要提供哪些輸入

它的 argument hint 是 [feature to shape]，但只丟一句功能名稱通常不夠。比較好的 shape 使用方式，通常會從以下資訊開始：

• 功能目標
• 目標使用者或角色
• 目前的工作流程或痛點
• 成功標準
• 平台、權限、法規遵循、既有 design system 等硬性限制
• 已知的邊界案例或明確不做的範圍

較弱的輸入例子：
Shape a notifications page.

較強的輸入例子：
Shape a notifications center for account admins who miss urgent billing and security events. It must work on desktop first, reuse our existing table and filter patterns, and avoid adding real-time infrastructure in v1.

實際工作流程，以及優先該讀哪些檔案

先讀 SKILL.md，把它當成操作上的正式契約。這個 repository snapshot 目前只看到這個檔案，因此大部分價值都來自於是否照它的順序正確執行：

1. 先透過 /impeccable 蒐集設計上下文。
2. 在規劃階段使用 shape，不要拿來做實作。
3. 讓它主導探索式訪談。
4. 把訪談結果整理成設計 brief。
5. 再把 brief 交給 /impeccable craft、/impeccable，或其他實作流程。

這個順序很重要，因為 shape skill 的優化目標，是在 UI 工作開始前先減少猜測與誤判，而不是一次就產出看起來很完整的精緻畫面。

哪種 prompt 寫法，shape skill 會有更好輸出

如果你想更有效地使用 shape skill，建議明確要求它先做訪談，再交付最終產物。比較好的結構包括：

• 要 shape 的功能
• 主要使用者是誰
• 目前問題是什麼
• 必須遵守的限制
• 你希望 brief 幫你定案哪些決策

範例：
Use shape to plan a bulk-edit inventory feature for operations managers. Interview me first. Focus on user intent, error prevention, empty/loading/failure states, permissions, and what the v1 interaction model should be. Output a design brief I can hand to implementation.

這會比直接說「design a UI for X」更有效，因為它讓 skill 有空間先問澄清問題，再決定設計方向，而不是一開始就把方向鎖死。

shape skill 常見問題

shape skill 是拿來寫程式，還是拿來做規劃？

shape skill 是用來做規劃的。repository 說得很明白：它不會寫程式。它的輸出是設計 brief，作用是指引後續實作。如果你要的是立即產出程式碼，那它不是好的起點；如果你要的是先把產品與 UI 決策做對，那它就很適合。

什麼時候 shape 會比一般 prompting 更好用？

當功能定義還不完整、風險較高、直接面向使用者，或很可能牽涉複雜狀態與取捨時，就適合用 shape。一般 prompt 對於隨手做個 mockup 可能更快；但如果你需要的是對工作流程、使用者需求、限制條件，以及交接品質做出更扎實的推理，shape skill 會更合適。

shape skill 適合初學者嗎？

適合，但有一個前提：初學者仍然需要具備足夠的產品上下文，才能好好回答探索式訪談。這個 skill 提供的是結構，不會幫你憑空發明使用者、限制條件或成功指標。如果你剛接觸 UX 規劃，它這種以訪談驅動的方式其實反而有幫助，因為它會把那些本來就應該先回答的問題攤開來。

什麼情況不該把 shape 用在 UI Design？

如果問題已經完全定義好、你只需要很小的視覺微調，或任務本質上純技術導向、跟使用者互動無關，就可以跳過 shape for UI Design。另外，如果你不願意先做前置的 context gathering，它也不適合你，因為 shape skill 本來就建立在這個基礎之上。

如何把 shape skill 用得更好

給 shape 更好的規劃輸入

影響品質最大的槓桿就是輸入品質。對 shape skill 來說，好的輸入不只是功能名稱而已。請盡量補上使用者類型、任務頻率、失敗成本、既有互動模式、商業規則，以及哪些內容應該排除在範圍外。skill 還是會再訪談你，但如果一開始的上下文更完整，最後的 brief 會更聚焦，也更不容易落入泛泛而談的建議。

避開 shape skill 最常見的失敗模式：過早進入解法

這個 repo 最強烈的提醒，就是不要太早做設計決策。shape skill 最常見的錯誤用法之一，就是在還沒釐清使用者問題之前，就先要求畫面、cards、tabs 或版面配置。如果你發現對話太早跳到介面模式，請把方向拉回來：先追問尚未滿足的使用者需求、任務流程、各種狀態、取捨，以及限制條件。

不只改 prompt，也要迭代設計 brief

第一輪完成後，請用挑戰不清楚決策的方式來強化 brief：

• 哪個使用者目標才是最主要的？
• 還少了哪些狀態？
• 哪些假設需要驗證？
• 哪些內容是刻意不放進 v1 的？
• 哪些地方會讓後續實作產生歧義？

這種迭代方式，對提升 shape 使用效果 的幫助，通常比反覆要求「做一個更好的 UI」還大。

把 shape 與下游執行流程串起來

要真正提升 shape install 的價值，最實際的做法是把它當成整條工作鏈的第一站。先用 shape 產出 brief，再把這份 brief 交給 /impeccable craft 或其他實作型 skill。你的交接產物越清楚，後續生成的程式碼或設計就越有機會持續對齊使用者需求，而不會慢慢漂向那種看似合理、實際上很薄弱的 UI。