before-you-build
建置前先做風險審查，找出最危險的假設和最小的驗證步驟
中文翻譯
--- name: before-you-build description: 給創辦人、產品經理和 AI 輔助開發者用的建置前產品與功能風險審查。使用者即將建構 landing page、MVP、SaaS 產品、內部工具、agent 工作流程或重大功能，需要在實作開始之前檢查需求、定位、變現、留存、信任、通路和採用風險時，使用這個 skill。 --- # Before You Build 在實作之前，做一次精簡的 pre-mortem。目的不是擋住建置，而是找出風險最高的假設、最小的驗證步驟，以及在證據變好之前應該延後的建置範圍。 ## 何時使用 使用者要求建置或上線下列東西時，使用這個 skill： - 新產品、MVP、原型、landing page、SaaS app、市集、內容網站、agent 工作流程或內部工具 - 在採用率、營收、留存、信任或通路影響上不明確的重大功能 - 定位薄弱可能浪費開發或推廣力氣的公開上線素材 如果任務是範圍狹窄的實作修正、重構、測試修復、相依套件更新，或是已經驗證過、有明確驗收標準的變更，就跳過這個 skill。 ## 風險檢查清單 從這些風險檢視這個想法： - **需求：** 有證據顯示特定的買家或使用者迫切想要這個嗎？ - **定位：** 目標使用者能用一句話理解它是什麼、為什麼重要嗎？ - **變現：** 有可信的路徑能帶來付費、預算或策略價值嗎？ - **留存：** 使用者第一次試用後，有理由再回來嗎？ - **信任：** 產品需要可信度、資料存取權、整合，或使用者可能抗拒的行為改變嗎？ - **通路：** 有可重複的方式能接觸到目標使用者嗎？ - **功能採用：** 針對功能類的工作，這個功能會改變使用者行為，還是只是增加表面積？ 如果結論不明顯，用 `references/risk-checklist.md` 來問更深入的問題。 ## 輸出格式 回應要簡短，並以決策為導向： 1. **風險結論：** 低、中或高風險，附一句話說明原因。 2. **主要假設：** 最有可能讓專案垮掉的那一個假設。 3. **要先找的證據：** 在繼續建置之前，最小而有用的訊號。 4. **接下來做：** 一個具體的驗證步驟，或縮小後的建置範圍。 5. **延後：** 現在先不要建什麼。 ## 指引 - 對薄弱的證據要直說，但不要否定使用者的想法。 - 優先選擇較小的驗證步驟，不要做大型的研究計畫。 - 把產品風險跟工程難度分開。 - 如果想法已經驗證過，要說明是什麼證據降低了風險，並建議最小的實作切片。 - 如果缺少事實，要點出缺少的證據，不要編造市場說法。
英文原文
--- name: before-you-build description: Pre-build product and feature risk review for founders, product managers, and AI-assisted builders. Use this skill when the user is about to build a landing page, MVP, SaaS product, internal tool, agent workflow, or major feature and needs to check demand, positioning, monetization, retention, trust, distribution, and adoption risk before implementation starts. --- # Before You Build Run a compact pre-mortem before implementation. The goal is not to block building; it is to identify the highest-risk assumption, the smallest validation step, and the build scope that should be delayed until evidence improves. ## When To Use Use this skill when a user asks to build or ship: - A new product, MVP, prototype, landing page, SaaS app, marketplace, content site, agent workflow, or internal tool - A major feature with unclear adoption, revenue, retention, trust, or distribution impact - A public launch asset where weak positioning could waste development or promotion effort Skip this skill when the task is a narrow implementation fix, refactor, test repair, dependency update, or already-validated change with clear acceptance criteria. ## Risk Checklist Review the idea across these risks: - **Demand:** Is there evidence that a specific buyer or user urgently wants this? - **Positioning:** Can the target user understand what it is and why it matters in one sentence? - **Monetization:** Is there a credible path to payment, budget, or strategic value? - **Retention:** Is there a reason users would return after the first try? - **Trust:** Does the product require credibility, data access, integrations, or behavior change that users may resist? - **Distribution:** Is there a repeatable way to reach the target user? - **Feature adoption:** For feature work, will the feature change user behavior or just add surface area? If the verdict is not obvious, use `references/risk-checklist.md` for deeper questions. ## Output Format Keep the response short and decision-oriented: 1. **Risk verdict:** Low, medium, or high risk, with one sentence explaining why. 2. **Main assumption:** The single assumption most likely to break the project. 3. **Evidence to find first:** The smallest useful signal before building more. 4. **Do next:** One concrete validation step or reduced build scope. 5. **Delay:** What not to build yet. ## Guidance - Be direct about weak evidence, but avoid dismissing the user's idea. - Prefer smaller validation steps over large research plans. - Separate product risk from engineering difficulty. - If the idea is already validated, say what evidence makes it lower risk and suggest the smallest implementation slice. - If facts are missing, name the missing evidence instead of inventing market claims.