用途：在实现功能、构建组件或做改动之前，先澄清需求与设计意图，回答“要做什么”而非“怎么做”。
主要能力：分阶段推进。阶段0评估需求是否清晰，若已明确可建议直接进入规划或实现；阶段1一次只问一个问题，理解目的、用户、约束、成功标准、边界情况与既有模式；阶段2提出2-3个具体方案，列出优缺点与适用条件并给出推荐；阶段3用结构化设计文档记录关键决策、开放问题与下一步；阶段4给出继续规划、继续细化或暂缓的交接选项。
使用方式：需求模糊、存在多种合理解释、需要权衡取舍或范围待细化时启用。提问优先用选择题，先宽后窄，显式确认假设。设计文档输出到 docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md，包含日期、主题、要构建的内容、选择该方案的原因、关键决策、开放问题与下一步，并指向 /workflows:plan。
适用场景：新功能探索、组件设计、范围不清的改动。需求明确、用户目标清晰或只是简单缺陷修复时可跳过。
限制与原则：遵循 YAGNI，避免为假设的未来需求设计，优先简单且经过验证的模式；每段输出控制在200-300字并暂停确认；避免一次问多个问题、过早进入实现细节、方案过度复杂、忽略既有代码模式、未验证就假设、写冗长文档。头脑风暴只回答“做什么”，实现步骤、文件改动、技术细节与测试策略由规划阶段负责；若已有头脑风暴产出，/workflows:plan 应检测并作为输入，跳过自身的想法细化阶段。