用途：在动手实现功能、构建组件或做改动之前，帮助澄清需求与设计方向，回答“要做什么（WHAT）”，而不是“怎么做（HOW）”。
适用时机：需求不清晰或有歧义、存在多种可行方案、需要与用户探讨取舍、用户尚未完整表达意图、功能范围需要细化时。若需求已明确（有具体验收标准、参考了现有模式、描述了确切行为、范围受限），可跳过并直接进入规划或实现。
核心流程：
- 评估需求清晰度，判断是否需要头脑风暴。
- 理解想法：一次只问一个问题，优先用多选形式，先宽后窄，显式验证假设，尽早询问成功标准；探索目的、用户、约束、成功、边界情况、现有模式等主题。
- 探索方案：提出 2-3 个具体方案，每个包含描述、优点、缺点和最佳适用场景，先给推荐并说明理由，诚实说明取舍，参考代码库现有模式。
- 记录设计：以结构化设计文档总结关键决策，输出到 docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md，包含构建内容、选择该方案的原因、关键决策、待解决问题和下一步。
- 交接：可选择进入规划（运行 /ce:plan）、继续细化设计或暂时结束。
原则与限制：遵循 YAGNI，避免为假设的未来需求设计，选择最简单可行的方案，优先成熟模式；分段输出并逐段确认，每段控制在 200-300 字以内。避免一次问多个问题、跳到实现细节、方案过度复杂、忽略现有代码库模式、未经验证就假设、写冗长设计文档。头脑风暴只回答需求与验收标准、所选方案及理由、关键决策与取舍；实现步骤、文件改动、技术细节、测试策略等由规划阶段负责。当存在头脑风暴输出时，/ce:plan 应能检测并将其作为输入，跳过自身的想法细化阶段。
其他信息（如安装方式、收费、平台支持等）暂未提供。