brainstorming

将想法头脑风暴为设计

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

首先理解当前项目上下文，然后逐个提出问题以细化想法。一旦你理解了要构建什么，就呈现设计并获得用户批准。

在你呈现设计并获得用户批准之前，不要调用任何实现技能、编写任何代码、搭建任何项目或采取任何实现动作。这适用于每一个项目，无论看起来多简单。

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

每个项目都要经过这个过程。待办清单、单函数工具、配置修改——全都是。"简单"的项目正是未经审视的假设造成最多浪费工作的地方。设计可以很简短（对于真正简单的项目只需几句话），但你必须呈现设计并获得批准。

检查清单

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

1. 探索项目上下文 — 检查文件、文档、最近的提交
2. 适时提供可视化伴侣 — 不要预先提供。当某个问题用展示比描述确实更清晰时，再在那时提供（作为独立消息）；批准后其浏览器标签页会为你打开。如果从未出现视觉问题，永远不要提供它。见下方的可视化伴侣部分。
3. 提出澄清问题 — 逐个提出，理解目的/约束/成功标准
4. 提出 2-3 个方案 — 包含权衡和你的推荐
5. 呈现设计 — 按各部分的复杂度调整篇幅，每部分后获得用户批准
6. 编写设计文档 — 保存到 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 并提交
7. 规格说明书自审 — 快速内联检查占位符、矛盾、歧义、范围（见下文）
8. 用户审查书面规格说明书 — 在继续之前请用户审查规格说明书文件
9. 过渡到实现 — 调用编写计划技能创建实现计划

流程图

digraph brainstorming {
    "探索项目上下文" [shape=box];
    "提出澄清问题" [shape=box];
    "提出 2-3 个方案" [shape=box];
    "呈现设计各部分" [shape=box];
    "用户批准设计？" [shape=diamond];
    "编写设计文档" [shape=box];
    "规格说明书自审\n（内联修复）" [shape=box];
    "用户审查规格说明书？" [shape=diamond];
    "调用编写计划技能" [shape=doublecircle];

    "探索项目上下文" -> "提出澄清问题";
    "提出澄清问题" -> "提出 2-3 个方案";
    "提出 2-3 个方案" -> "呈现设计各部分";
    "呈现设计各部分" -> "用户批准设计？";
    "用户批准设计？" -> "呈现设计各部分" [label="否，修改"];
    "用户批准设计？" -> "编写设计文档" [label="是"];
    "编写设计文档" -> "规格说明书自审\n（内联修复）";
    "规格说明书自审\n（内联修复）" -> "用户审查规格说明书？";
    "用户审查规格说明书？" -> "编写设计文档" [label="要求修改"];
    "用户审查规格说明书？" -> "调用编写计划技能" [label="批准"];
}

终止状态是调用编写计划。 不要调用 frontend-design、mcp-builder 或任何其他实现技能。头脑风暴之后你调用的唯一技能是编写计划。

流程

理解想法：

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

探索方案：

• 提出 2-3 个不同方案及其权衡
• 以对话方式呈现选项，附上你的推荐和理由
• 优先说明你推荐的方案并解释原因

呈现设计：

• 一旦你确信理解了要构建什么，就呈现设计
• 按各部分的复杂度调整篇幅：简单部分几句话，细微部分最多 200-300 字
• 每部分后询问到目前为止是否正确
• 涵盖：架构、组件、数据流、错误处理、测试
• 如果某处不合理，准备好回头澄清

为隔离和清晰而设计：

• 将系统拆分为更小的单元，每个单元都有明确单一的目的，通过定义良好的接口通信，能够被独立理解和测试
• 对于每个单元，你应该能回答：它做什么，如何使用它，它依赖什么？
• 不读内部实现能否理解一个单元做什么？能否在不破坏使用方的情况下更改内部实现？如果不能，边界需要改进。
• 更小、边界良好的单元也更便于你处理——你能更好地推理可一次性放入上下文的代码，当文件聚焦时你的编辑也更可靠。当文件变大时，这通常是它承担了太多职责的信号。

在现有代码库中工作：

• 在提出变更之前探索当前结构。遵循现有模式。
• 当现有代码存在影响当前工作的问题时（例如文件变得过大、边界不清、职责纠缠），将针对性改进作为设计的一部分——就像优秀的开发者会改进他们正在其中工作的代码。
• 不要提出无关的重构。保持专注于服务当前目标的内容。

设计之后

文档：

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

规格说明书自审： 编写规格说明书文档后，以全新的眼光审视它：

1. 占位符扫描： 是否有任何 "TBD"、"TODO"、不完整的部分或模糊的需求？修复它们。
2. 内部一致性： 各部分是否相互矛盾？架构是否与功能描述匹配？
3. 范围检查： 这是否足够聚焦于单个实现计划，还是需要分解？
4. 歧义检查： 任何需求是否可以被两种不同方式解读？如果是，选择一种并使其明确。

内联修复任何问题。无需重新审查——修复后继续。

用户审查门： 规格说明书审查循环通过后，在继续之前请用户审查书面规格说明书：

"规格说明书已编写并提交到 <path>。请审查它，在我们开始编写实现计划之前告诉我是否想作任何修改。"

等待用户回应。如果他们要求修改，进行修改并重新运行规格说明书审查循环。仅在用户批准后继续。

实现：

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

关键原则

• 一次一个问题 - 不要用多个问题压倒对方
• 优先多选题 - 尽可能比开放式问题更易回答
• YAGNI 要狠 - 从所有设计中移除不必要的功能
• 探索替代方案 - 在确定之前总是提出 2-3 个方案
• 增量验证 - 呈现设计，在继续之前获得批准
• 保持灵活 - 当某处不合理时回头澄清

可视化伴侣

一个基于浏览器的伴侣，用于在头脑风暴期间展示模型、图表和视觉选项。作为工具提供——不是一种模式。接受伴侣意味着它可用于受益于视觉处理的问题；这并不表示每个问题都通过浏览器处理。

提供伴侣（适时）： 不要预先提供。等到某个问题用展示确实比讲述更清晰时——一个真实的模型/布局/图表问题，而不仅仅是 UI 主题。第一次发生这种情况时，在那时提供，作为独立消息：

"接下来这部分如果我展示给你看可能更容易——我们进行时我可以在浏览器标签页中制作模型、图表和对比。它还较新，可能比较耗 token。要我吗？我会为你打开它。"

此提议必须是独立消息。 只有提议——没有澄清问题、总结或其他内容。等待用户回应。如果他们接受，用 --open 启动服务器，这样他们的浏览器会自动打开到第一个画面。如果他们拒绝，继续纯文本方式，除非他们主动提出否则不再提供。

逐问题决定： 即使用户接受后，也要为每个问题决定是使用浏览器还是终端。判断标准：用户通过看到它比读到它更好地理解吗？

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

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

如果他们同意使用伴侣，在继续之前阅读详细指南： skills/brainstorming/visual-companion.md