Before You Build
Unverified●30/40Claude Code◐PartialHas SKILL.md but declares no allowed-tools — Claude Code will ask for permission each time
Cursor◐PartialPlain prose you can paste in — but no Cursor rules file
Codex◐PartialPlain prose you can paste in — but no AGENTS.md
Gemini CLI◐PartialPlain prose you can paste in
Copilot◐PartialPlain prose you can paste in — but no Copilot instructions file
npx agentalley add before-you-buildWho is stuck, and on what
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.
The whole source
Frontmatter — 2 properties
| 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. |
| 1 | --- |
| 2 | name: before-you-build |
| 3 | 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. |
| 4 | ---A5 — No allowed-tools declared — no way to tell what this skill may touch |
| 5 | |
| 6 | # Before You Build |
| 7 | |
| 8 | 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. |
| 9 | |
| 10 | ## When To Use |
| 11 | |
| 12 | Use this skill when a user asks to build or ship: |
| 13 | |
| 14 | - A new product, MVP, prototype, landing page, SaaS app, marketplace, content site, agent workflow, or internal tool |
| 15 | - A major feature with unclear adoption, revenue, retention, trust, or distribution impact |
| 16 | - A public launch asset where weak positioning could waste development or promotion effort |
| 17 | |
| 18 | Skip this skill when the task is a narrow implementation fix, refactor, test repair, dependency update, or already-validated change with clear acceptance criteria. |
| 19 | |
| 20 | ## Risk Checklist |
| 21 | |
| 22 | Review the idea across these risks: |
| 23 | |
| 24 | - **Demand:** Is there evidence that a specific buyer or user urgently wants this? |
| 25 | - **Positioning:** Can the target user understand what it is and why it matters in one sentence? |
| 26 | - **Monetization:** Is there a credible path to payment, budget, or strategic value? |
| 27 | - **Retention:** Is there a reason users would return after the first try? |
| 28 | - **Trust:** Does the product require credibility, data access, integrations, or behavior change that users may resist? |
| 29 | - **Distribution:** Is there a repeatable way to reach the target user? |
| 30 | - **Feature adoption:** For feature work, will the feature change user behavior or just add surface area? |
| 31 | |
| 32 | If the verdict is not obvious, use `references/risk-checklist.md` for deeper questions. |
| 33 | |
| 34 | ## Output Format |
| 35 | |
| 36 | Keep the response short and decision-oriented: |
| 37 | |
| 38 | 1. **Risk verdict:** Low, medium, or high risk, with one sentence explaining why. |
| 39 | 2. **Main assumption:** The single assumption most likely to break the project. |
| 40 | 3. **Evidence to find first:** The smallest useful signal before building more. |
| 41 | 4. **Do next:** One concrete validation step or reduced build scope. |
| 42 | 5. **Delay:** What not to build yet. |
| 43 | |
| 44 | ## Guidance |
| 45 | |
| 46 | - Be direct about weak evidence, but avoid dismissing the user's idea. |
| 47 | - Prefer smaller validation steps over large research plans. |
| 48 | - Separate product risk from engineering difficulty. |
| 49 | - If the idea is already validated, say what evidence makes it lower risk and suggest the smallest implementation slice. |
| 50 | - If facts are missing, name the missing evidence instead of inventing market claims. |
| 51 |
Reviews
Installed this one?Write the first review and take the Trailblazer badge.
Alternatives
Structure Your Invention For A Patent FilingDescribe your invention in plain words and get back a formal write-up that lays out the problem it solves, how it works, and which parts are worth protecting.●····●37/40Claims Drafting: The Core Patent SkillDescribe your invention in plain words and get back a numbered set of formal patent claims — the legal wording that defines exactly what you own.●····●36/40Patent Novelty and Non-Obviousness CheckDescribe your invention in everyday words and get back a clear read on whether it's new and original enough to patent, plus where it might hit trouble.●····●35/40Patent Pipeline: From Invention to FilingDescribe your invention in plain words and get back a complete first-draft patent application — claims, full description, and abstract — ready to hand to a patent attorney.●····●35/40