before-you-build

Name: before-you-build
Author: wshobson

616installs4.1kforks

How to install before-you-build?

wshobson/agents/before-you-build

$npx -y skills add wshobson/agents --skill before-you-build

Installs into the current project.

Summary

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, monetizati

Files · 1

View on GitHub

SKILL.md

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

People who liked this also viewed

6 picks

Type

before-you-build

616installs4.1kforks

View on GitHub

How to install before-you-build?

wshobson/agents/before-you-build

$npx -y skills add wshobson/agents --skill before-you-build

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

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

People who liked this also viewed

6 picks

Type