solo-validate

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/validate

Validate a startup idea end-to-end: search KB, run Manifest alignment, S.E.E.D. niche check, Devil's Advocate inversion, STREAM 6-layer analysis, pick stack, generate PRD.

Philosophy: Validation should be honest, not optimistic. Better to kill a bad idea in 5 minutes than waste 3 months building it. The goal is truth, not encouragement.

全方位验证创业想法：搜索知识库（KB）、进行Manifest对齐、S.E.E.D.利基检查、魔鬼代言人反向思考、STREAM六层分析、选择技术栈、生成PRD。

核心理念： 验证应秉持诚实态度，而非盲目乐观。与其花费3个月时间开发一个糟糕的想法，不如在5分钟内就否决它。目标是追求真相，而非给予鼓励。

MCP Tools (use if available)

MCP工具（如有可用）

If MCP tools are available, prefer them over CLI:

```
kb_search(query, n_results)
```
— search knowledge base for related docs
```
project_info()
```
— list active projects with stacks
```
web_search(query)
```
— search for dead startups, competitor failures

If MCP tools are not available, fall back to Grep/Glob/WebSearch.

如果MCP工具可用，优先使用它们而非CLI：

```
kb_search(query, n_results)
```
— 搜索知识库中的相关文档
```
project_info()
```
— 列出带有技术栈的活跃项目
```
web_search(query)
```
— 搜索已倒闭的创业公司、竞争对手的失败案例

如果MCP工具不可用，则退而使用Grep/Glob/WebSearch。

Steps

步骤

Parse the idea from
```
$ARGUMENTS
```
. If empty, ask the user what idea they want to validate.
Search for related knowledge: If MCP
```
kb_search
```
tool is available, use it directly:
- ```
kb_search(query="<idea keywords>", n_results=5)
```
  Otherwise search locally:
- Grep for idea keywords in
```
.md
```
  files across the project and knowledge base Summarize any related documents found (existing ideas, frameworks, opportunities).
Deep research (optional): Check if
```
research.md
```
exists for this idea (look in
```
docs/
```
or the current working directory).
- If it exists: read it and use findings to inform STREAM analysis and PRD filling (competitors, pain points, market size).
- If it does not exist: ask the user if they want to run deep research first. If yes, tell them to run
```
/research <idea>
```
  and come back. If no, continue without it.
Manifest Alignment Check (with teeth):
Consult
```
references/manifest-checklist.md
```
(bundled with this skill) for the full checklist of 9 principles and 6 red flags. Check the idea against EACH one. This is not a formality — a manifest violation is a soft kill flag.
For each principle, assess: comply or violate? If violating — cite the specific principle.

Key principles (see checklist for details):
1. Privacy-first / offline-first
2. One pain -> one feature -> launch
3. AI as foundation, not feature
4. Speed over perfection (MVP in days)
5. Antifragile architecture
6. Money without overheating
7. Against exploitation
8. Subscription fatigue
9. Creators, not robots
Scoring: 0 violations = perfect, 1-2 = caution, 3+ = strong KILL signal.

Be honest. If the idea conflicts with principles, SAY SO. Don't rationalize alignment.
S.E.E.D. niche check (quick, before deep analysis):

