一句“给后台加个导出按钮”，可能只需要导出现有筛选结果，也可能涉及后台任务、权限隔离和大文件下载。brainstorming 的作用是先识别这种差别，让后续代码建立在双方同意的需求上，避免做出一个看起来完整却解决错问题的功能。
安装并开始
在 Claude Code 会话内运行下面的插件命令，安装整套 Superpowers，保留各技能之间的衔接。Codex 用户在插件界面搜索并安装 Superpowers；两个客户端需要分别安装。安装后开启新会话，在项目目录里明确提出使用 brainstorming，再交代任务范围。
/plugin install superpowers@claude-plugins-official
不必每次都写一份长设计书
以下是可按项目调整的首次输入：
使用 Superpowers brainstorming。我想给现有订单后台增加导出功能。先读当前筛选、权限和数据量限制，判断这是局部改动还是需要新子系统；逐步问清范围，先给方案，不开始写实现代码。
当前说明区分三条路径：验证可行性的探索、小范围且边界清楚的改动，以及牵涉新系统或接口的架构设计。探索可以以回答一个问题和临时实验结束；局部改动可以在聊天中确认简短设计。只有需要完整设计的任务，才进入更详细的方案与文档流程。
先把现有代码、使用者和成功标准交代清楚。对于订单导出，你需要回答谁能导出、导出当前页还是全部筛选结果、数据超过一定规模怎么办。Agent 应结合代码提问，一次推进一个关键问题，而不是把一份通用问卷丢给你。
先比较选择，再批准实现
架构型任务会比较几种做法和取舍，再分段展示设计。你可以逐段纠正假设，直到数据流、失败处理与不做的范围都清楚。比如同步生成文件容易起步，但大量数据可能需要异步任务；哪种合适，要由真实规模与产品要求决定。
完整设计通常写入 docs/superpowers/specs 下带日期的文档，随后才交给 writing-plans 拆解实施。聊天里认可一个想法，不等于已经审阅最终落盘的设计；检查文档是否保留刚才商定的限制，再同意下一步。已有项目文档规范时，应把位置和格式提前说明。
什么才算这一轮结束
合理的结束点可以是一个已回答的可行性问题、一段已确认的局部方案，或一份已批准的设计。它不是“必须马上生成代码”。如果范围不断扩大，让 Agent 把独立需求分开，并先完成当前最小交付。可选的视觉辅助只在图示有助于判断时使用，不是每次讨论的必需项。
这个流程仍需要你对业务作决定。资料不足时，保留待确认项比让 Agent 自动猜测更有用；资料已经充分时，也不必为了形式重复回答同一个问题。
第二个例子：把模糊的提醒需求变成可判断的方案
如果你说“用户忘记完成任务时提醒一下”，先把现有通知入口、用户时区、退订机制和什么算“未完成”交给 Agent 阅读。让它先判断是小范围改动还是需要新的调度系统：现有任务表已有到期时间且只要站内提醒，也许几句设计就够；需要跨时区邮件、重试和频率限制，则要把失败与运营成本纳入架构方案。分别讨论“提醒何时产生”“如何避免重复”“用户如何关闭”，不要把这三件事混成一个按钮。
评审方案时，让 Agent 用一个具体用户路径走通：周五设置、周日到期、期间修改时区并完成任务，最终会不会收到过期提醒？如果方案不能回答，就还没准备好进入计划。探索路径的成果也可能只是“当前数据不足以判断”，这时记录待验证的数据和最小实验，比先写一个大而全的通知系统更有价值。确认设计后再决定是否让 writing-plans 拆任务；不要把脑暴阶段生成的备选想法都当成已经批准的需求。
在现有产品里先看真实代码
在已有产品里讨论功能时，先给 Skill 真实约束：相关组件、数据结构、当前界面和不能改变的交互。曾有使用者让 brainstorming 讨论既有 Next.js UI，得到的组件与 mock 越迭代越偏离项目；暂停讨论、先探查真实代码并把发现带回后，设计才回到可实施范围。可以在首次输入里加一句：“提出方案前先读这些文件并概述现有形状；若找不到，列出待确认点，不自行发明组件。”这样头脑风暴是在当前产品上做决定，而不是替另一个虚构产品画图。