Menu
在任何创造性工作之前必须使用此技能——创建功能、构建组件、添加功能或修改行为。在实现之前先探索用户意图、需求和设计。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | brainstorming |
| description | 在任何创造性工作之前必须使用此技能——创建功能、构建组件、添加功能或修改行为。在实现之前先探索用户意图、需求和设计。 |
| version | 1.0.0 |
| license | MIT |
| metadata | {"hermes":{"tags":["design","planning"]}} |
通过自然的协作对话，帮助将想法转化为完整的设计和规格说明。
首先了解当前项目的上下文，然后逐一提问来完善想法。一旦你理解了要构建的内容，就展示设计方案并获得用户批准。
在你展示设计方案并获得用户批准之前，不要调用任何实现技能、编写任何代码、搭建任何项目或采取任何实现行动。这适用于所有项目，无论看起来多简单。每个项目都要经过这个流程。一个待办事项列表、一个单函数工具、一个配置变更——全都需要。"简单"的项目恰恰是未经检验的假设造成最多浪费的地方。设计可以很简短（对于真正简单的项目几句话就够了），但你必须展示出来并获得批准。
你必须为以下每个条目创建任务，并按顺序完成：
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 并 commitdigraph 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 或任何其他实现技能。头脑风暴之后你唯一要调用的技能是 writing-plans。
理解想法：
探索方案：
展示设计：
面向隔离和清晰的设计：
在现有代码库中工作：
文档：
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md
规格自检： 编写规格文档后，以全新的视角审视它：
发现问题就直接内联修复。无需重新审查——修好继续推进。
用户审查关卡： 规格自检完成后，请用户在继续之前审查书面规格：
"规格已编写并 commit 到
<path>。请审查一下，如果在我们开始编写实现计划之前你想做任何修改，请告诉我。"
等待用户回复。如果他们要求修改，做出修改并重新运行规格自检。只有在用户批准后才继续。
实现：
一个基于浏览器的伴侣工具，用于在头脑风暴过程中展示原型、图表和视觉选项。它是一个工具——不是一种模式。接受伴侣意味着它可用于适合视觉呈现的问题；并不意味着每个问题都要通过浏览器。
提供伴侣： 当你预计后续问题会涉及视觉内容（原型、布局、图表）时，提供一次以获得同意：
"我们接下来讨论的一些内容，如果能在浏览器中展示给你看可能会更直观。我可以在讨论过程中为你制作原型、图表、对比图和其他视觉材料。这个功能还比较新，可能会消耗较多 token。要试试吗？（需要打开一个本地 URL）"
此提议必须是一条独立的消息。 不要将它与澄清问题、上下文摘要或任何其他内容合并。消息中应该只包含上述提议，没有其他内容。等待用户回复后再继续。如果他们拒绝，继续纯文本的头脑风暴。
逐问题决策： 即使用户接受了，也要对每个问题单独决定是使用浏览器还是终端。判断标准：用户看到它是否比读到它更容易理解？
关于 UI 主题的问题不一定是视觉问题。"在这个上下文中个性化是什么意思？"是一个概念问题——使用终端。"哪种向导布局更好？"是一个视觉问题——使用浏览器。
如果他们同意使用伴侣，在继续之前阅读详细指南：
skills/brainstorming/visual-companion.md
当你有一份书面实现计划需要在单独的会话中执行，并设有审查检查点时使用
在开始任何对话时使用——确立如何查找和使用技能，要求在任何响应（包括澄清性问题）之前调用 Skill 工具
当实现完成、所有测试通过、需要决定如何集成工作时使用——通过提供合并、PR 或清理等结构化选项来引导开发工作的收尾
当需要开始与当前工作区隔离的功能开发，或在执行实现计划之前使用——通过原生工具或 git worktree 回退机制确保隔离工作区存在
中文 review 沟通参考——话术模板、分级标注（必须修复/建议修改/仅供参考）、国内团队常见反模式应对。仅在用户显式 /chinese-code-review 时调用，不要根据上下文自动触发。
中文 commit 与 changelog 配置参考——Conventional Commits 中文适配、commitlint/husky/commitizen 中文模板、conventional-changelog 中文配置。仅在用户显式 /chinese-commit-conventions 时调用，不要根据上下文自动触发。