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

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.

before-you-build