idea-validator

Idea Validator

以诚实的反馈，批判性地评估创意的市场可行性、技术可行性，并提出可执行的改进建议。

适用场景

当用户要求以下事项时，触发此技能：

• 评估、验证或打分某个应用创意或创业构想
• 诚实地判断某个创意是否值得开发
• 调查某个领域现有的竞争对手，包括商业工具／服务和开源替代方案
• 将模糊的构想整理为结构化的验证报告

说明

按以下顺序执行步骤：设置 → 阶段 1：澄清 → 阶段 2：技术背景 → 阶段 3：竞争格局 → 阶段 4：评估 → 阶段 5：改进 → 提交并推送 → 最终报告。不得跳过或调整步骤顺序，但边缘情况表中要求停止的情况除外。设置步骤 4 后停止时，仍须针对目前已写入的文件执行提交并推送，然后生成最终报告。如果 ideas 根目录是某个 ideas 仓库的根目录，还要在每次更新文件后执行 README 维护（检测规则见该部分）。

全文使用以下术语：

• Ideas 根目录 — 包含所有创意文件夹的目录（在设置步骤 2 中确定）。
• 项目文件夹 — <ideas 根目录>/YYYY_MM_DD_<short_snake_case_name>/，用于存放此创意的 idea.md 和 validate.md。
• 状态 — 本次运行结果，可选 COMPLETE、PARTIAL 或 BLOCKED，按最终报告中的规则确定。

编辑前同步仓库（必须执行）

在 ideas 根目录中执行此操作，且必须先于设置步骤 3 创建或修改任何文件。如果 ideas 根目录不在 git 仓库中（git -C <ideas root> rev-parse --git-dir 执行失败），则跳过此步骤，并在最终报告中记录跳过原因。

如果 git status --porcelain 没有输出，直接同步：

cd "<ideas root>"
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin
git pull --rebase origin "$branch"

如果有任何输出，先暂存更改，再同步，最后恢复更改：

git stash push -u -m "pre-sync"
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin && git pull --rebase origin "$branch"
git stash pop

如果缺少 origin、拉取失败，或变基或暂存恢复时发生冲突，请停止并询问用户，然后再继续。

设置

1. 获取创意。 使用 $ARGUMENTS 中的创意。如果 $ARGUMENTS 为空，请用户描述构想。如果用户未提供描述，则以状态 BLOCKED 停止。

2. 确定 ideas 根目录（与工具无关；每个环境询问一次）。按以下优先顺序选取第一个适用项：

   1. 若环境变量 IDEAS_ROOT 已设置，则使用该值。
   2. 若文件 ~/.config/ideas-root.txt 存在，则使用其中的路径。
   3. 若旧路径 ~/.openclaw/ideas-root.txt 存在，则使用其中的路径。将该值复制到 ~/.config/ideas-root.txt。
   4. 否则，询问用户生成的文档应存放在哪里。建议使用 ~/workspace/ideas。将用户的回答保存到 ~/.config/ideas-root.txt。

   只有在用户要求更改位置时才再次询问。

3. 创建项目文件夹，位置为 ideas 根目录下。如果同一日期和名称的文件夹已存在，则复用该文件夹并更新其中的文件，不要再创建一个。

4. 创建 idea.md，写入创意及相关澄清信息。

5. 创建 validate.md，写入评估和建议。

6. 在回复中回显项目文件夹的绝对路径，供后续技能使用。

如果无法创建或写入 ideas 根目录，则以状态 BLOCKED 停止，并指出该路径。

创建任一文件，或更新阶段 1–5 中指定的章节时，请阅读 references/file-templates.md。该文件规定标题名称和顺序；各阶段说明规定具体内容。

阶段 1：澄清创意

使用提问工具（AskUserQuestion 或同类工具）向用户提出以下问题。如果没有提问工具，则在普通聊天中提问。若设置步骤 1 中对创意的描述已回答某个问题，则跳过该问题。

• 这要解决什么问题？哪些人受到这个问题的困扰？
• 你的目标用户是谁？请具体说明。
• 这与现有解决方案有何不同？
• 6–12 个月后，怎样才算成功？

