ideation

构思：将想法转化为结构化文档

通过自然的协作式对话，帮助将粗略的想法整理成结构化、经过验证的想法文档。首先了解当前项目背景，然后一次提出一个问题来完善想法。想法明确后，提出几种方案，评估其可行性，并征求用户批准。

不要跳过直接进入实现。此技能旨在产出经过深思熟虑的想法文档，以便用于需求定义（例如 USDM）或作为任务跟踪。即使想法看起来很简单，未经审视的假设也最容易造成大量返工。

流程

请按顺序完成以下步骤：

步骤 1：了解背景

在继续之前，调查用户输入中提及的所有信息来源。

1a：外部参考

扫描用户输入，查找外部参考内容——应用名称、技术名称、URL、规范、标准、协议、服务或文档。如果发现任何内容：

• URL：获取并阅读链接内容，以了解其范围、API 接口、约束或规范
• 具名技术／服务：查找官方文档、功能、限制和集成模式
• 现有应用或产品：研究其功能、行为和设计，以了解用户指的是什么
• 标准／协议：查阅规范，了解要求和约束

在调查完所有外部参考之前，不要继续执行步骤 2。误解外部参考会导致后续每个步骤都出现错误。

1b：项目背景

检查当前项目，了解现有内容：

• 检查项目文件、文档和最近的提交
• 找出现有解决方案、模式和惯例
• 记录约束、依赖项和技术边界

这样可以让构思立足现实，而不是从空白状态开始。

步骤 2：提出澄清问题

通过有针对性的对话了解想法：

• 一次只问一个问题，不要一次抛出多个问题让用户应接不暇
• 可行时优先采用选择题，因为回答起来比开放式问题更轻松
• 重点了解目的、目标用户、约束和成功标准
• 如果新信息改变了整体情况，要随时准备重新审视之前的问题

持续提问，直到清楚了解用户想要什么，以及为什么想要。

步骤 3：提出方案

提出 2-3 种各有权衡的方案：

• 首先介绍推荐方案并说明理由
• 以对话式方式介绍其他选项，并说明理由
• 每种方案都必须包含可行性评估：
  • 差异化：与现有解决方案相比有何不同？
  • 技术风险和约束：技术上可能会出什么问题？
  • 事前验尸：“如果这个想法失败，原因会是什么？”
• 遵循 YAGNI 原则，从所有方案中删去不必要的功能

步骤 4：呈现并验证

用户选定某个方案（或组合方案）后：

• 按章节呈现想法，内容详略视复杂程度而定
• 每完成一个章节，都询问目前看来是否合理
• 如果内容不合理，随时准备回退并修改

第 5 步：编写构想文档

用户批准构想后，生成文档。

保存到：.docs/ideas/YYYY-MM-DD-<topic>.md

文档必须包含以下章节：

章节	内容
What	功能说明及其解决的问题
Why	理由、用户收益、业务价值
Scope	范围内 / 范围外的边界
Stakeholders	目标用户、受影响的系统
Approaches	已探索的备选方案及其权衡和可行性评估
Decision	选定的方案及理由

请参阅 templates/idea-document.md 中的输出模板。

这些章节的结构旨在为需求定义工具（如 USDM）提供输入：

• What 对应 Requirements
• Why 对应 Reasons
• Scope 对应 Descriptions（上下文、约束）
• Stakeholders 为范围确认提供信息

第 6 步：选择输出

编写构想文档后，询问用户希望采用哪种输出方式：

选项	操作
A：仅 Markdown（默认）	将构想文档保存到 .docs/ideas/——完成
B：Markdown + GitHub Issue	保存文档并根据其内容创建 GitHub Issue
C：Markdown + 需求	保存文档并调用需求定义技能（如 usdm）

核心原则

• 一次只问一个问题——不要在一条消息中捆绑多个问题
• 优先采用选择题——可行时，选择题比开放式问题更容易回答
• 严格遵循 YAGNI——从所有方案中移除不必要的功能
• 探索备选方案——确定方案前，始终提出 2–3 种方案
• 逐步验证——展示各个章节，获得批准后再继续
• 保持灵活——遇到不合理之处时，返回并澄清
• 可行性优先于乐观预期——每种方案都需要诚实评估风险

致谢

此技能基于 obra/superpowers 中的头脑风暴技能（MIT 许可证）。