Claude Cursor Skill

before-you-build

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

LLM Mart · 0 points · 13 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download wshobson-agents-plugins_before-you-build_skills_before-you-build-554237f.zip · 2 KB

wshobson/agents 39771 4241 forks MIT Updated 11d ago

Part of wshobson/agents — 170 skills

Install

skills CLI npx skills add https://github.com/wshobson/agents/tree/main/plugins/before-you-build/skills/before-you-build

Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install wshobson-agents@llmmart

Git git clone https://github.com/wshobson/agents.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole wshobson/agents collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

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.

Files (agents)

references

risk-checklist.md 1.6 KB

# Risk Checklist

Use these questions when the basic verdict is not obvious.

## Demand

- Who has the painful problem today?
- What workaround are they using now?
- What behavior shows urgency: payment, repeated manual work, switching tools, or asking for the same outcome more than once?

## Positioning

- Can the target user say what this is for without hearing the implementation details?
- Is the promise tied to a concrete outcome rather than a broad category?
- Does the idea have a clear alternative it must beat?

## Monetization

- Who controls the budget or time savings?
- Is the value large enough to support the required build and maintenance cost?
- Would the first useful version create enough value to justify payment, adoption, or internal sponsorship?

## Retention

- What makes the product useful after the first session?
- Does it create a saved workflow, history, collaboration loop, or recurring decision?
- Would users remember to come back without reminders?

## Trust

- What data, permissions, integrations, or behavior changes does this require?
- What proof would make a cautious user comfortable trying it?
- What failure would make the product feel unsafe or unserious?

## Distribution

- Where can the exact target user be reached repeatedly?
- What existing channel, community, workflow, or integration can expose the product?
- Is there a realistic path beyond one launch post?

## Feature Adoption

- What existing user behavior will this feature change?
- Is the feature tied to an active user pain or just a product idea?
- Can adoption be measured with one clear event?

SKILL.md 2.7 KB

---
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.