brainstorming

brainstorming skill 概览

brainstorming skill 是做什么用的

brainstorming skill 是一套结构化的“先设计、后实现”工作流：在还没写任何代码之前，先把一个模糊想法收敛成已获批准的设计。它的核心任务并不是抽象意义上的“帮你发散创意”，而是提前把范围、前提假设、需求和设计取舍摊开说清楚，从而减少返工。

谁适合安装这个 brainstorming skill

这个 brainstorming skill 特别适合那些经常从“我们应该做 X”直接跳到实现阶段的人。它尤其适用于：

• 功能规划
• 组件设计
• 行为变更
• 内部工具提案
• 用于 Requirements Planning 的 brainstorming

如果你已经有一套严格的 spec 流程，这个 skill 依然有价值：它可以作为那套流程前面的一个轻量入口。

它和普通 prompt 有什么不一样

最关键的区别在 SKILL.md 里的硬性门槛：在给出设计方案并获得批准之前，agent 不应该直接实现、搭脚手架或写代码。听起来很简单，但这会显著改变使用效果。相比之下，普通的“帮我做这个”式 prompt 往往会让助手直接跳到解决方案，省略中间的设计澄清环节。

用户在安装前最关心什么

大多数用户在安装前最想尽快确认三件事：

1. 它会不会拖慢我？
2. 它提的问题会不会有用，而不是一堆泛泛而谈？
3. 它能不能支持视觉设计讨论？

答案是：它确实是有意增加了一点流程成本，但当想法本身很小的时候，这个成本也很低。这个 skill 明确强调，即便是“看起来很简单”的工作，也应该先过一遍简短设计，因为很多代价高昂的错误，恰恰来自那些未被说出口的隐藏假设。

如何使用 brainstorming skill

brainstorming 的安装与设置

要从仓库添加这个 skill，可使用：
npx skills add https://github.com/obra/superpowers --skill brainstorming

安装后，建议先打开这些文件：

• skills/brainstorming/SKILL.md
• skills/brainstorming/visual-companion.md
• skills/brainstorming/spec-document-reviewer-prompt.md

如果你预计会用到视觉探索，也请顺带查看：

• skills/brainstorming/scripts/start-server.sh
• skills/brainstorming/scripts/frame-template.html

这个 brainstorming skill 期望的核心工作流

这个 brainstorming 的使用方式带有明确的方法论：

1. 先探索项目上下文
2. 视情况提供 visual companion
3. 一次只问一个澄清问题
4. 汇总并形成设计方案
5. 获取明确批准
6. 然后才进入规划或实现阶段

如果你的 agent 还是从想法直接跳到代码，那它其实并没有真正遵循这个 skill。

想让 brainstorming 用得更好，输入应该提供什么

如果你提供的不只是一个功能标题，这个 skill 的效果会好得多。一个更理想的起始输入通常包括：

• 要解决的问题
• 用户是谁
• 当前系统或 repo 的背景
• 约束条件
• “完成”意味着什么
• 已知的非目标

一个较弱的输入示例：

Add notifications.

一个更强的输入示例：

Add in-app notifications for failed background imports. Users are operations staff, not end customers. We already have email alerts, but they are too slow for live triage. Keep scope to the admin dashboard only. Do not add mobile push or user preference management in v1.

第二种写法能给 brainstorming skill 足够的结构信息，从而让它提出更锋利、更有决策价值的后续问题。

如何把一个模糊想法写成高质量的 brainstorming 首轮 prompt

一个实用的 brainstorming prompt 模板如下：

Use the brainstorming skill for Requirements Planning.
Context: [project/repo/product]
Problem: [what is happening now]
Target user: [who is affected]
Constraints: [timeline, stack, compliance, UX, compatibility]
Non-goals: [what not to solve]
Please ask clarifying questions one at a time, then present a proposed design for approval before any implementation.

这和 skill 预期的流程高度一致，也能降低它提出泛泛问题的概率。

澄清问题在 brainstorming 中应该怎么问

