Brainstorming

脑暴与方向收敛

在正式写 PRD 之前，先通过协作式脑暴把需求方向、范围边界和推荐方案收敛清楚。

这个 skill 的职责是“收敛方向”，不是“写正式 PRD”，也不是“直接开始实现”。

工作流

输入： 一个新功能想法、模糊需求、功能改造方向，或多个尚未拆清的子问题。

1. 先理解当前项目上下文：查看相关文件、文档、现有模块和最近约定。
2. 如果需求明显过大或包含多个相对独立子系统，先帮助拆成较小问题，并聚焦本轮最合适的一个。
3. 一次只问一个关键问题，逐步澄清目标、核心能力、约束和成功标准。
4. 当信息足够时，给出 2-3 个可行方案，说明取舍并给出推荐。
5. 输出一份“脑暴结论”，内容包括推荐方向、范围、非目标、风险和未决问题。
6. 如果用户确认方向，建议下一步调用 prd skill，把脑暴结论整理为正式 PRD。

重要：

• 不要直接开始实现。
• 不要把脑暴结论当成正式 PRD。
• 只有在用户明确要求时，才将脑暴结论写入文件。

第一步：探索上下文

在提问之前，优先快速了解：

• 现有代码结构和模块边界
• README、设计文档、任务文档中的约束
• 现有功能是否已经覆盖部分需求
• 是否存在明显的命名约定、交互模式或数据模型限制

如果当前不是现有项目，而是纯想法阶段，也要先判断这是否是一个过大的复合需求。

第二步：一次只问一个关键问题

脑暴阶段要避免一次抛出太多问题。每次只问一个最影响方向判断的问题。

优先关注：

• 目标：这个功能要解决什么问题？
• 用户：最核心的目标用户是谁？
• 核心动作：用户必须完成的关键动作是什么？
• 边界：这次明确不做什么？
• 约束：是否有时间、技术、兼容性、权限或设计限制？
• 完成标准：怎样算这次方向选对了？

推荐尽量使用带字母选项的问题，让用户能快速回答。

第三步：必要时启用视觉脑暴

如果问题本身是视觉性的，例如：

• 页面布局
• 交互流对比
• 信息层级
• 组件样式方向
• 结构图或数据流图

可以使用本目录下的视觉 companion 资源：

• visual-companion.md
• scripts/start-server.sh
• scripts/stop-server.sh
• scripts/server.cjs

但这是可选分支，不是每次脑暴都必须启用。

只有在“用户看图会比看文字更容易理解”的情况下，才建议使用视觉脑暴。

第四步：给出 2-3 个方案

在正式收口前，必须给出 2-3 个可行方向，而不是只给一个默认答案。

每个方案至少说明：

• 方案概述
• 适用场景
• 优点
• 代价 / 风险

然后给出你的推荐方案，并解释：

• 为什么它更适合当前目标
• 为什么现在不优先选另外几个方案

第五步：输出脑暴结论

当用户确认方向后，输出一份简洁但可交接的“脑暴结论”。建议包含：

1. 需求目标

• 这次要解决什么问题

2. 推荐方向

• 采用哪一种方案
• 为什么

3. 范围

• 本次要做的内容

4. 非目标

• 本次明确不做的内容

5. 风险与约束

• 已知技术、设计、交付风险

6. 未决问题

• 仍需后续确认的点

第六步：与 prd skill 的衔接

当脑暴结论已经稳定后：

1. 先向用户确认方向是否正确。
2. 如果用户确认，建议下一步调用 prd skill。
3. prd skill 应根据脑暴结论写成正式 PRD 文档。

推荐衔接方式：

• 直接把脑暴结论作为 prd 的输入
• 如果用户明确要求保存，可写入 tasks/brainstorm-[feature-name].md
• 然后让 prd 基于该结论输出 tasks/prd-[feature-name].md

输出要求

默认输出是对话中的“脑暴结论”，不是正式 PRD。

如果用户明确要求保存：

• 格式： Markdown (.md)
• 目录： tasks/
• 文件名： brainstorm-[feature-name].md

保存前检查

• 已先了解必要项目上下文
• 如果需求过大，已先完成拆分
• 已一次只问一个关键问题，而不是堆叠提问
• 已给出 2-3 个方案并明确推荐
• 已写清楚范围和非目标
• 已明确下一步应交给 prd，而不是直接进入实现