brainstorming by obra/superpowers
npx skills add https://github.com/obra/superpowers --skill brainstorming通过自然的协作对话,帮助将想法转化为完整的设计和规范。
首先了解当前项目背景,然后逐一提问以完善想法。一旦理解了要构建的内容,就呈现设计并获得用户批准。
每个项目都要经历这个过程。待办事项列表、单一功能工具、配置变更——所有项目都是如此。"简单"的项目往往因为未经审视的假设而造成最多的工作浪费。设计可以简短(对于真正简单的项目只需几句话),但你必须呈现它并获得批准。
你必须为以下每一项创建一个任务,并按顺序完成它们:
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 并提交digraph brainstorming {
"Explore project context" [shape=box];
"Visual questions ahead?" [shape=diamond];
"Offer Visual Companion\n(own message, no other content)" [shape=box];
"Ask clarifying questions" [shape=box];
"Propose 2-3 approaches" [shape=box];
"Present design sections" [shape=box];
"User approves design?" [shape=diamond];
"Write design doc" [shape=box];
"Spec review loop" [shape=box];
"Spec review passed?" [shape=diamond];
"User reviews spec?" [shape=diamond];
"Invoke writing-plans skill" [shape=doublecircle];
"Explore project context" -> "Visual questions ahead?";
"Visual questions ahead?" -> "Offer Visual Companion\n(own message, no other content)" [label="yes"];
"Visual questions ahead?" -> "Ask clarifying questions" [label="no"];
"Offer Visual Companion\n(own message, no other content)" -> "Ask clarifying questions";
"Ask clarifying questions" -> "Propose 2-3 approaches";
"Propose 2-3 approaches" -> "Present design sections";
"Present design sections" -> "User approves design?";
"User approves design?" -> "Present design sections" [label="no, revise"];
"User approves design?" -> "Write design doc" [label="yes"];
"Write design doc" -> "Spec review loop";
"Spec review loop" -> "Spec review passed?";
"Spec review passed?" -> "Spec review loop" [label="issues found,\nfix and re-dispatch"];
"Spec review passed?" -> "User reviews spec?" [label="approved"];
"User reviews spec?" -> "Write design doc" [label="changes requested"];
"User reviews spec?" -> "Invoke writing-plans skill" [label="approved"];
}
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
终端状态是调用 writing-plans。 在头脑风暴之后,不要调用 frontend-design、mcp-builder 或任何其他实施技能。你调用的唯一技能是 writing-plans。
理解想法:
探索方案:
呈现设计:
为隔离性和清晰性而设计:
在现有代码库中工作:
文档:
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md
规范审查循环: 编写规范文档后:
用户审查关口: 在规范审查循环通过后,请用户在继续之前审查书面规范:
"规范已编写并提交到
<路径>。请在开始编写实施计划之前审查它,并告知我你是否希望进行任何更改。"
等待用户的回应。如果他们要求更改,进行更改并重新运行规范审查循环。只有在用户批准后才能继续。
实施:
一个基于浏览器的伴侣,用于在头脑风暴期间展示线框图、图表和视觉选项。作为工具提供 —— 不是模式。接受伴侣意味着它可用于那些受益于视觉处理的问题;这不意味着每个问题都要通过浏览器进行。
提供伴侣: 当你预计即将到来的问题会涉及视觉内容(线框图、布局、图表)时,提供一次以征得同意:
"我们正在处理的一些内容,如果我能通过网页浏览器展示给你看,可能会更容易解释。我可以在过程中整理线框图、图表、比较和其他视觉效果。这个功能还很新,可能会消耗较多 token。想试试吗?(需要打开本地 URL)"
此提议必须是独立的消息。 不要将其与澄清问题、背景摘要或任何其他内容合并。该消息应仅包含上述提议,别无其他。等待用户的回应后再继续。如果他们拒绝,则继续进行纯文本头脑风暴。
按问题决定: 即使用户接受了,也要为每个问题决定是使用浏览器还是终端。判断标准是:用户通过看这个内容比读它理解得更好吗?
关于 UI 主题的问题并不自动成为视觉问题。"在这种情况下,'个性'意味着什么?"是一个概念性问题 —— 使用终端。"哪个向导布局效果更好?"是一个视觉问题 —— 使用浏览器。
如果他们同意使用伴侣,请先阅读详细指南再继续:skills/brainstorming/visual-companion.md
每周安装量
71.3K
仓库
GitHub 星标数
110.3K
首次出现
2026年1月19日
安全审计
安装于
opencode60.2K
gemini-cli58.4K
codex58.3K
github-copilot55.8K
kimi-cli52.2K
amp52.1K
Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.
Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.
You MUST create a task for each of these items and complete them in order:
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md and commitdigraph brainstorming {
"Explore project context" [shape=box];
"Visual questions ahead?" [shape=diamond];
"Offer Visual Companion\n(own message, no other content)" [shape=box];
"Ask clarifying questions" [shape=box];
"Propose 2-3 approaches" [shape=box];
"Present design sections" [shape=box];
"User approves design?" [shape=diamond];
"Write design doc" [shape=box];
"Spec review loop" [shape=box];
"Spec review passed?" [shape=diamond];
"User reviews spec?" [shape=diamond];
"Invoke writing-plans skill" [shape=doublecircle];
"Explore project context" -> "Visual questions ahead?";
"Visual questions ahead?" -> "Offer Visual Companion\n(own message, no other content)" [label="yes"];
"Visual questions ahead?" -> "Ask clarifying questions" [label="no"];
"Offer Visual Companion\n(own message, no other content)" -> "Ask clarifying questions";
"Ask clarifying questions" -> "Propose 2-3 approaches";
"Propose 2-3 approaches" -> "Present design sections";
"Present design sections" -> "User approves design?";
"User approves design?" -> "Present design sections" [label="no, revise"];
"User approves design?" -> "Write design doc" [label="yes"];
"Write design doc" -> "Spec review loop";
"Spec review loop" -> "Spec review passed?";
"Spec review passed?" -> "Spec review loop" [label="issues found,\nfix and re-dispatch"];
"Spec review passed?" -> "User reviews spec?" [label="approved"];
"User reviews spec?" -> "Write design doc" [label="changes requested"];
"User reviews spec?" -> "Invoke writing-plans skill" [label="approved"];
}
The terminal state is invoking writing-plans. Do NOT invoke frontend-design, mcp-builder, or any other implementation skill. The ONLY skill you invoke after brainstorming is writing-plans.
Understanding the idea:
Exploring approaches:
Presenting the design:
Design for isolation and clarity:
Working in existing codebases:
Documentation:
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md
Spec Review Loop: After writing the spec document:
User Review Gate: After the spec review loop passes, ask the user to review the written spec before proceeding:
"Spec written and committed to
<path>. Please review it and let me know if you want to make any changes before we start writing out the implementation plan."
Wait for the user's response. If they request changes, make them and re-run the spec review loop. Only proceed once the user approves.
Implementation:
A browser-based companion for showing mockups, diagrams, and visual options during brainstorming. Available as a tool — not a mode. Accepting the companion means it's available for questions that benefit from visual treatment; it does NOT mean every question goes through the browser.
Offering the companion: When you anticipate that upcoming questions will involve visual content (mockups, layouts, diagrams), offer it once for consent:
"Some of what we're working on might be easier to explain if I can show it to you in a web browser. I can put together mockups, diagrams, comparisons, and other visuals as we go. This feature is still new and can be token-intensive. Want to try it? (Requires opening a local URL)"
This offer MUST be its own message. Do not combine it with clarifying questions, context summaries, or any other content. The message should contain ONLY the offer above and nothing else. Wait for the user's response before continuing. If they decline, proceed with text-only brainstorming.
Per-question decision: Even after the user accepts, decide FOR EACH QUESTION whether to use the browser or the terminal. The test: would the user understand this better by seeing it than reading it?
A question about a UI topic is not automatically a visual question. "What does personality mean in this context?" is a conceptual question — use the terminal. "Which wizard layout works better?" is a visual question — use the browser.
If they agree to the companion, read the detailed guide before proceeding: skills/brainstorming/visual-companion.md
Weekly Installs
71.3K
Repository
GitHub Stars
110.3K
First Seen
Jan 19, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
opencode60.2K
gemini-cli58.4K
codex58.3K
github-copilot55.8K
kimi-cli52.2K
amp52.1K
99,500 周安装