核心用法
superpowers-brainstorming 是一个前置性设计约束工具，用于在一切创造性工作（功能开发、组件构建、行为修改）启动前，强制完成从想法到规格的标准化流程。用户触发条件后，Skill 会依次执行：项目上下文探索 → 视觉化同伴展示（如涉视觉问题）→ 澄清问题单轮询问 → 2-3 种方案对比与推荐 → 增量式设计展示与批准 → 规格文档编写与 Git 提交 → 规格自审 → 主人书面审查 → 调用 writing-plans 进入实现阶段。
整个流程以硬性门槛为约束：任何代码编写、项目搭建或实现动作，必须在设计展示并获得主人批准后方可进行。Skill 特别强调"简单项目正是浪费重灾区"，即使几句话能说完的设计也必须走完整流程。
显著优点
防返工设计哲学：通过"YAGNI 彻底"和"增量验证"原则，在最早阶段剔除不必要功能，避免过度工程化。每个设计部分需经"这样看起来对吗"确认，大幅降低后期重构成本。
结构化认知减负：将复杂设计拆解为"探索-提问-方案-设计-文档-审查"的线性流程，每次只处理单一问题，避免多问题并发造成认知过载。多选优先的提问策略降低用户决策摩擦。
视觉化决策支持：Canvas 工具的差异化使用（视觉问题用画布、概念问题用文字），确保信息呈现形式与问题类型匹配，提升沟通效率。
模块化设计强制：要求"为隔离和清晰而设计"，每个单元需能回答"做什么、怎么用、依赖什么"，并满足"不读内部代码可理解、改变内部不破坏消费者"的接口标准，天然契合现代软件工程最佳实践。
零技术债务引入：无可执行代码、零依赖、无网络请求，本身不会引入供应链风险或运行时故障。
潜在缺点与局限性
流程刚性成本：对于资深开发者或紧急 patch 场景，9 步检查表可能显得冗余。硬性门槛设计不提供快速通道，可能引发熟练用户的摩擦感。
视觉判断依赖用户：Canvas 使用规则（"用户看这个比读文字更好吗"）需要用户自行判断，若误判可能导致信息呈现形式不当。
规格审查阻塞："主人审查书面规格"步骤为同步阻塞点，若主人响应延迟，整个流程停滞。文档未提供异步或降级策略。
Git 依赖隐式假设：要求 commit 设计文档到 git，但未说明无 Git 环境时的替代方案，可能使纯原型或教育场景用户困惑。
推荐方案的锚定效应：虽然要求展示 2-3 种方案，但"用推荐选项开头并解释"的格式可能强化先入为主偏见，削弱真正中立对比。
适合的目标群体
- 初创团队技术负责人：需在资源受限环境下最大化设计质量，避免"快速上线-大量返工"循环
- 外包/咨询开发者：与客户协作时需结构化确认需求，生成可追溯的规格文档作为交付物
- 初级-中级开发者：缺乏设计经验，需要系统化框架引导完成从需求到技术方案的转换
- 远程协作团队：依赖异步文档而非实时会议做设计决策，需要标准化评审流程
- 代码审查严格的企业环境：需强制设计评审节点以满足内部合规要求
不适合：追求极致开发速度的单人黑客马拉松场景、已建立成熟设计系统的资深技术团队（可能过度约束）。
常规使用风险
流程中断风险：若用户在任一检查点放弃，设计文档可能处于未完成状态，需手动清理 docs/superpowers/specs/ 目录中的中间文件。
路径冲突风险：固定路径 docs/superpowers/specs/ 若与既有项目结构冲突，需用户手动调整，Skill 未提供配置覆盖机制。
版本管理噪声：高频小功能开发可能产生大量设计文档 commit，需团队约定文档保留策略（如实现完成后归档）。
跨 Skill 衔接依赖：终点状态强制调用 superpowers-writing-plans，若该 Skill 未安装或版本不兼容，流程中断。