brainstorming · 创意头脑风暴
动手写代码之前的创意设计 skill：通过协作对话把想法打磨成完整设计。它先对需求分类定级——Spike（可行性验证）、Bounded（已有代码的小改动）、Architectural（新项目/新子系统）——再按路径推进：挖掘意图、写回理解供纠正、呈现设计，最后经用户确认才进入实施。
每条路径都有硬性审批门：设计未经确认，不会开始写代码。架构级需求还会产出书面 spec 文档。
调用示例：在聊天框中说"帮我设计一个用户反馈收集功能，先别写代码"。
产品详解
定位
brainstorming 是动笔写代码前的创意设计流程：通过协作对话把模糊想法变成经确认的设计与规格。它管的是"做什么、怎么做才对"，不写产品代码；每个设计都必须经过用户审批才算完成。
核心能力
- 三路径分类：Spike（可行性问题，产出是结论而非代码）、Bounded（已有代码的边界清晰小改动）、Architectural（新项目/新子系统/接口变更）。分类先说出口，用户可纠正。
- 单向升级：拿不准选更重的路径；中途发现隐藏复杂度时升级路径，绝不降级。
- 硬性审批门：Spike 需认可问题与探针计划；Bounded 需认可聊天内短设计；Architectural 需审阅书面 spec 再转实施计划。审批只覆盖实际呈现的阶段。
- 意图挖掘：一次只问一个问题，优先多选题；把理解写回成用户可纠正的短笔记，区分"用户说的"与"假设的"。
- 架构级深度：2-3 个方案对比（含取舍与推荐）、分节呈现设计、spec 自检（占位符/矛盾/范围/歧义）、写入
docs/superpowers/specs/并提交 git。 - 只读探索允许：设计审批完成前，只能做只读的项目探索，不做任何实施动作。
工作流程
- 分类并宣布路径（Spike / Bounded / Architectural）
- 探索项目上下文：文件、文档、近期提交
- 逐个澄清问题：一次一个，聚焦目的、约束、成功标准
- 呈现设计：Spike 是问题+探针计划（2-3 句）；Bounded 是聊天内短设计（方法、涉及文件、测试）；Architectural 是方案对比+分节设计
- 获取审批：硬门，未经确认不进入实施
- 架构路径：写 spec 文档 → spec 自检 → 用户审阅 → 转 writing-plans 制定实施计划
输入与输出
| 输入 | 说明 |
|---|---|
| 创意/需求描述 | 新功能、组件、行为变更等；目的与约束越完整，需要的澄清越少 |
输出（按路径）：Spike——可行性结论与建议；Bounded——聊天内短设计；Architectural——书面设计文档（docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md）与共识记录。
与相邻 skill 的区别
- executing-plans：负责执行已确定的实施计划；brainstorming 产出计划之前的设计与共识，在它上游。
- requesting-code-review：审的是已写好的代码；brainstorming 管的是写代码之前的设计。
适用场景
- 动手写代码前，想先理清需求、约束与成功标准
- 新项目、新子系统或接口变更的架构决策
- "能不能做"的可行性验证，用最小成本探针找答案
- 团队协作中把想法沉淀为可审阅的设计文档
使用前准备
- 无需 API key；需要读取项目仓库（文件/文档/提交记录）。
- 各路径的审批门是硬门：设计不经确认不会进入实施，请预留审阅时间。
- 建筑路径的产出是书面 spec，实施阶段交由 writing-plans 制定计划，brainstorming 本身不写产品代码。
brainstorming 隶属于 Aiglade Skill 库。在 Aiglade 聊天框中用自然语言描述需求即可调用。