Score the idea on four dimensions:
- S — Searchability: Can you rank? Forums/Reddit in top-10, few fresh giants, no video blocks?
- E — Evidence: Real pain with real quotes/URLs? Or hypothetical?
- E — Ease: MVP in 1-2 days on existing stack? No heavy dependencies?
- D — Demand: Long-tail keywords exist? Clear monetization path?
Kill flags (stop immediately if any):
- Top-10 SERP dominated by media giants or encyclopedias
- Fresh competing content (<60 days old) already covers it well
- No evidence of real user pain (only founder's hypothesis)
- MVP needs >1 week even on best-fit stack
If any kill flag triggers → recommend KILL with explanation. Don't proceed to STREAM.

Devil's Advocate (Inversion):

"Flip the question: how would you guarantee failure?" — STREAM Layer 3 (Inversion)

This step is mandatory — before scoring positively, actively try to kill the idea. The goal is to find reasons NOT to build it.

6a. Inversion — 5 ways this fails: List 5 specific, concrete ways this idea could fail. Not generic risks ("competition") but specific scenarios with evidence:

What specific competitor could crush this? (name, funding, strategy)
What user behavior makes this unviable? (churn data, willingness to pay)
What regulatory/legal event kills this? (specific laws, precedents)
What technical limitation blocks this? (latency, cost, accuracy)
What market dynamic makes the "opportunity" a mirage?

6b. Dead startup search: Search for startups that tried something similar and failed or pivoted:

WebSearch:

"<idea category>" startup failed OR pivoted OR shut down

WebSearch:

"<competitor>" pivot OR layoffs OR shutdown

If any found: what killed them? Does the same risk apply here?

6c. Unit economics stress test (if research.md exists): Recalculate unit economics with PESSIMISTIC assumptions:

Metric	Optimistic	Realistic	Pessimistic
Monthly churn	10%	30-40% (industry data)	50%+ (first year)
Average lifetime	10 months	2.5-3 months	1.5 months
LTV	(price × 10)	(price × 2.5)	(price × 1.5)
CAC	<$20	$30-50	$50-80
LTV:CAC	>3:1	~1:1	<1:1 (UNPROFITABLE)

If pessimistic LTV:CAC < 1 → flag as critical risk.

6d. "Empty market" test: If the analysis found an "empty" market segment or pricing gap, ask:

Why is it empty? Is it opportunity or graveyard?
Search for companies that tried this exact positioning and failed
Is the segment empty because demand doesn't exist at that price point?

6e. Manifest conflict honesty: Re-check findings from step 4. For each manifest violation found, state the conflict clearly: "This requires X, which violates principle Y because Z." Do NOT rationalize conflicts away. The user decides whether to proceed — not the skill.

STREAM analysis: Walk the idea through all 6 layers.
Consult
```
references/stream-layers.md
```
(bundled with this skill) for the complete 6-layer framework with questions per layer.
For EACH layer, provide BOTH positive and negative assessment. Use the actual framework questions:
- Layer 1 (Scope): Map!=Territory, Simplicity, Boundaries — what assumptions are unproven?
- Layer 2 (Time): Entropy, Lindy — will this exist in 5 years?
- Layer 3 (Route): Inversion (use Devil's Advocate findings), Second-Order Effects — effects of effects?
- Layer 4 (Stakes): Asymmetry, Antifragility — real risk/reward with pessimistic numbers
- Layer 5 (Audience): Reputation, Network — deposit or withdrawal?
- Layer 6 (Meta): Mortality, Balance — worth finite time? Aligns with mission?
Scoring rules:
- Each layer scored 1-10
- If Devil's Advocate found critical issues, the affected layer score MUST be reduced
- If Manifest alignment has violations, Layer 6 (Meta) score MUST be reduced
- Final score = weighted average (Meta and Stakes weighted 1.5x)
Stack selection: Auto-detect from research data, then confirm or ask.
Auto-detection rules (from
```
research.md
```
```
product_type
```
field or idea keywords):
- ```
product_type: ios
```
  →
```
ios-swift
```
- ```
product_type: android
```
  →
```
kotlin-android
```
- ```
product_type: web
```
  + mentions AI/ML →
```
nextjs-supabase
```
  (or
```
nextjs-ai-agents
```
  )
- ```
product_type: web
```
  + landing/static →
```
astro-static
```
- ```
product_type: web
```
  + content site + needs SSR for some pages (CDN data, transcripts, dynamic) →
```
astro-hybrid
```
- ```
product_type: web
```
  (default) →
```
nextjs-supabase
```
- ```
product_type: api
```
  →
```
python-api
```
- ```
product_type: cli
```
  + Python keywords →
```
python-ml
```
- ```
product_type: cli
```
  + JS/TS keywords →
```
nextjs-supabase
```
  (monorepo)
- Edge/serverless keywords →
```
cloudflare-workers
```
If auto-detected with high confidence, state the choice and proceed. If ambiguous (e.g., could be web or mobile), ask via AskUserQuestion with the top 2-3 options. If MCP
```
project_info
```
is available, show user's existing stacks as reference.
Generate PRD: Create a PRD document at
```
docs/prd.md
```
in the current project directory. Use a kebab-case project name derived from the idea.
PRD must pass Definition of Done:
- Problem statement ≥ 30 words (who suffers, when, why now)
- ICP + JTBD — target segment + 2-3 jobs-to-be-done
- 3-5 features, each with measurable acceptance criteria
- 3-5 KPIs with units (daily/weekly) and target values
- Kill/Iterate/Scale thresholds for each KPI
- 3-5 risks with mitigation plans
- Honest Assessment section (from Devil's Advocate step)
- Unit economics: optimistic AND pessimistic (both columns)
- Dead startup precedents (who tried this and failed?)
- Manifest conflicts (explicit list of principle violations)
- Tech stack with key packages
- Architecture principles (SOLID, DRY, KISS, schemas-first)
- Evidence-first — numbers/claims have source URLs (from research.md if available)
Output summary:
- Idea name and one-liner
- S.E.E.D. score (S/E/E/D each rated low/medium/high)
- Manifest alignment (X/9 principles met, list violations)
- Two scores:
  - Optimistic score (0-10): best-case assumptions
  - Realistic score (0-10): pessimistic unit economics, real churn, funded competitors
- Devil's Advocate top finding (the single strongest reason NOT to build)
- Key risk and key advantage
- Path to generated PRD
- "If I'm wrong about..." — state the single assumption that, if wrong, changes the verdict
- Recommended next action (one of):
  - ```
  /research <idea>
```
  — if evidence is weak, get data first
- ```
/scaffold <name> <stack>
```
    — if realistic score ≥ 7, build it
  - Fake-Door Test — if realistic score 5-7, spend $20 on a landing stub before coding
  - KILL — if realistic score < 5 or kill flags triggered
  - PIVOT — if the idea has merit but current angle fails (suggest specific pivot)

解析创业想法 从
```
$ARGUMENTS
```
中解析创业想法。如果为空，请询问用户想要验证的具体想法。
搜索相关知识： 如果MCP
```
kb_search
```
工具可用，直接使用：

kb_search(query="<想法关键词>", n_results=5)

否则在本地搜索：

在项目和知识库的
```
.md
```
文件中搜索想法关键词总结找到的所有相关文档（现有想法、框架、机会）。

深度研究（可选）： 检查该想法是否存在对应的
```
research.md
```
文件（查看
```
docs/
```
目录或当前工作目录）。

如果存在：读取该文件，并将其中的发现（竞争对手、痛点、市场规模）用于指导STREAM分析和PRD内容填充。
如果不存在：询问用户是否想要先进行深度研究。如果是，请告知用户运行
```
/research <想法>
```
后再返回。如果否，则继续后续步骤。

Manifest对齐检查（严格执行）： 查阅随本技能附带的
```
references/manifest-checklist.md
```
，获取包含9项原则和6个红色预警的完整清单。对照每一项原则检查想法。这不是形式主义——违反Manifest原则是一个软否决信号。

针对每一项原则，评估：符合还是违反？如果违反——引用具体的原则内容。

核心原则（详情请查看清单）：

隐私优先/离线优先
一个痛点对应一个功能再启动
AI作为基础，而非附加功能
速度优先于完美（数天内完成MVP）
反脆弱架构
合理盈利，避免过度扩张
反剥削
避免订阅疲劳
聚焦创作者，而非机器人

评分规则： 0项违反=完美，1-2项=需谨慎，3项及以上=强烈否决信号。

务必诚实。 如果想法与原则冲突，请明确说明。不要强行合理化对齐关系。

S.E.E.D.利基检查（快速检查，在深度分析前进行）：

从四个维度对想法评分：

S — 可搜索性： 能否获得排名？论坛/Reddit排名前10，没有新的巨头玩家，没有视频内容阻碍？
E — 证据支持： 有真实的痛点及真实的用户引用/URL？还是仅为假设？
E — 实现难度： 基于现有技术栈能否在1-2天内完成MVP？没有重型依赖？
D — 市场需求： 存在长尾关键词？有清晰的变现路径？

否决触发条件（如果满足任意一项，立即停止）：

搜索结果前10位被媒体巨头或百科全书占据
发布时间少于60天的竞品内容已充分覆盖该领域
没有真实用户痛点的证据（仅为创始人的假设）
即使使用最适配的技术栈，MVP开发也需要超过1周时间

如果触发任意否决条件→建议否决并说明原因。无需继续进行STREAM分析。

魔鬼代言人（反向思考）：

“反向提问：如何确保这个想法一定会失败？”——STREAM第三层（反向思考）

此步骤为必填项——在给出正面评分前，主动尝试否决该想法。目标是找到不应该开发它的理由。

6a. 反向思考——5种失败路径： 列出5种具体、明确的失败场景。不要泛泛而谈风险（如“竞争”），而是要有证据支撑的具体场景：

哪个具体的竞争对手可能击败这个想法？（名称、资金、策略）
哪种用户行为会导致这个想法不可行？（流失数据、付费意愿）
哪种监管/法律事件会否决这个想法？（具体法律、先例）
哪种技术限制会阻碍这个想法？（延迟、成本、准确性）
哪种市场动态让这个“机会”只是海市蜃楼？

6b. 倒闭创业公司搜索： 搜索尝试过类似想法但失败或转型的创业公司：

Web搜索：

"<想法类别>" startup failed OR pivoted OR shut down

Web搜索：

"<竞争对手>" pivot OR layoffs OR shutdown

如果找到相关案例：是什么导致它们失败？同样的风险是否适用于当前想法？

6c. 单位经济压力测试（如果存在research.md）： 基于悲观假设重新计算单位经济效益：

指标	乐观假设	现实假设	悲观假设
月度流失率	10%	30-40%（行业数据）	50%+（第一年）
平均生命周期	10个月	2.5-3个月	1.5个月
LTV	(价格 × 10)	(价格 × 2.5)	(价格 × 1.5)
CAC	<$20	$30-50	$50-80
LTV:CAC	>3:1	~1:1	<1:1（无盈利可能）

如果悲观假设下的LTV:CAC < 1→标记为关键风险。

6d. “空白市场”测试： 如果分析发现“空白”的市场细分或定价缺口，请询问：

为什么这个市场是空白的？ 是机会还是坟墓？
搜索尝试过该精准定位但失败的公司
该细分市场空白是因为该价格点没有需求吗？

6e. 诚实说明Manifest冲突： 重新检查步骤4中的发现。对于每一项发现的Manifest原则违反，明确说明冲突：“这需要X，违反了原则Y，原因是Z。” 不要试图合理化冲突。由用户决定是否继续——而非本技能。

STREAM分析： 将想法逐一通过所有6层分析。

查阅随本技能附带的

references/stream-layers.md

，获取包含每层问题的完整6层框架。

针对每一层，同时提供正面和负面评估。使用框架中的实际问题：

第一层（范围）： 地图≠领土、简洁性、边界——哪些假设未被验证？
第二层（时间）： 熵、林迪效应——5年后这个想法还会存在吗？
第三层（路径）： 反向思考（使用魔鬼代言人步骤的发现）、二阶效应——效应的效应是什么？
第四层（风险）： 不对称性、反脆弱性——基于悲观数据的真实风险/回报
第五层（受众）： 声誉、网络效应——是积累还是消耗？
第六层（元层）： 局限性、平衡性——值得投入有限的时间吗？与使命对齐吗？

评分规则：

每一层评分1-10分
如果魔鬼代言人步骤发现关键问题，相关层的评分必须降低
如果Manifest对齐存在违反，第六层（元层）的评分必须降低
最终得分=加权平均分（元层和风险层权重为1.5倍）

技术栈选择： 从研究数据中自动检测，然后确认或询问用户。

自动检测规则（来自

research.md

的

product_type

字段或想法关键词）：

```
product_type: ios
```
→
```
ios-swift
```
```
product_type: android
```
→
```
kotlin-android
```

product_type: web

+ 提及AI/ML →

nextjs-supabase

（或

nextjs-ai-agents

）

```
product_type: web
```
+ 着陆页/静态站点 →
```
astro-static
```
```
product_type: web
```
+ 内容站点 + 部分页面需要SSR（CDN数据、 transcripts、动态内容） →
```
astro-hybrid
```
```
product_type: web
```
（默认） →
```
nextjs-supabase
```
```
product_type: api
```
→
```
python-api
```
```
product_type: cli
```
+ Python关键词 →
```
python-ml
```
```
product_type: cli
```
+ JS/TS关键词 →
```
nextjs-supabase
```
（单体仓库）
边缘/无服务器关键词 →
```
cloudflare-workers
```

如果自动检测的置信度高，说明选择结果并继续。如果存在歧义（例如：可能是Web或移动端），通过AskUserQuestion询问用户，提供前2-3个选项。如果MCP

project_info

可用，展示用户现有的技术栈作为参考。

生成PRD： 在当前项目目录的
```
docs/prd.md
```
位置创建PRD文档。使用从想法衍生的短横线命名法（kebab-case）项目名称。

PRD必须满足完成定义：

问题陈述≥30字（谁在遭受痛苦，何时，为什么是现在）
ICP + JTBD — 目标用户群体 + 2-3个用户待办事项
3-5个功能，每个功能都有可衡量的验收标准
3-5个KPI，包含单位（日/周）和目标值
每个KPI对应的否决/迭代/扩展阈值
3-5个风险及缓解方案
诚实评估部分（来自魔鬼代言人步骤的内容）
单位经济效益：乐观和悲观两种假设（两列数据）
倒闭创业公司先例（谁尝试过类似想法并失败？）
Manifest冲突（明确列出违反的原则）
技术栈及核心包
架构原则（SOLID、DRY、KISS、 schema-first）
基于证据——数据/声明带有来源URL（如有可用，来自research.md）

输出总结：

想法名称和一句话描述
S.E.E.D.评分（S/E/E/D分别评为低/中/高）
Manifest对齐情况（符合9项原则中的X项，列出违反项）
两个评分：
- 乐观评分（0-10）：基于最佳假设
- 现实评分（0-10）：基于悲观单位经济效益、真实流失率、有资金支持的竞争对手
魔鬼代言人步骤的核心发现（不应该开发该想法的最有力理由）
主要风险和主要优势
生成的PRD的路径
“如果我判断错误的点是...” — 说明单个假设，若该假设错误，会改变最终结论
推荐下一步行动（以下之一）：
- ```
/research <想法>
```
  — 如果证据不足，先获取数据
- ```
/scaffold <名称> <技术栈>
```
  — 如果现实评分≥7，开始开发
- 假门测试 — 如果现实评分5-7，在编码前花费20美元制作一个着陆页原型
- 否决（KILL） — 如果现实评分<5或触发了否决条件
- 转型（PIVOT） — 如果想法有价值但当前方向不可行（建议具体的转型方向）

Important

重要提示

Do NOT skip the Devil's Advocate step (step 6). It is mandatory.
Do NOT skip reading
```
references/manifest-checklist.md
```
and
```
references/stream-layers.md
```
(bundled with this skill). They contain the actual checklists.
Quality and honesty are more important than speed. Take your time on steps 4, 6, and 7.
A KILL recommendation is a valid and valuable outcome. It saves months of wasted effort.

请勿跳过魔鬼代言人步骤（步骤6）。此步骤为必填项。
请勿跳过阅读
```
references/manifest-checklist.md
```
和
```
references/stream-layers.md
```
（随本技能附带）。它们包含实际的检查清单。
质量和诚实比速度更重要。在步骤4、6、7上多花时间。
否决（KILL）建议是一个有效且有价值的结果。它能节省数月的无用功。

When to use

使用场景

Before building anything non-trivial
After
```
/research
```
or
```
/swarm
```
to score and generate PRD
When deciding between multiple ideas (run on each, compare realistic scores)
When friends ask for feedback on their startup (be honest, not nice)

在开发任何非 trivial 的产品之前
在
```
/research
```
或
```
/swarm
```
之后，用于评分和生成PRD
在多个想法之间做决策时（对每个想法运行此命令，比较现实评分）
朋友请求对他们的创业想法提供反馈时（保持诚实，而非客套）

Common Issues

常见问题

S.E.E.D. kill flag triggered

S.E.E.D.否决条件被触发

Cause: Idea fails basic niche viability (SERP dominated, no evidence, MVP too complex). Fix: This is by design — kill flags save time. Consider pivoting the idea or running

/research

for deeper evidence.

原因： 想法未通过基本的利基可行性检查（搜索结果被垄断、无证据支持、MVP开发过于复杂）。 解决方法： 这是设计的一部分——否决条件能节省时间。考虑调整想法方向或运行

/research

获取更深入的证据。

No research.md found

未找到research.md文件

Cause: Skipped

/research

step. Fix: Skill asks if you want to research first. For stronger PRDs, run

/research <idea>

before

/validate

原因： 跳过了

/research

步骤。 解决方法： 技能会询问是否要先进行研究。为了生成更优质的PRD，请在运行

/validate

前先运行

/research <想法>

。

Stack auto-detection wrong

技术栈自动检测错误

Cause: Ambiguous product type (could be web or mobile). Fix: Skill asks via AskUserQuestion when ambiguous. Specify product type explicitly in the idea description.

原因： 产品类型存在歧义（可能是Web或移动端）。 解决方法： 当存在歧义时，技能会通过AskUserQuestion询问用户。在想法描述中明确指定产品类型。

Score seems too high

评分似乎过高

Cause: Confirmation bias — you found evidence FOR and stopped looking. Fix: Devil's Advocate step is now mandatory. If you skipped it, the score is invalid. Re-run with full inversion.

原因： 确认偏差——只找到了支持想法的证据就停止搜索。 解决方法： 魔鬼代言人步骤现在是必填项。如果跳过了该步骤，评分无效。请重新运行完整的反向思考步骤。

Manifest conflicts rationalized away

Manifest冲突被合理化

Cause: The idea is exciting but conflicts with principles. Fix: State conflicts explicitly. "This violates X because Y" is more useful than silence. The user decides whether to proceed — not the skill.

原因： 想法很吸引人但违反了原则。 解决方法： 明确说明冲突。“这违反了X，原因是Y”比沉默更有价值。由用户决定是否继续——而非本技能。