name: brainstorming
description: 在进行任何创意工作（如创建功能、构建组件、添加功能或修改行为）之前，你必须使用此方法。在实施之前，需先探索用户意图、需求和设计。

将创意构思转化为设计方案

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

首先了解当前项目背景，然后逐一提问以完善想法。一旦明确你要构建的内容，展示设计方案并获取用户批准。

<HARD-GATE>

在展示设计方案并获得用户批准之前，不得调用任何实现技能、编写任何代码、搭建任何项目或采取任何实施行动。这一点适用于每个项目，无论其看似多么简单。

</HARD-GATE>

反模式：“这太简单了，不需要设计”

每个项目都需经历此流程。待办事项清单、单一功能工具、配置变更——无一例外。正是那些“简单”项目，未被检视的假设会造成最多的无效工作。设计方案可以很短（对于真正简单的项目只需几句话），但你必须展示并获取批准。

检查清单

你必须为以下每项创建任务并按顺序完成：

1. 探索项目背景 —— 检查文件、文档、最近的提交
2. 适时提供视觉伴侣 —— 不要提前提供。当某个问题通过展示比描述更清晰时，才在该时刻提供（单独一条消息）；一旦批准，浏览器标签页会为你打开。如果从未出现需要视觉的问题，则永远不要提供。请参见下方“视觉伴侣”部分。
3. 提出澄清性问题 —— 逐一提问，理解目的、约束条件和成功标准
4. 提出 2-3 种方案 —— 附带权衡因素和你的推荐
5. 展示设计方案 —— 按各部分的复杂程度缩放，每部分获取用户批准
6. 编写设计文档 —— 保存至 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 并提交
7. 规格自审 —— 快速内联检查占位符、矛盾点、歧义、范围（见下方）
8. 用户审查书面规格 —— 在继续之前请用户审查规格文件
9. 过渡到实现 —— 调用 writing-plans 技能创建实现计划

流程

digraph brainstorming {
    "探索项目背景" [shape=box];
    "提出澄清性问题" [shape=box];
    "提出 2-3 种方案" [shape=box];
    "展示设计方案各部分" [shape=box];
    "用户批准设计？" [shape=diamond];
    "编写设计文档" [shape=box];
    "规格自审\n(内联修正)" [shape=box];
    "用户审查规格？" [shape=diamond];
    "调用 writing-plans 技能" [shape=doublecircle];

    "探索项目背景" -> "提出澄清性问题";
    "提出澄清性问题" -> "提出 2-3 种方案";
    "提出 2-3 种方案" -> "展示设计方案各部分";
    "展示设计方案各部分" -> "用户批准设计？";
    "用户批准设计？" -> "展示设计方案各部分" [label="否，修订"];
    "用户批准设计？" -> "编写设计文档" [label="是"];
    "编写设计文档" -> "规格自审\n(内联修正)";
    "规格自审\n(内联修正)" -> "用户审查规格？";
    "用户审查规格？" -> "编写设计文档" [label="要求修改"];
    "用户审查规格？" -> "调用 writing-plans 技能" [label="批准"];
}

最终状态是调用 writing-plans。 不要调用 frontend-design、mcp-builder 或任何其他实现技能。在 brainstormering 之后唯一可调用的技能是 writing-plans。

流程

理解想法：

• 首先检查当前项目状态（文件、文档、最近的提交）
• 在提出详细问题之前，评估范围：如果请求描述多个独立的子系统（例如，“构建一个包含聊天、文件存储、计费和分析的平台”），立即标记出来。不要在尚未分解的项目上花问题来细化细节。
• 如果项目对于一个规格来说太大，帮助用户分解为子项目：哪些是独立部分，它们之间如何关联，构建顺序是什么？然后通过正常设计流程对第一个子项目进行 brainstormering。每个子项目都有自己独立的 规格 → 计划 → 实现 周期。
• 对于范围合适的项目，逐一提问以完善想法
• 尽可能使用多项选择题，但开放式问题亦可
• 每条消息只提一个问题——如果一个主题需要更多探索，将其拆分为多个问题
• 重点理解：目的、约束条件、成功标准

探讨方案：

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

