name: brainstorming 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 应检测并使用它作为输入，跳过它自己的想法细化阶段。