根据用户的回答更新 idea.md。对于用户拒绝回答或无法回答的问题，填写 unknown，并在最终报告的“不确定事项”中列出。目标用户问题除外：请参阅“边缘情况”。

第 2 阶段：收集技术背景

使用与第 1 阶段相同的工具和跳过规则询问用户：

• 首选技术栈？
• 时间安排和团队规模？
• 预算情况（自筹／已获融资／副业项目）？
• 现有资产（代码、设计、研究）？

更新 idea.md 中的 Technical Context 部分。每个未回答的项目都填写 unknown。

第 3 阶段：竞品格局调研

评估创意之前，进行实时网络调研，了解该领域现有的解决方案。对于市场、定价、发展情况、竞品或开源相关的说法，不要依赖记忆或训练数据——必须进行网络搜索，确保报告反映最新信息。

使用可用的网络搜索工具（WebSearch、web_search 或同类工具）运行至少 4 个不同的查询，覆盖以下方面：

商业工具／服务——SaaS 产品、移动应用、企业平台、付费 API、代理机构、市场，以及其他能解决相同或相近问题的商业产品。搜索核心问题描述，并搭配 "app"、"tool"、"platform"、"SaaS"、"startup"、"pricing"、"alternative" 等关键词，以及面向特定受众的词语。

开源解决方案——GitHub／GitLab 仓库、可自托管工具、软件包、框架、模板，以及能解决相同问题或提供有力基础的开源替代方案。搜索时使用 "open source"、"GitHub"、"self-hosted"、"OSS"、"alternative"、"library" 等词语，以及相关的软件包注册表名称。如果没有找到可信的开源方案，记录尝试过的查询，并说明没有发现维护活跃的开源基础方案。

相邻解决方案——解决相关问题或以不同方式服务同一受众的产品或项目。这些方案可以揭示用户目前在没有拟议解决方案时如何应对。

失败尝试——曾尝试过类似方案但后来停滞、关闭或被弃用的初创公司、产品或开源项目。搜索 "[concept] startup failed"、"[concept] post-mortem"、"[concept] abandoned GitHub"，或查看产品目录。

对于找到的每个竞品或开源项目，记录：

• 名称和 URL
• 类型（商业、开源、混合、相邻、失败／弃用）
• 功能（用一句话说明）
• 定价或许可证（免费、免费增值、付费、企业版；如有，则注明开源许可证）
• 发展情况或健康度（评价、评分、用户、融资、GitHub 星标数／复刻数、近期提交、未解决的问题、社区活跃度）
• 关键弱点或缺口，即用户的创意可以利用之处
• 复用／在其基础上构建的潜力（针对开源方案：复刻、插件、库依赖、贡献途径，或不适合复用）

目标是找到 3 到 8 个竞品，并至少进行一次商业方案搜索和一次开源方案搜索。如果找到的可信结果少于 3 个，在 validate.md 中将此记录为一个信号：市场较为小众、搜索词需要调整，或创意采用了不常见的表述方式。

如果现有开源解决方案已能实现创意中的重要部分，在建议从头构建之前，应比较许可证的适配性、维护状况、架构、可扩展性、部署负担和社区情况。判断用户应该在其基础上构建、复刻它、为其作贡献，还是明确做出差异化。

在 validate.md 中新增 ## Competitive Landscape 部分，包含：

1. 商业和开源竞品汇总表
2. 开源替代方案与复用潜力分析
3. “市场空白”分析——当前市场缺少什么
4. 诚实评估：结合现有方案，用户的差异化究竟是真实存在还是想象出来的？
5. 存在开源基础方案时，给出从头构建还是基于现有方案构建的建议

如果无法使用网络搜索，或搜索受到阻碍，请暂停并询问用户是否愿意在不进行网络搜索的情况下继续。如果用户回答愿意，将 Competitive Landscape 部分标记为 Not verified by live search，并将状态设为 PARTIAL。如果用户回答不愿意，将状态设为 BLOCKED 并停止。绝不能悄悄用常识替代实时调研。

阶段 4：关键评估

诚实地进行评估，并更新 validate.md：

市场分析：

• 类似的商业产品和开源解决方案
• 市场规模和竞争情况
• 独特的差异化优势

需求评估：

• 用户愿意付费的证据
• 问题的紧迫程度

