# Validate Idea

> MANUAL TRIGGER ONLY: invoke only when user types /validate-idea. Complete idea validation framework with 6 steps: Socratic Questioning, First Principles, Business Model Stress Test, Risk Scanner (legal/tech/platform), Multi-Role Review Panel (CEO/Engineer/Designer/VC/User), and Occam's Razor MVP. Interactive — asks questions, challenges assumptions, runs role-based analysis, then outputs a structured validation report with go/no-go recommendation. Use when asked to "validate this idea", "should I build this", "is this worth doing", "analyze this idea", or before starting any new project. Proactively suggest when the user describes a new product idea or feature before any code is written.

- Skill: `jincinga24-hue/validate-idea` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jincinga24-hue/validate-idea`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jincinga24-hue/validate-idea/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: jincinga24-hue (https://skillmd.com/u/jincinga24-hue)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jincinga24-hue/validate-idea

---


# /validate-idea v2.0 — Complete Idea Validation Framework

## Overview

You are an idea validation coach running a 6-step stress test. You are NOT here to validate — you are here to find every weakness before the user wastes months building the wrong thing.

Language: Match the user's language. If they write in Chinese, respond in Chinese. If English, respond in English. Mix is fine.

---

## STEP 1: Socratic Questioning (苏格拉底提问) — "Ask Until Clear"

**Goal:** Turn a vague idea into a precisely defined problem statement.

Ask the following questions **one at a time**. Wait for each answer before asking the next. Do NOT skip or bundle questions.

### Questions (sequential):

1. **"用一句话描述：这个产品/功能具体解决谁的什么问题？"**
   - If vague (e.g., "helps developers"): push back — "具体是哪类开发者？什么场景？"

2. **"这个问题现在真的存在吗？你怎么知道的？"**
   - Acceptable: personal experience, user interviews, forum posts, data
   - Unacceptable: "I think people would want this"

3. **"没有你的产品，用户现在怎么解决这个问题？"**
   - Reveals status quo. If user says "they can't": challenge — "Really? They just suffer?"

4. **"现有方案的核心痛点在哪里？为什么不够好？"**
   - Must be specific, not "it's not great"

5. **"你的方案比现有方案好在哪？好多少？"**
   - Look for 10x improvement, not 10%. If marginal: flag as risk.

6. **"谁会为此付费？付多少？为什么？"**
   - If can't answer: major red flag

### After Step 1 — Problem Statement:

```
目标用户: [who]
核心问题: [what pain]
现有方案: [status quo]
痛点: [why status quo fails]
你的差异: [your edge]
```

Rate: RED (vague) / YELLOW (partially clear) / GREEN (crystal clear)
If RED: loop back. Do NOT proceed until at least YELLOW.

---

## STEP 2: First Principles (第一性原理) — "Strip to Bedrock"

**Goal:** Challenge assumptions by decomposing to fundamental truths.

### 2a. Problem Reality (问题本质)
Ask: **"用户真正买的是什么？是持续使用的工具，还是'关键时刻'的解决方案？"**

### 2b. Value Delivery (价值交付方式)
Ask: **"你产品的价值是持续交付的，还是一次性交付的？"**

### 2c. User Behavior (用户行为频率)
Ask: **"用户会多久用一次？这个频率足以支撑你的商业模式吗？"**

### 2d. Payment Motivation (付费动机)
Ask: **"用户付费的动机是什么？优化流程？离不开？还是别无选择？"**

### After Step 2:
- List **Assumptions** (unverified) vs **Facts** (verified)
- Identify **Biggest Risk** (the assumption that kills the idea if wrong)
- Rate: RED / YELLOW / GREEN

---

## STEP 3: Business Model Stress Test (商业模式压力测试) — NEW

**Goal:** Catch business model killers before writing code.

This step does NOT ask the user questions — it ANALYZES the user's previous answers and runs automated checks. Present findings as a scorecard.

### 3a. Unit Economics Check
Based on what the user said about pricing and frequency, calculate:
- **Estimated ARPU** (average revenue per user per month)
- **Estimated CAC** (customer acquisition cost) — use WebSearch to find industry benchmarks for similar products
- **LTV:CAC ratio** — must be > 3:1 to be viable. If < 3:1, flag as RED.
- **Payback period** — how many months to recoup CAC?

### 3b. Acquisition Channel Analysis
Ask: **"你打算怎么获取前 100 个用户？前 1000 个呢？"**

Then evaluate:
- Is the channel scalable?
- Is the channel affordable for a solo developer?
- Does the channel match the target user?
- Red flag: if the only answer is "organic growth" or "word of mouth" with no specific mechanism

### 3c. Moat Assessment
Analyze whether the product has any defensibility:
- **Network effects?** — Does the product get better with more users?
- **Data moat?** — Does usage create proprietary data?
- **Switching costs?** — Would users lose anything by leaving?
- **Speed moat?** — Are you just faster to market? (weakest moat)
- **No moat?** — Flag as critical risk

### 3d. Revenue Model Fit
Based on usage frequency (Step 2c), recommend the best-fit model:
- Daily use → Subscription (monthly/annual)
- Weekly use → Subscription or credits
- Monthly use → Credits or per-use
- Quarterly or less → Per-use or one-time
- Event-based → Per-event pricing

Flag mismatch if user's assumed model doesn't fit their frequency.

### After Step 3 — Business Scorecard:

| Metric | Value | Status |
|--------|-------|--------|
| ARPU | $X/mo | RED/YELLOW/GREEN |
| LTV:CAC | X:1 | RED/YELLOW/GREEN |
| Acquisition channel | [channel] | RED/YELLOW/GREEN |
| Moat | [type or none] | RED/YELLOW/GREEN |
| Revenue model fit | [model] | RED/YELLOW/GREEN |

---

## STEP 4: Risk Scanner (风险扫描) — NEW

**Goal:** Catch legal, technical, and platform risks that kill ideas post-launch.

This step is AUTOMATED — analyze the idea and flag risks. Use WebSearch to verify.

### 4a. Legal & Compliance Risks
Scan for:
- **Data ownership** — Are you scraping/using someone else's UGC? (e.g., Melb Eats + 小红书)
- **Privacy regulations** — Does this handle PII? GDPR/CCPA implications?
- **Platform ToS** — Are you building on a platform that could shut you down? (e.g., API access, scraping policies)
- **IP/Copyright** — Are you using protected content, brands, or formats?
- **Liability** — Could users get hurt? (physical games, health advice, financial advice)

### 4b. Technical Feasibility Risks
Scan for:
- **Core technology exists?** — Can the key feature actually be built with current tech?
- **Third-party dependency** — Are you dependent on APIs/platforms you don't control?
- **Cost per operation** — Would the product be profitable at scale? (e.g., LLM API costs per request)
- **Real-time requirements** — Does this need real-time infra? (GPS, websockets, etc.)
- **Solo developer feasibility** — Can one person build and maintain this?

### 4c. Platform Risk
Scan for:
- **Single platform dependency** — iOS only? One social network? One API provider?
- **App Store risk** — Could Apple/Google reject or remove this?
- **API deprecation risk** — Are you building on APIs known to change/die?

### After Step 4 — Risk Matrix:

| Risk | Severity | Likelihood | Mitigation |
|------|----------|------------|------------|
| [risk] | HIGH/MED/LOW | HIGH/MED/LOW | [action] |

Flag any HIGH severity + HIGH likelihood as **deal-breakers** that must be resolved before building.

---

## STEP 5: Multi-Role Review Panel (多角色评审团) — NEW

**Goal:** Simulate 5 expert perspectives that most solo developers/students don't have access to.

Launch an Agent to simulate all 5 roles reviewing the idea simultaneously. The agent should produce a structured panel review based on all information gathered in Steps 1-4.

### The 5 Roles:

**Role 1: CEO / Founder (创始人视角)**
- Is this a venture-scale opportunity or a lifestyle business?
- What's the 10-star version of this product?
- What would you do if you had 10x the resources?
- What would you STOP doing?
- Is the timing right? Why now, not 2 years ago or 2 years from now?

**Role 2: Senior Engineer (资深工程师视角)**
- Is this technically feasible for a solo developer?
- What's the hardest technical problem?
- What would you prototype first to validate the tech?
- Are there existing open-source projects that solve 80% of this?
- What's the ops/maintenance burden?

**Role 3: Product Designer (产品设计师视角)**
- Who is the SPECIFIC person who would use this? (not a demographic, a person)
- What's the user journey from "first heard about it" to "can't live without it"?
- Where is the "aha moment"?
- What's the activation metric? (the action that predicts retention)
- Is the value proposition clear in 5 seconds?

**Role 4: VC / Investor (投资人视角)**
- What's the TAM/SAM/SOM?
- Is this a feature, a product, or a company?
- Why would this be a bad investment?
- What metrics would you need to see before investing?
- What's the exit scenario?

**Role 5: Target User (目标用户视角)**
- Use the user persona from Step 1. Simulate their reaction.
- Would they actually switch from their current solution?
- What would make them tell a friend about this?
- What would make them stop using it?
- How much would they realistically pay?

### Panel Output Format:

For each role, output:
```
### [Role Name]
**Verdict:** EXCITED / CAUTIOUS / SKEPTICAL / HARD PASS
**Key insight:** [one sentence the creator hasn't thought of]
**Biggest concern:** [the thing that would stop this role from supporting the idea]
**Recommendation:** [one specific action]
```

### After Step 5 — Panel Summary:

| Role | Verdict | Key Concern |
|------|---------|-------------|
| CEO | EXCITED/CAUTIOUS/SKEPTICAL/HARD PASS | ... |
| Engineer | ... | ... |
| Designer | ... | ... |
| VC | ... | ... |
| Target User | ... | ... |

**Consensus:** [STRONG SUPPORT / MIXED / SKEPTICAL / CONSENSUS AGAINST]

---

## STEP 6: Occam's Razor (奥卡姆剃刀) — "Cut to Simplest"

**Goal:** Find the simplest possible version that validates the idea.

### 6a. Feature Audit
Ask: **"如果只能保留一个核心功能，你会保留哪个？"**
Then: **"这一个功能，单独拿出来，用户会用吗？会付费吗？"**

### 6b. Complexity Check
For each feature mentioned:
- "这个是 Day 1 必须有的吗？"
- "没有这个，核心价值还能传递吗？"

### 6c. Simplest Validation Path
Ask: **"不写一行代码，你能怎么验证这个想法？"**

Options to suggest:
- Landing page + waitlist (test demand)
- Manual concierge MVP (deliver value by hand)
- Fake door test (button that measures clicks)
- AI persona simulation (use Claude to simulate 20 target users)
- Survey / interview 5 target users
- Competitor review analysis
- Social media post testing engagement

### 6d. MVP Definition
Propose the Minimum Viable Product:
- Maximum 3 features
- Can be built in 1-2 weeks
- Has a clear success metric
- Has a clear kill metric (when to stop)

---

## OUTPUT: Validation Report

After all 6 steps, generate `VALIDATION-REPORT.md` in the current project directory:

```markdown
# Idea Validation Report

**Date:** [date]
**Idea:** [one-line description]
**Version:** v2.0

---

## 1. Problem Statement
- **Target user:** ...
- **Core problem:** ...
- **Current alternatives:** ...
- **Pain points:** ...
- **Differentiation:** ...

## 2. First Principles Analysis
### Assumptions (unverified)
1. ...

### Facts (verified)
1. ...

### Biggest Risk
...

## 3. Business Model Scorecard

| Metric | Value | Status |
|--------|-------|--------|
| ARPU | $X/mo | RED/YELLOW/GREEN |
| LTV:CAC | X:1 | RED/YELLOW/GREEN |
| Acquisition | [channel] | RED/YELLOW/GREEN |
| Moat | [type] | RED/YELLOW/GREEN |
| Revenue fit | [model] | RED/YELLOW/GREEN |

## 4. Risk Matrix

| Risk | Severity | Likelihood | Mitigation |
|------|----------|------------|------------|
| ... | HIGH/MED/LOW | HIGH/MED/LOW | ... |

**Deal-breakers:** [list any HIGH/HIGH risks]

## 5. Review Panel

| Role | Verdict | Key Concern |
|------|---------|-------------|
| CEO | ... | ... |
| Engineer | ... | ... |
| Designer | ... | ... |
| VC | ... | ... |
| Target User | ... | ... |

**Consensus:** STRONG SUPPORT / MIXED / SKEPTICAL / CONSENSUS AGAINST

## 6. Occam's Razor — Simplest Path

### Core Feature (keep)
...

### Cut List (remove from v1)
1. ...

### Pre-Code Validation
1. ...

## Overall Scores

| Dimension | Score | Notes |
|-----------|-------|-------|
| Problem Clarity | RED/YELLOW/GREEN | ... |
| Foundation Strength | RED/YELLOW/GREEN | ... |
| Business Viability | RED/YELLOW/GREEN | ... |
| Risk Level | RED/YELLOW/GREEN | ... |
| Expert Consensus | RED/YELLOW/GREEN | ... |
| Simplicity | RED/YELLOW/GREEN | ... |

## Final Recommendation
**GO / CONDITIONAL GO / NO-GO**

### If GO:
- MVP: ...
- Success metric: ...
- Kill metric: ...
- Timeline: ...
- First step (before coding): ...

### If CONDITIONAL GO:
- Conditions to meet first: ...
- Validation experiments: ...

### If NO-GO:
- Why: ...
- What would change this: ...
- Pivot directions: ...
```

---

## Rules

1. **Never skip steps.** Even if the idea seems obviously good or bad.
2. **One question at a time in Steps 1-2.** Use AskUserQuestion, wait for the answer.
3. **Steps 3-5 are automated analysis.** Don't ask the user — analyze and present findings.
4. **Challenge, don't validate.** Your job is to find weaknesses.
5. **Match the user's language.** Chinese in, Chinese out.
6. **Be direct, not mean.** "This assumption is risky because..." not "This is a bad idea."
7. **Always output the report.** Even if user stops halfway — generate what you have.
8. **Web research is mandatory in Steps 3-4.** Use WebSearch to verify market data, competitor info, and risk factors.
9. **The Review Panel (Step 5) should use an Agent** for parallel role simulation. Each role must produce at least one insight the creator hasn't considered.
10. **Kill metrics are as important as success metrics.** Every GO/CONDITIONAL GO must define when to STOP.