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:
- Risk verdict: Low, medium, or high risk, with one sentence explaining why.
- Main assumption: The single assumption most likely to break the project.
- Evidence to find first: The smallest useful signal before building more.
- Do next: One concrete validation step or reduced build scope.
- 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.
Source: wshobson/agents → plugins/before-you-build/skills/before-you-build/SKILL.md
1---2name: before-you-build-23description: 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---5
6
7# Before You Build
8
9Run 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.
10
11## When To Use
12
13Use this skill when a user asks to build or ship:
14
15- A new product, MVP, prototype, landing page, SaaS app, marketplace, content site, agent workflow, or internal tool
16- A major feature with unclear adoption, revenue, retention, trust, or distribution impact
17- A public launch asset where weak positioning could waste development or promotion effort
18
19Skip this skill when the task is a narrow implementation fix, refactor, test repair, dependency update, or already-validated change with clear acceptance criteria.
20
21## Risk Checklist
22
23Review the idea across these risks:
24
25- **Demand:** Is there evidence that a specific buyer or user urgently wants this?
26- **Positioning:** Can the target user understand what it is and why it matters in one sentence?
27- **Monetization:** Is there a credible path to payment, budget, or strategic value?
28- **Retention:** Is there a reason users would return after the first try?
29- **Trust:** Does the product require credibility, data access, integrations, or behavior change that users may resist?
30- **Distribution:** Is there a repeatable way to reach the target user?
31- **Feature adoption:** For feature work, will the feature change user behavior or just add surface area?
32
33If the verdict is not obvious, use `references/risk-checklist.md` for deeper questions.
34
35## Output Format
36
37Keep the response short and decision-oriented:
38
391. **Risk verdict:** Low, medium, or high risk, with one sentence explaining why.
402. **Main assumption:** The single assumption most likely to break the project.
413. **Evidence to find first:** The smallest useful signal before building more.
424. **Do next:** One concrete validation step or reduced build scope.
435. **Delay:** What not to build yet.
44
45## Guidance
46
47- Be direct about weak evidence, but avoid dismissing the user's idea.
48- Prefer smaller validation steps over large research plans.
49- Separate product risk from engineering difficulty.
50- If the idea is already validated, say what evidence makes it lower risk and suggest the smallest implementation slice.
51- If facts are missing, name the missing evidence instead of inventing market claims.
52
53---
54
55**Source:** [`wshobson/agents`](https://github.com/wshobson/agents) → `plugins/before-you-build/skills/before-you-build/SKILL.md`
wshobson