可行性：

• 能否在 2-4 周内交付 MVP？
• 最小可行功能
• 是否存在复杂依赖？
• 能否复用、分叉、扩展现有 OSS 项目，或将其作为参考，而不是从头开始？

变现：

• 是否有明确的收入路径？
• 用户是否愿意付费？

技术风险：

• 在既定限制下能否实现？
• 主要技术风险是什么？
• 基于开源项目开发时的许可证、维护和依赖风险是什么？

重复开发 / 复用风险：

• 这个想法是否基本上是在重新实现现有的商业或 OSS 解决方案？
• 是否有可信的基于现有项目开发、插件、分叉或贡献路径，可以降低风险？

评分（1-10）： 创造力、可行性、市场影响、技术执行。每项评分都要附上一句理由。

结论。 采用第一个符合条件的规则：

1. Skip it — 阶段 3 发现了近乎相同的产品，且用户未指出真正的差异化优势；或存在团队和预算无法解决的硬性障碍。
2. Maybe — 符合以下任一条件：存在尚未解决的重大技术风险；有维护活跃、覆盖该想法大部分内容的 OSS 项目，但尚未选定基于该项目开发的路径；没有证据证明存在需求或付费意愿；或可行性评分低于 6。
3. Build it — 以上情况均不符合。

写出结论及其所依据的规则，并用 2-3 句话说明理由。

阶段 5：改进

更新 validate.md，包含：

• 如何加强：提出具体、可执行的改进措施，每项都要对应阶段 4 中的一项顾虑
• 增强版：重新设计并优化后的概念
• 实施路线图：分阶段推进的方法（如适用）

边界情况

• 目标用户不明确：如果想法过于宽泛（例如“面向所有人的应用”），请在阶段 1 中提出异议：让用户指出一个目前正面临这一痛点的具体人物。在确定用户群体之前，不要开始阶段 3。如果用户仍未指出任何人，则以状态 PARTIAL 停止，并保存 idea.md。
• 想法已存在重复产品：如果阶段 3 发现了近乎相同的产品，请立即提供证据（URL、功能对比），并询问用户是否想继续。只有用户指出真正的差异化优势后才能继续。如果用户停止，则在阶段 4 使用结论 Skip it（规则 1），跳过阶段 5，并将状态设为 PARTIAL。
• 已有开源解决方案：如果阶段 3 发现有维护活跃的 OSS 项目已覆盖该想法的大部分内容，应将“从头开始开发”视为风险更高的建议。在给出 Build it 结论前，决定是基于该项目开发、分叉、贡献，还是与其形成差异化。
• 技术可行性不明确：如果想法需要未经验证的技术、未公开的 API，或团队无法实现的能力，请在阶段 4 将其标记为硬性障碍并降低可行性评分。根据结论规则，这种情况下不能给出 Build it。
• 无法进行网页搜索：遵循阶段 3 的最后一段。
• Ideas 根目录不是 git 仓库：写入文件，跳过 Repo Sync 和 Commit and Push，并将状态设为 PARTIAL。除非用户提出要求，否则不要运行 git init。
• 重试一次后推送仍然失败：停止并询问用户（Commit and Push）。报告提交哈希，并将状态设为 PARTIAL。

步骤完成报告

完成从 Setup 到阶段 5 的每个步骤后，按以下格式输出状态报告：

◆ [Step Name] ([step N of 6] — [idea name])
··································································
  [Check 1]:          √ pass
  [Check 2]:          × fail — [reason]
  ____________________________
  Result:             PASS | FAIL | PARTIAL

通过使用 √，失败使用 ×，简短补充说明使用 —。各阶段的检查块位于 references/step-completion-reports.md；请读取与刚完成步骤对应的检查块。

语气

• 坦率直言：在 Concerns 中直截了当地指出每个致命缺陷
• 建设性：针对每条批评都给出建议
• 具体：用竞争对手、数字或引用的用户回答为每项结论提供依据
• 全面：既列出优势，也列出弱点

README 维护（在 ideas 仓库中运行时）

当 ideas 根目录中包含 README.md 和至少两个 YYYY_MM_DD_* idea 文件夹时，运行此步骤。每次更新 idea.md 或 validate.md 后，在该 README.md 中插入或更新 ## Ideas index 表格，每个 idea 占一行：

