用途
idea-refine 是一个帮助把原始想法打磨成清晰、可执行、值得构建的概念的 skill。它适用于以下情况：想法还很模糊时；需要在承诺某个计划之前压力测试假设时；或想在收敛到一个方案之前先扩展选项时。
主要能力
它通过结构化的发散与收敛思考来完成工作，分为三个阶段：
阶段 1：理解与扩展（发散）
接住原始想法并把它打开。先重述想法，把它变成清晰的 "How Might We" 问题陈述，这会迫使你澄清到底要解决什么。然后提出 3-5 个打磨问题（不再更多），聚焦于：这具体是为谁做的？成功是什么样子？真实约束是什么（时间、技术、资源）？之前试过什么？为什么是现在？使用 AskUserQuestion tool 收集这些输入。在你理解这是为谁做的、成功是什么样子之前，不继续。之后用这些视角生成 5-8 个想法变体：反转、移除约束、受众迁移、组合、简化、10x 版本、专家视角。
如果在代码库中运行，会使用 Glob、Grep 和 Read 扫描相关上下文，包括现有架构、模式、约束和先例，让变体扎根于实际存在的东西。还会阅读该 skill 目录中的 frameworks.md 获取可借鉴的其他构思框架，选择性使用。
阶段 2：评估与收敛
用户对阶段 1 做出反应后，切换到收敛模式：把用户有共鸣的想法聚类成 2-3 个不同方向；用三个标准压力测试每个方向，即用户价值、可行性、差异化；暴露隐藏假设，对每个方向明确说出你押注什么为真（但还没有验证）、什么可能杀死这个想法、你选择忽略什么（以及为什么现在可以忽略）；并对薄弱想法具体而温和地提出反对。还会阅读该 skill 目录中的 refinement-criteria.md 查看完整评估 rubric。
阶段 3：打磨与交付
产出一份具体的 markdown one-pager，包含 Problem Statement、Recommended Direction、Key Assumptions to Validate、MVP Scope、Not Doing (and Why)、Open Questions。其中 "Not Doing" 列表被认为是最有价值的部分。最后询问用户是否想把它保存到 docs/ideas/[idea-name].md（或他们选择的位置），只有在用户确认后才保存。
使用方式
这个 skill 主要是一段互动式对话。带着一个想法调用它，agent 会引导你完成整个过程。
可选：初始化 ideas 目录
bash skills/idea-refine/scripts/idea-refine.sh
触发短语：
- "Help me refine this idea"
- "Ideate on [concept]"
- "Stress-test my plan"
最终输出是一份 markdown one-pager，在用户确认后保存到 docs/ideas/[idea-name].md。
输出结构
# [Idea Name]
## Problem Statement
[One-sentence "How Might We" framing]
## Recommended Direction
[The chosen direction and why — 2-3 paragraphs max]
## Key Assumptions to Validate
- [ ] [Assumption 1 — how to test it]
- [ ] [Assumption 2 — how to test it]
- [ ] [Assumption 3 — how to test it]
## MVP Scope
[The minimum version that tests the core assumption. What's in, what's out.]
## Not Doing (and Why)
- [Thing 1] — [reason]
- [Thing 2] — [reason]
- [Thing 3] — [reason]
## Open Questions
- [Question that needs answering before building]
适用场景
当用户带着一个想法调用这个 skill 时，它引导用户完成三个阶段，并根据用户所说的内容调整方式，这是一场对话，而不是模板。适合在想法模糊、需要扩展选项、或需要在决策前压力测试假设的场景使用。
限制与反模式
需要避免的反模式包括：不要生成 20+ 个想法（质量胜过数量，5-8 个深思熟虑的变体胜过 20 个浅层点子）；不要当 yes-machine，要具体而温和地反驳薄弱想法；不要跳过“这是为谁做的”；不要在没有暴露假设的情况下产出计划；不要过度工程化这个流程，抵制增加步骤；不要只是列想法，要讲故事；不要忽略代码库。
红旗包括：生成 20+ 个浅层变体而不是 5-8 个经过思考的变体；跳过“这是为谁做的”这个问题；在承诺某个方向前没有暴露假设；对薄弱想法 yes-machining；产出的计划没有 "Not Doing" 列表；在项目中构思时忽略现有代码库约束；没有运行阶段 1 和阶段 2 就直接跳到阶段 3 输出。
完成验证
完成一次构思会话后：存在清晰的 "How Might We" 问题陈述；已定义目标用户和成功标准；探索了多个方向而不是只探索第一个想法；隐藏假设已明确列出并带有验证策略；"Not Doing" 列表让取舍变得显式；输出是具体工件（markdown one-pager）而不只是对话；用户在任何实现工作开始前确认了最终方向。
语气
直接、周到、略带挑衅。是一个敏锐的思考伙伴，而不是照着稿子念的 facilitator。保持“这很有意思，但如果……”的能量，始终往前多推一步，但不要让人疲惫。可阅读该 skill 目录中的 examples.md 了解优秀构思会话的示例。