brainstorming

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

头脑风暴：将想法转化为设计

Brainstorming: Turning Ideas into Designs

通过自然的协作对话，帮助将想法转化为完整的设计和规格说明。

首先了解当前项目的上下文，然后逐一提问来完善想法。一旦你理解了要构建的内容，就展示设计方案并获得用户批准。

<HARD-GATE> 在你展示设计方案并获得用户批准之前，不要调用任何实现技能、编写任何代码、搭建任何项目或采取任何实现行动。这适用于所有项目，无论看起来多简单。 </HARD-GATE>

Through natural collaborative dialogue, help turn ideas into complete designs and specifications.

First understand the context of the current project, then ask questions one by one to refine the idea. Once you understand what needs to be built, present the design solution and obtain user approval.

<HARD-GATE> Do not call any implementation skills, write any code, set up any projects, or take any implementation actions until you have presented the design solution and obtained user approval. This applies to all projects, no matter how simple they seem. </HARD-GATE>

反模式："这个太简单了，不需要设计"

Anti-pattern: "This is too simple, no design needed"

每个项目都要经过这个流程。一个待办事项列表、一个单函数工具、一个配置变更——全都需要。"简单"的项目恰恰是未经检验的假设造成最多浪费的地方。设计可以很简短（对于真正简单的项目几句话就够了），但你必须展示出来并获得批准。

Every project must go through this process. A to-do list, a single-function tool, a configuration change—all require it. "Simple" projects are precisely where untested assumptions cause the most waste. The design can be brief (a few sentences for truly simple projects), but you must present it and get approval.

检查清单

Checklist

你必须为以下每个条目创建任务，并按顺序完成：

探索项目上下文 — 检查文件、文档、最近的 commit
提供视觉伴侣（如果主题涉及视觉问题）— 这是一条独立的消息，不要与澄清问题合并。参见下方的"视觉伴侣"部分。
提出澄清问题 — 每次一个，了解目的/约束/成功标准
提出 2-3 种方案 — 附带权衡分析和你的推荐
展示设计 — 按复杂度分节展示，每节展示后获得用户批准

编写设计文档 — 保存到

docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md

并 commit

规格自检 — 快速内联检查占位符、矛盾、模糊性、范围（详见下方）
用户审查书面规格 — 在继续之前请用户审查规格文件
过渡到实现 — 调用 writing-plans 技能创建实现计划

You must create tasks for each of the following items and complete them in order:

Explore Project Context — Check files, documents, recent commits
Provide Visual Companion (if the topic involves visual issues) — This is a separate message, do not combine with clarification questions. See the "Visual Companion" section below.
Ask Clarification Questions — One at a time, understand the purpose/constraints/success criteria
Propose 2-3 Solutions — With trade-off analysis and your recommendation
Present Design — Present in sections by complexity, obtain user approval after each section

Write Design Document — Save to

docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md

and commit

Specification Self-Check — Quick inline check for placeholders, contradictions, ambiguity, scope (details below)
User Review of Written Specification — Ask the user to review the specification document before proceeding
Transition to Implementation — Call the writing-plans skill to create an implementation plan

流程图

Flowchart

dot

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 或任何其他实现技能。头脑风暴之后你唯一要调用的技能是 writing-plans。

dot

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="批准"];
}

The termination state is calling writing-plans. Do not call frontend-design, mcp-builder, or any other implementation skills. The only skill you should call after brainstorming is writing-plans.

流程详述

Process Details

理解想法：

首先查看当前项目状态（文件、文档、最近的 commit）
在提出详细问题之前，先评估范围：如果需求描述了多个独立子系统（例如"构建一个包含聊天、文件存储、计费和分析的平台"），立即指出这一点。不要花时间用问题去细化一个需要先拆分的项目。
如果项目规模过大，单个规格说明无法覆盖，帮助用户分解为子项目：有哪些独立的部分，它们之间有什么关系，应该按什么顺序构建？然后通过正常的设计流程进行第一个子项目的头脑风暴。每个子项目都有自己的规格 → 计划 → 实现周期。
对于范围适当的项目，每次提一个问题来完善想法
尽量使用选择题，开放式问题也可以
每条消息只提一个问题——如果一个主题需要更多探索，拆分成多个问题
重点理解：目的、约束、成功标准

探索方案：

提出 2-3 种不同的方案及其权衡
以对话的方式展示选项，附上你的推荐和理由
先展示你推荐的方案并解释原因

展示设计：

一旦你认为理解了要构建的内容，就展示设计
每个部分的篇幅与其复杂度匹配：简单的几句话，复杂的最多 200-300 字
每个部分展示后询问是否正确
涵盖：架构、组件、数据流、错误处理、测试
随时准备回头澄清不明确的地方

