The Agent Skills Directory
npx skills add https://smithery.ai/skills/obra/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"];
}
最终状态是调用 writing-plans。 在头脑风暴之后不要调用 frontend-design、mcp-builder 或任何其他实施技能。头脑风暴后调用的唯一技能是 writing-plans。
理解想法:
探索方法:
呈现设计:
为隔离和清晰性设计:
在现有代码库中工作:
文档:
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md
规格审查循环: 编写规格文档后:
用户审查关卡: 规格审查循环通过后,请用户在继续之前审查书面规格:
"规格已编写并提交到
<路径>。请在开始制定实施计划之前审查它,并告诉我您是否希望进行任何更改。"
等待用户的回应。如果他们要求更改,进行更改并重新运行规格审查循环。只有在用户批准后才继续。
实施:
一个基于浏览器的伴侣,用于在头脑风暴期间展示模型、图表和视觉选项。作为工具提供 - 不是模式。接受伴侣意味着它可用于受益于视觉处理的问题;这不意味着每个问题都通过浏览器进行。
提供伴侣: 当您预计即将出现的问题会涉及视觉内容(模型、布局、图表)时,提供一次以获得同意:
"我们正在处理的一些内容,如果我能通过网页浏览器向您展示,可能会更容易解释。我可以逐步准备模型、图表、比较和其他视觉内容。这个功能仍然是新的,可能会消耗较多令牌。想试试吗?(需要打开本地URL)"
此提供必须是独立的消息。 不要将其与澄清问题、背景摘要或任何其他内容合并。消息应仅包含上述提供内容,没有其他内容。等待用户的回应后再继续。如果他们拒绝,继续进行纯文本头脑风暴。
每个问题的决定: 即使用户接受后,也要为每个问题决定是使用浏览器还是终端。测试标准:用户通过看到它比阅读它更能理解吗?
关于UI主题的问题不自动成为视觉问题。"在这种情况下个性意味着什么?"是概念问题 - 使用终端。"哪个向导布局更好?"是视觉问题 - 使用浏览器。
如果他们同意使用伴侣,请在继续之前阅读详细指南:skills/brainstorming/visual-companion.md
每周安装
70
来源
首次出现
2026年3月6日
安全审计
安装于
claude-code38
codex20
opencode11
gemini-cli11
cursor11
antigravity8
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 commit广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
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"];
}
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
70
Source
First Seen
Mar 6, 2026
Security Audits
Installed on
claude-code38
codex20
opencode11
gemini-cli11
cursor11
antigravity8
推荐与联盟计划设计优化指南:病毒式增长营销策略、客户推荐计划、联盟营销
31,000 周安装
GitHub Copilot create-readme:AI自动生成专业README文档工具
9,600 周安装
React Native 最佳实践与性能优化指南 | 提升应用FPS、启动速度与包体积
9,600 周安装
Web无障碍性(a11y)指南:WCAG 2.1原则、Lighthouse审计与代码实践
10,500 周安装
Vue Router 最佳实践指南:导航守卫、路由生命周期与常见陷阱解决方案
9,900 周安装
SEO优化指南:技术性SEO、页面优化与结构化数据实践
10,700 周安装
设计工程指南:构建卓越用户界面的品味、细节与动画决策框架
11,800 周安装