/validate
Use this skill when the user needs to validate a business idea, test demand before building, run a smoke test, create an MVP experiment, or decide whether an idea is worth pursuing. Covers demand validation, smoke tests, fake-door tests, landing page experiments, and go/no-go
$ npx -y skills add whawkinsiv/claude-code-superpowers --skill validate --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/validate
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use this skill when the user needs to validate a business idea, test demand before building, run a smoke test, create an MVP experiment, or decide whether an idea is worth pursuing. Covers demand validation, smoke tests, fake-door tests, landing page experiments, and go/no-go
SKILL.md
validate.SKILL.mdname: validate
description: "Use this skill when the user needs to validate a business idea, test demand before building, run a smoke test, create an MVP experiment, or decide whether an idea is worth pursuing. Covers demand validation, smoke tests, fake-door tests, landing page experiments, and go/no-go decision frameworks for bootstrapped founders."
Idea Validation
The #1 reason startups fail is "no market need." Validation isn't about asking people if they'd use something — it's about observing whether they'll pay, sign up, or take action. This skill helps you test demand before writing a single line of code.
Core Principles
- Ideas are free. Validated demand is valuable. Never skip validation because you're excited.
- "Would you use this?" is a useless question. "Will you pay $X right now?" is the only one that matters.
- The goal of validation is to fail fast and cheap — not to confirm what you already believe.
- You don't need to build anything to validate. Landing pages, waitlists, and conversations come first.
- Validation is not a one-time event. You re-validate at every stage: idea, MVP, pricing, features.
Pressure-Test Your Idea
Before running experiments, pressure-test the idea itself. These six questions expose fatal flaws fast — answer them honestly, not optimistically.
Which Questions to Answer
| Your Stage | Focus On | |-----------|----------| | Pre-product (just an idea) | Q1, Q2, Q3 | | Have a prototype or early users | Q2, Q4, Q5 | | Have paying customers | Q4, Q5, Q6 |
The Six Questions
**Q1 — Demand Reality:** What evidence do you have — beyond your own experience — that someone else actually wants this? Not "I think people need it." What have you seen, heard, or measured?
**Q2 — Status Quo:** What are people in your field doing right now to handle this — even badly? What does that workaround cost them in time, money, or errors?
**Q3 — Desperate Specificity:** Name one specific person who needs this most. Not "dentists" — which dentist, at which practice, with what problem? If you can't name someone, you haven't found your customer yet.
**Q4 — Narrowest Wedge:** What's the smallest version of this someone would pay for this week — not after you build the platform? One screen, one workflow, one outcome.
**Q5 — Observation:** Have you watched a colleague struggle with this task without helping them? What surprised you about how they actually do it vs. how you assumed?
**Q6 — Future-Fit:** How does your industry change in 3 years, and does that make this tool more essential or less?
> **Interest is not demand.** Waitlist signups are not demand. Someone would be genuinely upset if it disappeared — that's demand.
> **"Everyone in my field needs this"** means you haven't found anyone specific yet. The more universal you think the need is, the less validated it actually is.
> **The status quo is your real competitor** — not the other startup. It's the spreadsheet-and-email workaround people already live with. You have to be dramatically better than "good enough."
---
Validation Levels
Level 1: Problem Validation (Do People Have This Problem?)
Before you validate your solution, validate that the problem exists and is painful enough to pay for.
**Where to look for evidence:**
| Source | What to Look For | |--------|-----------------| | Reddit, forums, communities | People complaining about the problem repeatedly | | Google Trends | Search volume for problem-related terms | | Competitor reviews (G2, Capterra) | 1-3 star reviews mentioning unmet needs | | Twitter/X | People publicly frustrated with current solutions | | Your own experience | You've felt this pain yourself (strongest signal) |
**Tell AI:**
Research the problem of [describe the problem].
Find evidence that people are actively looking for solutions:
- Search volume for related terms
- Reddit/forum threads where people discuss this pain
- Competitors that exist (even partial solutions)
- How much people currently pay to solve this (or workarounds they use)
Summarize: Is this a real, painful, frequent problem?
Level 2: Solution Validation (Will People Want YOUR Solution?)
**The Mom Test** — Never ask leading questions. Instead:
| Bad Question | Good Question | |-------------|--------------| | "Would you use an app that does X?" | "How do you currently handle X?" | | "Would you pay for this?" | "What do you spend on solving X today?" | | "Do you think this is a good idea?" | "Tell me about the last time X was a problem." | | "Would this be useful?" | "What have you tried? What didn't work?" |
**Conversation template:**
1. "What's the hardest part about [area]?"
2. "Tell me about the last time that happened."
3. "How did you deal with it?"
4. "What didn't work about that solution?"
5. "If you could wave a magic wand, what would change?"
6. "How much time/money does this cost you today?"
Talk to 10-15 potential customers. If 8+ describe the same pain with intensity, you have signal.
Level 3: Willingness to Pay (Will They Open Their Wallets?)
The strongest validation signals, ranked:
| Signal | Strength | |--------|----------| | They pre-pay before the product exists | Strongest | | They sign up for a waitlist with a credit card | Very strong | | They sign up for a waitlist with email | Strong | | They click a "Buy" button (fake door test) | Moderate | | They say "I'd definitely pay for that" | Weak | | They say "That's a cool idea" | Worthless |
---
For Domain Experts: Your Network Is Your Validation Lab
If you're a [profession] building for other [professionals], you already have what most founders spend months trying to get: direct access to target customers.
- **Skip the cold outreach.** Message 10 peers you actually know: "Hey, how do you handle [pain]? I'm thinking about building something."
- **You've already had 1,000 customer conversations.** Mine your memory: what do colleagues complain about at conferences, in group
Read more
name: validate description: "Use this skill when the user needs to validate a business idea, test demand before building, run a smoke test, create an MVP experiment, or decide whether an idea is worth pursuing. Covers demand validation, smoke tests, fake-door tests, landing page experiments, and go/no-go decision frameworks for bootstrapped founders."
Idea Validation
The #1 reason startups fail is "no market need." Validation isn't about asking people if they'd use something — it's about observing whether they'll pay, sign up, or take action. This skill helps you test demand before writing a single line of code.
Core Principles
- Ideas are free. Validated demand is valuable. Never skip validation because you're excited.
- "Would you use this?" is a useless question. "Will you pay $X right now?" is the only one that matters.
- The goal of validation is to fail fast and cheap — not to confirm what you already believe.
- You don't need to build anything to validate. Landing pages, waitlists, and conversations come first.
- Validation is not a one-time event. You re-validate at every stage: idea, MVP, pricing, features.
Pressure-Test Your Idea
Before running experiments, pressure-test the idea itself. These six questions expose fatal flaws fast — answer them honestly, not optimistically.
Which Questions to Answer
| Your Stage | Focus On | |-----------|----------| | Pre-product (just an idea) | Q1, Q2, Q3 | | Have a prototype or early users | Q2, Q4, Q5 | | Have paying customers | Q4, Q5, Q6 |
The Six Questions
**Q1 — Demand Reality:** What evidence do you have — beyond your own experience — that someone else actually wants this? Not "I think people need it." What have you seen, heard, or measured?
**Q2 — Status Quo:** What are people in your field doing right now to handle this — even badly? What does that workaround cost them in time, money, or errors?
**Q3 — Desperate Specificity:** Name one specific person who needs this most. Not "dentists" — which dentist, at which practice, with what problem? If you can't name someone, you haven't found your customer yet.
**Q4 — Narrowest Wedge:** What's the smallest version of this someone would pay for this week — not after you build the platform? One screen, one workflow, one outcome.
**Q5 — Observation:** Have you watched a colleague struggle with this task without helping them? What surprised you about how they actually do it vs. how you assumed?
**Q6 — Future-Fit:** How does your industry change in 3 years, and does that make this tool more essential or less?
> **Interest is not demand.** Waitlist signups are not demand. Someone would be genuinely upset if it disappeared — that's demand.
> **"Everyone in my field needs this"** means you haven't found anyone specific yet. The more universal you think the need is, the less validated it actually is.
> **The status quo is your real competitor** — not the other startup. It's the spreadsheet-and-email workaround people already live with. You have to be dramatically better than "good enough."
---
Validation Levels
Level 1: Problem Validation (Do People Have This Problem?)
Before you validate your solution, validate that the problem exists and is painful enough to pay for.
**Where to look for evidence:**
| Source | What to Look For | |--------|-----------------| | Reddit, forums, communities | People complaining about the problem repeatedly | | Google Trends | Search volume for problem-related terms | | Competitor reviews (G2, Capterra) | 1-3 star reviews mentioning unmet needs | | Twitter/X | People publicly frustrated with current solutions | | Your own experience | You've felt this pain yourself (strongest signal) |
**Tell AI:**
Research the problem of [describe the problem]. Find evidence that people are actively looking for solutions: - Search volume for related terms - Reddit/forum threads where people discuss this pain - Competitors that exist (even partial solutions) - How much people currently pay to solve this (or workarounds they use) Summarize: Is this a real, painful, frequent problem?
Level 2: Solution Validation (Will People Want YOUR Solution?)
**The Mom Test** — Never ask leading questions. Instead:
| Bad Question | Good Question | |-------------|--------------| | "Would you use an app that does X?" | "How do you currently handle X?" | | "Would you pay for this?" | "What do you spend on solving X today?" | | "Do you think this is a good idea?" | "Tell me about the last time X was a problem." | | "Would this be useful?" | "What have you tried? What didn't work?" |
**Conversation template:**
1. "What's the hardest part about [area]?" 2. "Tell me about the last time that happened." 3. "How did you deal with it?" 4. "What didn't work about that solution?" 5. "If you could wave a magic wand, what would change?" 6. "How much time/money does this cost you today?"
Talk to 10-15 potential customers. If 8+ describe the same pain with intensity, you have signal.
Level 3: Willingness to Pay (Will They Open Their Wallets?)
The strongest validation signals, ranked:
| Signal | Strength | |--------|----------| | They pre-pay before the product exists | Strongest | | They sign up for a waitlist with a credit card | Very strong | | They sign up for a waitlist with email | Strong | | They click a "Buy" button (fake door test) | Moderate | | They say "I'd definitely pay for that" | Weak | | They say "That's a cool idea" | Worthless |
---
For Domain Experts: Your Network Is Your Validation Lab
If you're a [profession] building for other [professionals], you already have what most founders spend months trying to get: direct access to target customers.
- **Skip the cold outreach.** Message 10 peers you actually know: "Hey, how do you handle [pain]? I'm thinking about building something."
- **You've already had 1,000 customer conversations.** Mine your memory: what do colleagues complain about at conferences, in group
43 expert skills for non-technical founders building SaaS with AI tools (Claude Code, Lovable, Replit, Cursor). Covers the full lifecycle of planning, building, launching, and growing a software business — actionable guides, checklists, and copy-paste prompts.
Other skills on solo-founder-superpowers.
- /about-me
Use this skill when the user wants to create a founder profile, establish their personal voice for content, or set up context so other skills produce personalized output instead of generic AI copy. Also use when the user says 'set up my voice,' 'create my profile,' 'who am I,'
Open skill - /accounting
Use this skill when the user needs to set up bookkeeping, track revenue and expenses, prepare for taxes, choose accounting software, understand SaaS revenue recognition, or manage the financial operations of their bootstrapped business. Covers bookkeeping setup, tax preparation,
Open skill - /ads
Use this skill when the user needs to run Google Ads, write ad copy, select keywords, optimize CAC/LTV, or manage a small paid acquisition budget. Covers Google Ads strategy, keyword selection, ad copywriting, and conversion tracking for bootstrapped SaaS.
Open skill - /ai-features
Use this skill when the user needs to add AI-powered features to their SaaS product, integrate LLM APIs, build AI assistants, implement RAG, or use AI to differentiate their product. Covers API selection, prompt engineering for product features, cost management, and building AI
Open skill - /analytics
Use this skill when the user needs to set up analytics, design event tracking, define key metrics, build funnels, or instrument their SaaS product for data-driven decisions. Covers event naming conventions, tracking strategy, funnel analytics, and data quality.
Open skill - /beautify
Use this skill when the user wants to make their app look better, says it looks like a template, asks how to achieve Stripe/Linear quality, or says something looks off. Covers visual hierarchy, whitespace, composition, color application, and typography in practice.
Open skill