面向隔离和清晰的设计：

将系统拆分为更小的单元，每个单元有一个明确的职责，通过定义良好的接口通信，可以独立理解和测试
对于每个单元，你应该能回答：它做什么，如何使用，它依赖什么？
别人能否不看内部实现就理解一个单元的功能？你能否在不影响调用者的情况下修改内部实现？如果不能，边界需要调整。
更小、边界清晰的单元也更便于你工作——你对能一次放入上下文的代码推理得更好，文件越专注你的编辑越可靠。当文件变大时，这通常意味着它承担了过多职责。

在现有代码库中工作：

在提出更改之前先探索现有结构。遵循现有模式。
如果现有代码存在影响当前工作的问题（例如文件过大、边界不清、职责纠缠），在设计中包含有针对性的改进——就像一个优秀的开发者在工作中改进经手的代码一样。
不要提议无关的重构。专注于服务当前目标的事情。

Understanding the Idea:

First check the current project status (files, documents, recent commits)
Before asking detailed questions, assess the scope: if the requirements describe multiple independent subsystems (e.g., "Build a platform with chat, file storage, billing, and analytics"), point this out immediately. Do not spend time refining a project that needs to be split first with questions.
If the project is too large to be covered by a single specification, help the user break it down into sub-projects: what are the independent parts, what is the relationship between them, and in what order should they be built? Then brainstorm the first sub-project through the normal design process. Each sub-project has its own specification → plan → implementation cycle.
For projects with appropriate scope, ask one question at a time to refine the idea
Try to use multiple-choice questions; open-ended questions are also acceptable
Only ask one question per message—if a topic requires more exploration, split it into multiple questions
Focus on understanding: purpose, constraints, success criteria

Exploring Solutions:

Propose 2-3 different solutions and their trade-offs
Present options in a conversational manner, with your recommendation and reasons
Present your recommended solution first and explain why

Presenting the Design:

Once you think you understand what needs to be built, present the design
The length of each section matches its complexity: a few sentences for simple parts, up to 200-300 words for complex parts
After presenting each section, ask if it is correct
Cover: architecture, components, data flow, error handling, testing
Be ready to go back and clarify ambiguous points at any time

Design for Isolation and Clarity:

Split the system into smaller units, each with a clear responsibility, communicating through well-defined interfaces, which can be understood and tested independently
For each unit, you should be able to answer: what does it do, how to use it, what does it depend on?
Can others understand the function of a unit without looking at its internal implementation? Can you modify the internal implementation without affecting the caller? If not, the boundaries need to be adjusted.
Smaller, clearly bounded units also make your work easier—you reason better about code that fits into context at once, and your edits are more reliable when files are focused. When a file grows large, it usually means it is taking on too many responsibilities.

Working in Existing Codebases:

Explore the existing structure before proposing changes. Follow existing patterns.
If there are issues in the existing code that affect the current work (e.g., overly large files, unclear boundaries, tangled responsibilities), include targeted improvements in the design—just like a good developer improves the code they work on.
Do not propose unrelated refactoring. Focus on things that serve the current goal.

设计之后

After Design

文档：

将验证通过的设计（规格说明）写入
```
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md
```
- （用户对规格位置的偏好优先于此默认值）
如果可用，使用 elements-of-style:writing-clearly-and-concisely 技能
将设计文档 commit 到 git

规格自检： 编写规格文档后，以全新的视角审视它：

占位符扫描： 有没有"待定"、"TODO"、未完成的章节或模糊的需求？修复它们。
内部一致性： 各章节之间有矛盾吗？架构和功能描述匹配吗？
范围检查： 这是否聚焦到可以用一个实现计划覆盖，还是需要进一步拆分？
模糊性检查： 有没有需求可以被两种方式理解？如果有，选择一种并明确写出来。

发现问题就直接内联修复。无需重新审查——修好继续推进。

用户审查关卡： 规格自检完成后，请用户在继续之前审查书面规格：

"规格已编写并 commit 到
<path>
。请审查一下，如果在我们开始编写实现计划之前你想做任何修改，请告诉我。"

等待用户回复。如果他们要求修改，做出修改并重新运行规格自检。只有在用户批准后才继续。

实现：

调用 writing-plans 技能创建详细的实现计划
不要调用任何其他技能。writing-plans 是下一步。

Documentation:

Write the validated design (specification) to
```
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md
```
- (User preferences for specification location take precedence over this default)
If available, use the elements-of-style:writing-clearly-and-concisely skill
Commit the design document to git

Specification Self-Check: After writing the specification document, review it with a fresh perspective:

