Token导航 LogoToken导航

Agent Skill · 研究检索

solo-validate(单独验证)

solo-validate 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

solo-validate 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为调用外部服务;许可证信息还不明确,第三方扫描有提醒项,按安装量在研究检索类的 73,675 个 Skill 里排第 50,488。

总安装 612周安装 26GitHub Stars 15下载 214核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:solo-validate(单独验证)
来源仓库:https://github.com/fortunto2/solo-factory
仓库路径:skills/solo-validate
安装命令:
npx skills add https://github.com/fortunto2/solo-factory --skill solo-validate
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/fortunto2/solo-factory --skill solo-validate

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

solo-validate 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中快速定位候选结果。适用于验证或校验相关的信息检索与筛选需求。可通过来源仓库和 README 文档了解具体实现方式。安装前需确认权限范围、维护状态及是否触发联网或文件操作。

建议结合实际规则集验证其判断逻辑的准确性。

来源仓库内路径:skills/solo-validate

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/fortunto2/solo-factory --skill solo-validate;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要调用外部服务,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

solo-validate 怎么安装?

在终端执行 npx skills add https://github.com/fortunto2/solo-factory --skill solo-validate。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

solo-validate 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

solo-validate 需要什么权限?

权限级别是调用外部服务。该 Skill 可能调用第三方服务、云服务或外部模型 API,使用前需要确认账号、额度、数据发送范围和服务条款。

solo-validate 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

solo-validate 用的人多吗?

公开数据是累计安装 612 次,近一周安装 26 次,下载 214 次,GitHub 15 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

solo-validate 安全吗?

第三方扫描有提醒项,说明存在需要人工确认的行为。安装前请打开源码看清它读了什么、联网到哪里。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方扫描存在提醒项或未通过项,需要人工逐条确认。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
solo-validate

单独验证 · 本页

61215调用外部服务未明确有提醒

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

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

MCP Tools (use if available)

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.

Steps

  1. Parse the idea from $ARGUMENTS. If empty, ask the user what idea they want to validate.
  2. 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).

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

  1. 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): 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.

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

  1. S.E.E.D. niche check (quick, before deep analysis): Score the idea on four dimensions: Kill flags (stop immediately if any): If any kill flag triggers → recommend KILL with explanation. Don't proceed to STREAM.

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

  1. 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: 6b. Dead startup search: Search for startups that tried something similar and failed or pivoted: 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: 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.

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

  1. 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: Scoring rules:

- 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? - 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)

  1. Beachhead Segment (first target market): From research personas (if available) or idea description, define the beachhead: This feeds into PRD ICP section and /launch GTM strategy.

- Who exactly? — narrow segment, not "everyone" (e.g., "freelance designers earning $3-8K/mo", not "freelancers") - Why them first? — accessible, high pain, willing to pay, can reach via specific channel - Channel to reach them? — one specific channel (subreddit, community, newsletter) - What adjacent segment next? — after beachhead is won, where to expand

  1. Pricing Model (2-3 options with reasoning): Based on competitor pricing (from research.md) and manifesto principles (subscription fatigue is real — prefer one-time purchase or honest transparent pricing when possible): Model Price Reasoning Manifest Alignment One-time $X No running costs → no recurring charge Best fit (no lock-in) Freemium Free / $X/mo Server costs justify subscription OK if honest Usage-based $X per Y Pay for what you use Good (transparent) Rules from manifesto (templates/principles/manifest.md): Pick the recommended model and explain why. Include in PRD.

- If it doesn't cost to run, it should be free - One-time purchase over subscription when possible - Build the opposite of lock-in: tools users own, data they control - No dark patterns, no artificial limitations to force upgrades

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

  1. 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)
  • Beachhead segment — who first, why them, how to reach
  • Pricing model — recommended option with manifest alignment check
  • Tech stack with key packages
  • Architecture principles (SOLID, DRY, KISS, schemas-first)
  • Evidence-first — numbers/claims have source URLs (from research.md if available)
  1. 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)

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.

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)

Common Issues

S.E.E.D. kill flag triggered

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.

No research.md found

Cause: Skipped /research step. Fix: Skill asks if you want to research first. For stronger PRDs, run /research <idea> before /validate.

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.

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

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.

平台分布

Codex

34.4%
按下载量换算74

Claude

30.72%
按下载量换算66

Cursor

18.88%
按下载量换算40

Gemini CLI

8.65%
按下载量换算19

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

可疑

权限和风险

调用外部服务

该 Skill 可能调用第三方服务、云服务或外部模型 API,使用前需要确认账号、额度、数据发送范围和服务条款。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在提醒或未通过项,安装前请自行复核。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills