菜单
Before any creative work — creating features, building components, adding capabilities, or modifying behavior — you must use this skill. Explore user intent, requirements, and design before implementation.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when executing implementation plans with independent tasks in the current session
Use when implementing any feature or bug fix, before writing implementation code
Use when creating new skills, editing existing skills, or verifying skills work before deployment
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
| name | brainstorming |
| description | Before any creative work — creating features, building components, adding capabilities, or modifying behavior — you must use this skill. Explore user intent, requirements, and design before implementation. |
通过自然协作对话帮助将想法转化为完全形成的设计和规格。
首先了解当前项目上下文，然后一次一个地提问来完善想法。一旦理解了你正在构建的内容，呈现设计并获得用户批准。
在呈现设计并获得用户批准之前，**不要**调用任何实施技能、编写任何代码、搭建任何项目或采取任何实施行动。这适用于**每个**项目，无论感知到的简单性如何。每个项目都要经过这个过程。待办事项列表、单功能实用程序、配置更改——所有这些。"简单"项目是未检查的假设造成最多浪费工作的地方。设计可以是短的（对于真正简单的项目只需几句话），但你必须呈现它并获得批准。
你必须为每个项目创建一个任务并按顺序完成：
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 并提交digraph brainstorming {
"探索项目上下文" [shape=box];
"有视觉问题吗？" [shape=diamond];
"提供视觉助手\n（自己的消息，无其他内容）" [shape=box];
"提出澄清问题" [shape=box];
"提出 2-3 种方法" [shape=box];
"呈现设计章节" [shape=box];
"用户批准设计？" [shape=diamond];
"编写设计文档" [shape=box];
"规格自检\n（内联修复）" [shape=box];
"用户审核规格？" [shape=diamond];
"调用 writing-plans 技能" [shape=doublecircle];
"探索项目上下文" -> "有视觉问题吗？";
"有视觉问题吗？" -> "提供视觉助手\n（自己的消息，无其他内容）" [label="是"];
"有视觉问题吗？" -> "提出澄清问题" [label="否"];
"提供视觉助手\n（自己的消息，无其他内容）" -> "提出澄清问题";
"提出澄清问题" -> "提出 2-3 种方法";
"提出 2-3 种方法" -> "呈现设计章节";
"呈现设计章节" -> "用户批准设计？";
"用户批准设计？" -> "呈现设计章节" [label="否，修改"];
"用户批准设计？" -> "编写设计文档" [label="是"];
"编写设计文档" -> "规格自检\n（内联修复）";
"规格自检\n（内联修复）" -> "用户审核规格？";
"用户审核规格？" -> "编写设计文档" [label="需要更改"];
"用户审核规格？" -> "调用 writing-plans 技能" [label="已批准"];
}
终止状态是调用 writing-plans。 不要调用 frontend-design、mcp-builder 或任何其他实施技能。brainstorming 后唯一调用的技能是 writing-plans。
理解想法：
探索方法：
呈现设计：
为隔离和清晰度设计：
在现有代码库中工作：
文档：
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md
-（用户对规格位置的偏好覆盖此默认值）规格自检： 编写规格文档后，用新的眼光看待它：
内联修复任何问题。不需要重新审查——只需修复并继续。
用户审核门： 规格审查循环通过后，要求用户在继续之前审核书面规格：
"规格已写入并提交到
<path>。请审核它，并告诉我是否想在开始编写实施计划之前做任何更改。"
等待用户的响应。如果他们请求更改，进行更改并重新运行规格审查循环。只有在用户批准后才能继续。
实施：
一个基于浏览器的伴侣，用于在头脑风暴期间显示模型、图表和视觉选项。作为工具可用——不是一种模式。接受伴侣意味着它可用于受益于视觉处理的问题；它不意味着每个问题都通过浏览器。
提供伴侣： 当你预计即将到来的问题将涉及视觉内容（模型、布局、图表）时，提供一次以获得同意：
"如果我们能在网页浏览器中向您展示一些东西，可能更容易解释。我可以在我们进行时组合模型、图表、比较和其他视觉效果。这个功能仍然是新的，可能会消耗大量 tokens。想试试吗？（需要打开本地 URL）"
这个提议必须是它自己的消息。 不要将其与澄清问题、上下文摘要或任何其他内容合并。消息应仅包含上述提议，别无其他。等待用户的响应后再继续。如果他们拒绝，继续纯文本头脑风暴。
每个问题的决定： 即使用户接受了，也要为每个问题决定是使用浏览器还是终端。测试：用户通过看它比读它更好地理解吗？
关于 UI 主题的问题不自动是视觉问题。"在这个上下文中，个性意味着什么？"是一个概念问题——使用终端。"哪个向导布局更好？"是一个视觉问题——使用浏览器。
如果他们同意伴侣，在继续之前阅读详细指南：
skills/brainstorming/visual-companion.md