name: 脑力激荡 description: 此技能应在实施功能、构建组件或进行更改之前使用。它指导在规划之前探索用户意图、方法和设计决策。触发条件包括"让我们脑力激荡"、“帮我思考”、“我们应该构建什么”、“探索方法”、模糊的功能请求，或当用户的请求有多个有效解释需要澄清时。

脑力激荡

此技能提供详细的流程知识，用于有效的脑力激荡会议，以澄清构建什么，然后再深入如何构建。

何时使用此技能

脑力激荡在以下情况下很有价值：

需求不清晰或模糊
多种方法可以解决问题
需要与用户探索权衡
用户未完全表达他们想要什么
功能范围需要细化

可以跳过脑力激荡当：

需求明确且详细
用户确切知道他们想要什么
任务是直接的错误修复或明确定义的更改

核心流程

阶段0：评估需求清晰度

在深入问题之前，评估是否需要脑力激荡。

需求清晰的信号：

用户提供了具体的验收标准
用户引用了要遵循的现有模式
用户描述了预期的确切行为
范围受限且明确定义

需要脑力激荡的信号：

用户使用了模糊的术语（“让它更好”、“添加类似的东西”）
存在多个合理的解释
权衡尚未讨论
用户似乎不确定方法

如果需求清晰，建议：“您的需求似乎清晰。考虑直接进行规划或实施。”

阶段1：理解想法

一次问一个问题以理解用户的意图。避免用多个问题压倒用户。

提问技巧：

当存在自然选项时，优先使用多项选择
- 好：“通知应该是：(a) 仅电子邮件，(b) 仅应用内，还是 © 两者？”
- 避免：“用户应该如何被通知？”
从广泛开始，然后缩小
- 首先：核心目的是什么？
- 然后：用户是谁？
- 最后：存在哪些约束？
明确验证假设
- “我假设用户已登录。是否正确？”
尽早询问成功标准
- “您如何知道这个功能运行良好？”

要探索的关键主题：

主题	示例问题
目的	这解决了什么问题？动机是什么？
用户	谁使用这个？他们的上下文是什么？
约束	有任何技术限制吗？时间线？依赖关系？
成功	您如何衡量成功？快乐路径是什么？
边界情况	不应该发生什么？需要考虑任何错误状态吗？
现有模式	代码库中有类似功能可遵循吗？

退出条件： 继续直到想法清晰或用户说"继续"或"让我们继续"

阶段2：探索方法

理解想法后，提出2-3个具体方法。

每个方法的结构：

### 方法A: [名称]

[2-3句描述]

**优点：**
- [好处1]
- [好处2]

**缺点：**
- [缺点1]
- [缺点2]

**最适合时：** [此方法表现出色的情况]

指南：

以推荐开始并解释原因
诚实对待权衡
考虑YAGNI——更简单通常更好
相关时参考代码库模式

阶段3：捕捉设计

以结构化格式总结关键决策。

设计文档结构：

---
date: YYYY-MM-DD
topic: <kebab-case-topic>
---

# <主题标题>

## 我们正在构建什么
[简洁描述—最多1-2段]

## 为什么选择此方法
[简要解释考虑过的方法以及为什么选择这个]

## 关键决策
- [决策1]: [理由]
- [决策2]: [理由]

## 开放问题
- [任何未解决的问题供规划阶段使用]

## 下一步
→ `/workflows:plan` 用于实施细节

输出位置： docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md

阶段4：移交

呈现明确的下一步选项：

进行规划 → 运行 /workflows:plan
进一步细化 → 继续探索设计
现在完成 → 用户稍后返回

YAGNI原则

在脑力激荡期间，积极抵制复杂性：

不要为假设的未来需求设计
选择解决所述问题的最简单方法
偏好无聊、已验证的模式，而不是聪明的解决方案
当复杂性出现时，问"我们真的需要这个吗？"
推迟不需要现在做出的决策

增量验证

保持部分简短—最多200-300字。在输出的每个部分后，暂停以验证理解：

“这与您的想法匹配吗？”
“在继续之前有任何调整吗？”
“这是您想走的方向吗？”

这防止了对不匹配设计的浪费努力。

要避免的反模式

反模式	更好的方法
一次问5个问题	一次问一个
跳入实施细节	专注于什么，而不是如何
提出过于复杂的解决方案	从简单开始，只在需要时添加复杂性
忽略现有代码库模式	首先研究已存在的内容
不验证假设	明确陈述假设并确认
创建冗长的设计文档	保持简洁—细节放在计划中

与规划的集成

脑力激荡回答构建什么：

需求和验收标准
选择的方法和理由
关键决策和权衡

规划回答如何构建它：

实施步骤和文件更改
技术细节和代码模式
测试策略和验证

当有脑力激荡输出时，/workflows:plan 应检测它并使用它作为输入，跳过其自身的想法细化阶段。