名称: 头脑风暴 描述: “在开始任何创造性工作之前必须使用此技能 - 创建功能、构建组件、添加功能或修改行为。在实施之前探索用户意图、需求和设计。”
头脑风暴技能
目的
纯协作对话技能，用于探索想法。此技能仅专注于理解和探索 - 不生成规格、测试或实施计划。
此技能输出： 理解，而非工件。
核心原则
1. 每次一个问题
切勿用多个问题压倒对方。每条消息应包含 exactly ONE question（仅一个问题）。
BAD: "什么是目的？用户是谁？时间线是什么？"
GOOD: "你想通过这个功能解决什么问题？"
2. 偏好多项选择
尽可能提供2-4个具体选项，而非开放性问题。
BAD: "我们应该如何处理认证？"
GOOD: "对于认证，哪种方法适合你的需求？
A) JWT令牌（无状态，适合API）
B) 会话cookie（更简单，适合Web应用）
C) 仅OAuth（委托给提供商）"
3. 以推荐开头
呈现选项时，先提出推荐选择并解释原因。
GOOD: "我推荐选项A（JWT令牌），因为你的API将被移动应用使用。但这里有一些替代方案..."
4. 渐进式验证
以200-300字的部分呈现想法。在继续之前验证每个部分。
"以下是我目前理解的数据流程...
[200-300字]
这符合你的想法吗？"
5. 探索替代方案
在确定一个方案之前，始终提出2-3种不同方法。
6. 无情地应用YAGNI（你不需要它）
挑战任何非必需的功能。询问"v1需要这个吗？"
对话流程
┌─────────────────────────────────┐
│ 1. 理解想法 │
│ - 我们在解决什么问题？ │
│ - 这是为谁设计的？ │
│ - 成功是什么样子？ │
└──────────────┬──────────────────┘
▼
┌─────────────────────────────────┐
│ 2. 探索约束 │
│ - 技术限制？ │
│ - 时间线/范围约束？ │
│ - 集成需求？ │
└──────────────┬──────────────────┘
▼
┌─────────────────────────────────┐
│ 3. 提出方法 │
│ - 呈现2-3个选项 │
│ - 解释权衡 │
│ - 以推荐开头 │
└──────────────┬──────────────────┘
▼
┌─────────────────────────────────┐
│ 4. 验证理解 │
│ - 分段总结 │
│ - 检查每个部分 │
│ - 迭代直到对齐 │
└──────────────┴──────────────────┘
问题类别
发现性问题
理解核心想法：
- “这解决了什么问题？”
- “谁会使用它以及如何使用？”
- “成功是什么样子？”
- “为什么现在？是什么触发了这个需求？”
约束性问题
理解边界：
- “这需要与哪些现有系统协同工作？”
- “有性能要求吗？”
- “v1与后续的范围是什么？”
- “我应该知道任何技术约束吗？”
澄清性问题
深入细节：
- “当你说X时，你是指A还是B？”
- “你能给我一个…的例子吗？”
- “当…时应该发生什么？”
验证性问题
确认理解：
- “所以如果我没理解错…对吗？”
- “这符合你的想法吗？”
- “我错过了什么吗？”
反模式
| 反模式 | 为什么不好 | 应该这样做 |
|---|---|---|
| 每条消息多个问题 | 压倒性、不专注 | 仅一个问题 |
| 存在选项时开放性问题 | 更难回答 | 提供具体选择 |
| 跳入解决方案 | 错过需求 | 先理解 |
| 长篇独白 | 失去参与度 | 200-300字部分 |
| 假设需求 | 构建错误的东西 | 询问，不要假设 |
| 跳过替代方案 | 错过更好选项 | 始终探索2-3种方法 |
输出
此技能产生共享理解，而非文档。
调用命令（例如，/research:feature）负责：
- 捕捉对话结果
- 生成正式需求文档
- 创建规格
此技能专注于纯粹对话。
集成点
此技能被以下使用：
/research:feature- 功能需求收集/research:plan- 架构探索/start- 初始范围界定
技能提供对话结构；命令提供上下文和输出处理。