这里有个细微但非常重要的行为要求：问题应该一次只问一个，而不是一口气甩出一大份需求调研问卷。原因很简单——前一个回答往往会改变下一个问题应该怎么问。如果你的 agent 一次性丢出 15 个问题，那就失去了这个 brainstorming 指南原本要实现的“交互式逐步收敛”。

什么时候该用 visual companion

这个仓库内置了一个基于浏览器的 visual companion。适合在用户“看见选项”会比“读文字”更容易理解时使用，比如：

• 线框图
• 布局对比
• UI 流程
• 架构图
• 状态或关系可视化

但不要因为话题提到了 UI 就默认启用它。像“这里应该用 wizard 还是 modal？”这种偏概念的问题，用文字讨论就足够。像“这两个 wizard 布局里，哪个更清晰？”这种问题，就非常适合走视觉路径。

visual companion 实际上是怎么启动的

这个视觉辅助不只是文档说明；仓库里也附带了本地运行会话所需的脚本：

• scripts/start-server.sh
• scripts/stop-server.sh
• scripts/server.cjs
• scripts/helper.js

start-server.sh 会在一个随机高位端口上启动本地服务，并且可以把会话文件存储在 /tmp 下，或者存到项目目录里，例如 .superpowers/brainstorm/。如果你希望 mockup 能跨会话保留，这一点会很有用。

在依赖视觉流程前要注意的环境问题

这套视觉工作流默认假设你的环境可以通过浏览器访问。如果你是在远程容器、VM 或 SSH 工作流里使用，就要特别留意：

• --host
• --url-host
• session 目录是否可持久化

如果只是本地使用，默认配置通常没什么门槛；但如果是共享环境或远程环境，最好先把网络访问细节规划好，再围绕浏览器反馈去设计整个工作流。

快速上手时最推荐的文件阅读顺序

如果你想用最短路径把 brainstorming skill 用到“真正有质量”，建议按这个顺序读：

1. SKILL.md：先看行为契约
2. visual-companion.md：了解什么时候浏览器支持真的有帮助
3. spec-document-reviewer-prompt.md：理解什么叫“已经清晰到可以实现”
4. 如果需要视觉路径，再看 scripts/start-server.sh

这样的顺序，先建立决策逻辑，再补充可选工具。

一次好的 brainstorming 输出应该长什么样

一次成功的 brainstorming 会话，最后应该产出一个足够具体、可被审阅的设计，至少包含：

• 目标和用户
• 范围边界
• 关键决策
• 尚未解决的风险或假设
• 足够支持后续实现规划的具体性

如果最终产出只是一份松散的想法列表，那通常说明这次会话停得太早了。

如何把 brainstorming 用在 Requirements Planning

如果是用于 Requirements Planning 的 brainstorming，比较好的用法是把它放在 spec 之前，作为预处理步骤：

1. 先澄清问题和约束
2. 起草设计方向或需求形态
3. 获取批准
4. 再写 spec
5. 有需要的话，运行 spec reviewer prompt template

这是这个 skill 最强的使用场景之一，因为它能在规划被正式锁定之前，先把 scope drift 和模糊点揪出来。

brainstorming skill 常见问题

brainstorming skill 只适合大项目吗？

不是。这个 skill 明确反对“任务小就可以跳过设计”这种想法。对于很小的改动，设计本身当然可以很短，但“先设计一下”这个步骤依然重要。很多时候，它在那些看似简单、实则暗藏假设的改动上反而最有价值。

它比普通的 brainstorming prompts 更好吗？

通常是的，前提是你的真实目标是“得到可以执行的清晰方案”，而不是“尽量多出点想法”。普通 brainstorming prompt 可能更擅长发散出很多选项；而这个 brainstorming skill 更适合做收敛型思考：理解上下文、缩小选择范围，并产出一个已获批准的设计。

这个 brainstorming skill 对新手友好吗？

友好，尤其适合单人开发者或还没养成规划习惯的人。它的结构能弥补一种常见新手问题：一看到一个貌似可行的想法，就直接开始实现，却没有先厘清需求和权衡。

什么情况下 brainstorming 不太适合？

在以下情况可以跳过，或至少显著缩短：