Placeholder Scan: Are there "TBD", "TODO", unfinished sections, or vague requirements? Fix them.
Internal Consistency: Are there contradictions between sections? Do the architecture and functional descriptions match?
Scope Check: Is this focused enough to be covered by one implementation plan, or does it need further splitting?
Ambiguity Check: Are there requirements that can be interpreted in two ways? If so, choose one and write it clearly.

Fix any issues found directly inline. No need for re-review—fix and proceed.

User Review Gate: After completing the specification self-check, ask the user to review the written specification before proceeding:

"The specification has been written and committed to
<path>
. Please review it and let me know if you want to make any changes before we start writing the implementation plan."

Wait for the user's reply. If they request changes, make the changes and re-run the specification self-check. Only proceed after user approval.

Implementation:

Call the writing-plans skill to create a detailed implementation plan
Do not call any other skills. writing-plans is the next step.

核心原则

Core Principles

每次一个问题 — 不要同时抛出多个问题
优先选择题 — 在可能的情况下比开放式问题更容易回答
严格遵循 YAGNI — 从所有设计中移除不必要的功能
探索替代方案 — 在做决定之前始终提出 2-3 种方案
增量验证 — 展示设计，获得批准后再继续
保持灵活 — 有不明确的地方就回头澄清

One Question at a Time — Do not throw multiple questions at once
Prioritize Multiple-Choice Questions — Easier to answer than open-ended questions when possible
Strictly Follow YAGNI — Remove unnecessary features from all designs
Explore Alternatives — Always propose 2-3 solutions before making a decision
Incremental Validation — Present the design and obtain approval before proceeding
Stay Flexible — Go back and clarify ambiguous points when they arise

视觉伴侣

Visual Companion

一个基于浏览器的伴侣工具，用于在头脑风暴过程中展示原型、图表和视觉选项。它是一个工具——不是一种模式。接受伴侣意味着它可用于适合视觉呈现的问题；并不意味着每个问题都要通过浏览器。

提供伴侣： 当你预计后续问题会涉及视觉内容（原型、布局、图表）时，提供一次以获得同意：

"我们接下来讨论的一些内容，如果能在浏览器中展示给你看可能会更直观。我可以在讨论过程中为你制作原型、图表、对比图和其他视觉材料。这个功能还比较新，可能会消耗较多 token。要试试吗？（需要打开一个本地 URL）"

此提议必须是一条独立的消息。 不要将它与澄清问题、上下文摘要或任何其他内容合并。消息中应该只包含上述提议，没有其他内容。等待用户回复后再继续。如果他们拒绝，继续纯文本的头脑风暴。

逐问题决策： 即使用户接受了，也要对每个问题单独决定是使用浏览器还是终端。判断标准：用户看到它是否比读到它更容易理解？

使用浏览器 展示本身就是视觉的内容——原型、线框图、布局对比、架构图、并排视觉设计
使用终端 展示文本内容——需求问题、概念选择、权衡列表、A/B/C/D 文字选项、范围决策

关于 UI 主题的问题不一定是视觉问题。"在这个上下文中个性化是什么意思？"是一个概念问题——使用终端。"哪种向导布局更好？"是一个视觉问题——使用浏览器。

如果他们同意使用伴侣，在继续之前阅读详细指南：

skills/brainstorming/visual-companion.md

A browser-based companion tool for displaying prototypes, diagrams, and visual options during the brainstorming process. It is a tool—not a pattern. Accepting the companion means it can be used for issues suitable for visual presentation; it does not mean every issue must go through the browser.

Providing the Companion: When you anticipate that subsequent questions will involve visual content (prototypes, layouts, diagrams), offer it once to get consent:

"Some of the content we'll discuss next might be more intuitive if shown to you in a browser. I can create prototypes, diagrams, comparison charts, and other visual materials for you during the discussion. This feature is relatively new and may consume more tokens. Would you like to try it? (Requires opening a local URL)"

This offer must be a separate message. Do not combine it with clarification questions, context summaries, or any other content. The message should only contain the above offer, nothing else. Wait for the user's reply before proceeding. If they decline, continue with text-only brainstorming.

Per-Question Decision: Even if the user accepts, decide individually for each question whether to use the browser or terminal. The criterion: Is it easier for the user to understand by seeing it rather than reading it?

Use Browser to display content that is inherently visual—prototypes, wireframes, layout comparisons, architecture diagrams, side-by-side visual designs
Use Terminal to display text-based content—requirement questions, concept choices, trade-off lists, A/B/C/D text options, scope decisions

Questions about UI topics are not necessarily visual. "What does personalization mean in this context?" is a conceptual question—use terminal. "Which wizard layout is better?" is a visual question—use browser.

If they agree to use the companion, read the detailed guide before proceeding:

skills/brainstorming/visual-companion.md