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=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。

流程

理解想法：

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

探索方案：

• 提出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种方案
• 增量验证 — 呈现设计，获得批准后再继续
• 保持灵活 — 当某些内容不合理时，返回去澄清

视觉辅助

一个基于浏览器的辅助工具，用于在头脑风暴期间展示原型、图表和视觉选项。作为工具可用——而非模式。接受辅助意味着在那些受益于视觉处理的问题上可以使用它；但这并不意味着每个问题都要通过浏览器进行。

提供辅助： 当你预计即将提出的问题会涉及视觉内容（原型、布局、图表）时，提供一次以获得同意：

“我们正在处理的一些内容，如果我能通过网页浏览器向你展示，可能会更容易解释。我可以在过程中创建原型、图表、对比图和其他视觉内容。这个功能还很新，可能消耗较多 token。想试试吗？（需要打开一个本地 URL）”

这个提供必须是单独的消息。 不要将其与澄清问题、背景总结或任何其他内容合并。消息中应只包含上述提供内容，别无其他。在用户回复之前不要继续。如果用户拒绝，则继续仅使用文本的头脑风暴。

每个问题的决策： 即使接受了，对于每个问题也要决定是使用浏览器还是终端。测试标准：用户通过看到它比阅读它理解得更好吗？

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

关于 UI 主题的问题不自动成为视觉问题。“人格在这个上下文中意味着什么？”是一个概念问题——使用终端。“哪种向导布局更好？”是一个视觉问题——使用浏览器。

如果他们同意使用视觉辅助，在继续之前阅读详细指南：

skills/brainstorming/visual-companion.md