当想法还模糊或需要在承诺计划前压力测试假设时…

把一个模糊的想法通过发散探索、收敛评估、产出单页文档三步，打磨成值得动手做的清晰方案。

适用场景

解决思路

1. 把原始想法重述为一个简洁的「How Might We」问题陈述，强制厘清真正要解决的问题。
2. 提出 3-5 个（不要更多）尖锐的澄清问题，聚焦：具体为谁而做？成功是什么样？真实约束（时间、技术、资源）是什么？以前尝试过什么？为什么是现在？使用 AskUserQuestion 工具收集输入，在弄清「为谁做」和「成功标准」之前不要继续。
3. 用以下视角生成 5-8 个想法变体：反转（「如果反着做呢？」）、移除约束（「如果预算/时间/技术都不是限制呢？」）、切换受众（「如果这是给另一个用户群体呢？」）、组合（「如果和相邻想法合并呢？」）、简化（「10 倍简化的版本是什么？」）、10 倍版本（「大规模下会是什么样？」）、专家视角（「领域专家觉得显而易见、外行却想不到的是什么？」）。要超越用户最初的要求。
4. 如果在代码库中运行：用 Glob、Grep、Read 扫描相关上下文——现有架构、模式、约束、先例，让变体扎根于实际存在的东西，并引用具体文件和模式。
5. 阅读技能目录下的 frameworks.md 获取更多构思框架，按需选择性使用，不要机械地跑完每个框架。
6. 在用户对第一阶段做出反应后切换到收敛模式：把引起共鸣的想法聚类成 2-3 个截然不同的方向，每个方向应有实质差异而非同一主题的变体。
7. 用三个标准对每个方向做压力测试：用户价值（谁受益、受益多大？是止痛药还是维生素？）、可行性（技术和资源成本多少？最难的部分是什么？）、差异化（真正不同在哪？有人会从现有方案切换过来吗？）。阅读 refinement-criteria.md 获取完整评估标准。
8. 对每个方向显式列出隐藏假设：你押注为真但尚未验证的是什么、什么可能杀死这个想法、你选择忽略什么（以及为什么暂时可以忽略）。这是大多数构思失败的地方，不要跳过。
9. 诚实而非一味支持：如果想法很弱，温和地指出来。对复杂性提出质疑，质疑真实价值，指出「皇帝没穿衣服」的时候。
10. 产出具体的 markdown 单页文档，包含：问题陈述（一句话 How Might We 框架）、推荐方向（所选方向及原因，最多 2-3 段）、待验证的关键假设（复选框列表，每条附验证方法）、MVP 范围（测试核心假设的最小版本，什么在内什么在外）、不做清单（每条附原因）、待解问题。
11. 把「不做清单」当作最有价值的部分——聚焦就是拒绝好想法，把取舍显式化。
12. 询问用户是否愿意保存到 docs/ideas/[idea-name].md（或用户选择的位置），仅在用户确认后才保存。
13. 可选：运行 bash skills/idea-refine/scripts/idea-refine.sh 初始化 ideas 目录。
14. 避免反模式：不要生成 20+ 个想法（5-8 个深思熟虑的变体胜过 20 个浅薄的）；不要做应声虫；不要跳过「为谁而做」；不要在没有暴露假设的情况下产出计划；不要过度工程化流程（三阶段，每阶段做好一件事）；不要只罗列想法而要讲故事（每个变体都应有存在的理由）；如果在项目中不要忽略代码库。
15. 保持直接、深思、略带挑衅的语气，像一个敏锐的思考伙伴而非照本宣科的引导者，始终用「这很有意思，但如果……」再推进一步。
16. 完成后按验证清单检查：存在清晰的 How Might We 问题陈述、定义了目标用户和成功标准、探索了多个方向而非只用第一个想法、隐藏假设被显式列出并有验证策略、不做清单明确了取舍、产出是具体文档而非仅对话、用户在任何实现工作前确认了最终方向。

适用边界 · 注意事项

• 想法已经非常明确、具体且可直接执行时，不需要再做发散探索。
• 只需要快速记录一个想法、不打算深入打磨或压力测试时。
• 用户明确只想要一个简单答案或直接实现，而不想参与多轮对话式构思时。