• 链接到该 idea 的 idea.md
• PRD/任务状态：如果文件夹中存在 prd.md，则为 PRD；如果存在 tasks.md，则为 tasks；否则为 none
• verdict，链接到该 idea 的 validate.md

提交并推送（必须）

如果 ideas 根目录不是 git 仓库（参见边缘情况），则跳过此步骤。否则，在 Phase 5 之后，或在提前停止时（参见说明），运行此步骤：

1. 仅暂存本次运行写入的文件：git add <project folder>/idea.md <project folder>/validate.md；如果 README 维护修改了 README.md，也将其加入。绝不运行 git add -A。
2. 运行 git diff --cached --name-only，确认暂存的只有这些文件。如果还有其他文件已暂存，则使用 git restore --staged <file> 将其取消暂存。
3. 使用提交信息 docs(ideas): validate <short_snake_case_name> 创建提交。
4. 推送到当前分支。
5. 如果推送被拒绝，则变基并重试一次：branch="$(git rev-parse --abbrev-ref HEAD)" && git fetch origin && git rebase "origin/$branch" && git push。
6. 如果推送仍然失败（缺少 origin、变基冲突或再次被拒绝），则停止并询问用户，再继续操作。

调用此 skill 即表示授权提交并推送。无需再次征求推送许可。绝不在 ideas 仓库中强制推送或运行 git reset；只有在获得用户确认后，才能解决变基冲突。

最终报告

每次运行（包括停止的情况）都应以简洁的聊天文本提供一份摘要：主要结果无需打开文件即可查看，完整细节则写在 validate.md 中。仅当用户要求其他格式时，才遵循其他格式。按第一个匹配的规则确定状态：

1. BLOCKED — 没有 idea 描述、ideas 根目录无法写入，或用户拒绝在没有网页搜索的情况下继续。
2. PARTIAL — 跳过了某个步骤或提前停止、Phase 3 在没有实时搜索的情况下运行，或文件未提交并推送。
3. COMPLETE — Setup 至 Commit and Push 全部完成。

摘要按以下顺序包含这些行：

• Result: 状态，随后是 verdict 和四项评分（如果运行了 Phase 4）；对于 PARTIAL 或 BLOCKED，说明停止的步骤及原因。
• Evidence: 项目文件夹路径；idea.md、validate.md 的 GitHub 链接，以及（如有更改）README.md 的链接；提交哈希；实时查询次数和找到的竞争对手数量。只引用已运行的检查。
• Strengths: 和 Concerns: 各列出最重要的 3 项。
• Uncertainty: 每个回答为 unknown 的问题、每项依赖假设而非来源的结论，以及每项跳过的检查。如无此类情况，写 none within the checks run。
• Decision: No approval needed.（调用即表示已授权提交并推送），或说明运行停止时提出的问题。
• Next step: 对用户而言最重要的一项后续操作。

根据 git remote get-url origin 和当前分支构建每个 GitHub 链接：https://github.com/<owner>/<repo>/blob/<branch>/<relative-path>。示例摘要和填写规则见 references/final-report.md。

验收标准

• Setup、Phases 1-5 和 Commit and Push 按顺序运行；否则，流程会在 Edge Cases 行以匹配的状态停止
• 通过实时网络搜索开展竞争格局研究，至少使用 4 个不同的查询
• 同时检查商业工具/服务和开源解决方案；如果没有找到可信的 OSS 选项，则记录尝试过的 OSS 查询
• 在 validate.md 中填写竞争对手表格和开源替代方案与复用潜力分析
• 判定结果（Build it / Maybe / Skip it）需注明得出该结果的判定规则，并说明理由
• 提供全部四项评分（创造力、可行性、市场影响、技术执行），每项满分为 10 分
• 仅提交本次运行写入的文件，并推送提交（否则状态为 PARTIAL）
• 最终报告以 Result: 和状态开头，并包含 Evidence:、Uncertainty: 和 Decision: 行
• 读者检查通过：能找到结果，事实与假设明确区分，主张可追溯，且下一步决策清晰（references/final-report.md → 读者检查；evals/evals.json 中的场景用例）