• 任务是纯机械执行，而且已经被完整定义
• 你并没有在做设计或行为层面的决策
• 用户已经批准了详细 spec，现在只需要执行

即便如此，也要确认这个 skill 的硬性门槛不会和你的工作流冲突。它本来就是故意设计得比较严格的。

这个 skill 会生成代码吗？

不会，而且这是刻意为之。brainstorming skill 的职责就是在拿到批准前停在实现之前。如果你需要代码生成，更合适的方式是：先用这个 skill 完成澄清和设计，再在批准后交给 planning 或 implementation skill。

不用 visual companion，也有价值吗？

有。浏览器路径是可选的。即便只用文本，brainstorming 在需求澄清、范围界定和技术取舍讨论上，也能提供大部分价值。视觉工具真正重要的场景，是“决策本身就是视觉性的”。

如何改进 brainstorming skill 的使用效果

给 brainstorming skill 更多真实的项目上下文

想最快提升效果，最有效的方法就是让讨论更贴近现实：

• 相关文件或目录
• 当前已有行为
• 最近的改动
• 已知技术约束
• 受影响的用户

这个 skill 本身就要求 agent 先探索项目上下文。你可以进一步帮它，把上下文所在的位置直接点出来。

尽早说清楚约束和非目标

很多不够好的 brainstorming 输出，问题都出在边界条件不明确。要尽早告诉这个 skill 哪些东西必须保留、哪些东西不能碰：

• 向后兼容性
• 性能上限
• 合规或安全要求
• 时间线或人力限制
• 明确不在范围内的功能

这样产出的设计会更聚焦，也更适合拿来做决策。

要求它产出设计，而不只是想法

如果你希望最后拿到的是“可进入实现”的结果，那就把要求说清楚。可以直接让 brainstorming skill 以这些内容收尾：

• 一个 proposed design
• 明确列出的 assumptions
• 尚未解决的问题
• 一个显式的 approval checkpoint

这会把会话从无休止的发散，拉回到真正可使用的产物上。

做视觉 brainstorming 时，prompt 要更具体

如果是视觉类工作，不要只说“show mockups”。要明确说明视觉输出要比较什么：

Show two dashboard layout options for failed import alerts: one optimized for fast triage, one optimized for detail review. Keep the existing navigation shell. Highlight which option better supports keyboard-heavy operators.

这类 prompt 能帮助 visual companion 产出更适合决策的结果，而不是只做一些好看但缺乏判断价值的界面。

留意最常见的失败模式：过早进入解法

这个 skill 最大的失败模式，就是在问题还没真正理解清楚前，就过早跳进实现细节。如果出现这种情况，可以这样把会话拉回来：

Pause implementation thinking. What assumptions are we making about the user workflow, edge cases, and scope boundaries?

这样能让 brainstorming 指南重新对齐它的核心目的。

用一轮复审来提升第一次输出

拿到初版设计后，最好做一次有针对性的修订，而不是从头重来。可以追问：

• 哪里仍然模糊？
• 哪里设计过度了？
• 哪些地方会影响实现规划？
• 为了获得批准，还缺了什么？

这里仓库中的 spec-document-reviewer-prompt.md 很有用，因为它关注的是会真实阻碍规划推进的问题，而不是表面的文字润色。

让 brainstorming 产物保持精简，但足以支撑决策

一个常见错误，是把设计文档越写越大，塞进很多其实不必要的细节。更好的 brainstorming 不是更长的 brainstorming。对于简单任务，几段紧凑文字，清楚覆盖目的、范围、约束、方案和批准点，往往就够了。衡量标准不是文档长度，而是下一步能否在更少猜测的前提下推进。

把 brainstorming 和 spec review 串起来

如果你准备认真把这个 skill 纳入流程，最好把它和后续的 spec 或设计复审结合起来。仓库里附带的 reviewer template 会检查：

• placeholders
• contradictions
• ambiguous requirements
• over-broad scope
• unrequested complexity

这样，brainstorming skill 就不只是“聊天时帮你理一理思路”，而是能真正嵌入实际交付流程的一环。