方法论来源与许可
Brainstorming 是来自 obra/superpowers 的方法论（MIT 许可）。它把“头脑风暴与设计优先”作为一套可执行的流程，供开发者或 AI 智能体在动手写代码之前使用。资料中未提供该技能的具体实现代码、安装命令或运行环境要求，暂未提供。
核心理念
硬性门槛：设计未获批准前，不写任何代码。
四个阶段
阶段一——理解问题
澄清用户目标，追问“这解决什么问题？”而不是“我该建什么？”。
识别约束：时间线、技术栈、既有模式、用户预期。
定义成功标准——如何判断做完且做好。
明确列出非目标，防止范围蔓延。
阶段二——生成备选方案
提出 2–3 个不同方案。不是同一个想法的变体，而是真正不同的策略。
对每个方案描述：
它如何工作（一段话，平实语言）。
优点——它擅长什么。
缺点——它不擅长什么或会让什么变难。
工作量——粗略规模（小 / 中 / 大）。
突出方案之间的权衡，而不只是功能清单。
阶段三——决策
把备选方案呈现给用户（若独自工作，则对照成功标准评估）。
推荐一个方案并给出清晰理由。
在写任何代码之前等待批准。
如果用户选了另一个选项，就完全采纳它——不要把个人的偏好偷偷夹带进来。
阶段四——毫不留情地应用 YAGNI
在添加任何功能前问：“这是现在就需要，还是将来某天可能需要？”
如果答案是“某天”，就砍掉。等需求真实出现时再加。
优先选择易于扩展的简单方案，而非预判未来的聪明方案。
每一行代码都是负债。更少的代码 = 更少的缺陷 = 更少的维护。
实用规则
设计讨论不是浪费时间——它防止实现阶段的时间浪费。
被否决的设计备选方案是有价值的信息，不是失败。
先写能工作的最简单版本。
在需求变化时重新审视设计决策，而不是因为无聊才重审。
应避免的反模式
因为“更快”就直接跳到代码。
只提一个选项然后问“这样可以吗？”。
镀金：添加没人要求的功能。
过早抽象：一个函数就够用时却去搭框架。