展示设计方案：

• 一旦你确信自己理解了要构建的内容，就展示设计方案
• 按各部分复杂程度缩放：如果简单则用几句话；如果微妙复杂则用 200-300 字
• 每部分之后询问其是否正确
• 涵盖：架构、组件、数据流、错误处理、测试
• 如果某些内容不合理，准备好回头澄清

为隔离和清晰而设计：

• 将系统分解成更小的单元，每个单元有明确的用途，通过定义良好的接口通信，并且可以独立理解和测试
• 对于每个单元，你应该能回答：它做什么、如何使用、依赖什么？
• 是否有人在不阅读其内部实现的情况下就能理解一个单元的功能？是否可以在不破坏使用者的情况下更改内部实现？如果不能，边界需要调整。
• 更小、边界清晰的单元也更容易处理——你一次能放在上下文中处理的代码越多，推理越准确，且文件聚焦时你的编辑更可靠。当文件变得臃肿时，通常意味着它承担了过多职责。

在现有代码库中工作：

• 在提出更改之前先探索当前结构。遵循现有模式。
• 当现有代码存在问题影响到工作时（例如文件过大、边界不清晰、职责混淆），将针对性的改进作为设计的一部分——就像优秀开发者在他们正在处理的代码中改进一样。
• 不要提出无关的重构。聚焦在当前目标所需的内容上。

设计之后

文档化：

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

规格自审：

编写完规格文档后，以全新视角审视：

1. 占位符扫描： 是否存在任何“待定”、“TODO”、不完整部分或模糊需求？修正它们。
2. 内部一致性： 各部分之间是否存在矛盾？架构是否与功能描述匹配？
3. 范围检查： 该规格是否足够聚焦以适用于单个实现计划，还是需要进一步分解？
4. 歧义检查： 是否有任何需求可以被解释为两种不同方式？如果有，选择一种并明确说明。

直接内联修正任何问题。无需重新审查——只需修正并继续。

用户审查关卡：

在规格审查循环通过后，请用户审查已编写的规格，然后再继续：

“规格已编写并提交至 <path>。请审查，如果您希望在开始编写实现计划之前进行任何更改，请告知。”

等待用户响应。如果他们要求修改，则进行修改并重新运行规格审查循环。只有在用户批准后才继续。

实现：

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

关键原则

• 一次一个问题 —— 不要用多个问题让人不知所措
• 优先多项选择 —— 尽可能比开放式问题更容易回答
• 严格遵守 YAGNI —— 从所有设计中移除不必要的功能
• 探索替代方案 —— 在确定之前始终提出 2-3 种方案
• 增量验证 —— 展示设计方案，在继续之前获取批准
• 保持灵活 —— 当某些内容不合理时，退回去澄清

视觉伴侣

一个基于浏览器的伴侣，用于在 brainstormering 过程中展示模型、图表和视觉选项。作为一种工具提供——而非一种模式。接受伴侣意味着它对那些受益于视觉处理的问题可用；但并不意味着每个问题都通过浏览器进行。

提供伴侣（适时）： 不要提前提供。等到某个问题确实通过展示比描述更清晰时——即真正的模型/布局/图表问题，而不仅仅是 UI *话题*。首次出现时，在单独的消息中提供：

“接下来的部分可能我展示给您会更方便——我可以在浏览器标签页中为您制作模型、图表和比较内容。它仍然是新功能且可能消耗较多令牌。您需要吗？我会为您打开。”

这条消息必须是单独的消息。 仅包含提供内容——不附带澄清问题、总结或其他内容。等待用户响应。如果他们接受，用 --open 启动服务器，以便他们的浏览器自动打开至第一屏。如果他们拒绝，继续纯文本模式，除非用户主动提出，否则不再提供。

每问题决策： 即使用户已接受，也要针对每个问题决定是使用浏览器还是终端。判断标准：用户看到它是否比读到它理解得更清晰？

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

关于 UI 主题的问题不自动就是视觉问题。“在这个上下文中，‘个性’是什么意思？”是概念性问题——使用终端。“哪种向导布局更好？”是视觉性问题——使用浏览器。

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

skills/brainstorming/visual-companion.md