brainstorming

name	brainstorming
description	在进行任何创造性工作之前，你必须使用此 skill - 创建功能、构建组件、添加功能或修改行为。在实现之前探索用户意图、需求和设计。

将想法 Brainstorm 成设计 (Brainstorming Ideas Into Designs)

通过自然的协作对话，帮助把想法转变为完全成形的设计和规范（spec）。

从理解当前项目上下文开始，然后一次一个问题地提问来细化想法。一旦你理解了要构建什么，就呈现设计并获得用户批准。

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

反模式："这太简单了，不需要设计" (Anti-Pattern)

每个项目都要经过这个流程。一个 todo 列表、一个单函数工具、一个配置改动——全部都是。"简单"的项目正是未经审视的假设造成最多返工的地方。设计可以很短（对于真正简单的项目几句话即可），但你必须呈现它并获得批准。

检查清单 (Checklist)

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

1. 探索项目上下文 —— 检查文件、文档、最近的 commits
2. 即时（just-in-time）提供视觉伴侣 —— 不要预先提供。第一次出现"展示比描述更清晰"的问题时，那时再提供（作为独立消息）；用户同意后，它的浏览器标签页会为你打开。如果从未出现视觉问题，绝不提供。见下方的视觉伴侣（Visual Companion）小节。
3. 提出澄清问题 —— 一次一个，理解目的/约束/成功标准
4. 提出 2-3 种方案 —— 含权衡和你的推荐
5. 呈现设计 —— 按复杂度分节，每节后获得用户批准
6. 编写设计文档 —— 保存到 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 并提交
7. 规范自审（Spec self-review） —— 快速内联检查占位符、矛盾、歧义、范围（见下文）
8. 用户审查书面规范 —— 在继续之前请用户审查 spec 文件
9. 过渡到实现 —— 调用 writing-plans skill 创建实现计划

流程图 (Process Flow)

digraph brainstorming {
    "探索项目上下文" [shape=box];
    "提出澄清问题" [shape=box];
    "提出 2-3 种方案" [shape=box];
    "呈现设计小节" [shape=box];
    "用户批准设计？" [shape=diamond];
    "编写设计文档" [shape=box];
    "规范自审\n（内联修复）" [shape=box];
    "用户审查规范？" [shape=diamond];
    "调用 writing-plans skill" [shape=doublecircle];

    "探索项目上下文" -> "提出澄清问题";
    "提出澄清问题" -> "提出 2-3 种方案";
    "提出 2-3 种方案" -> "呈现设计小节";
    "呈现设计小节" -> "用户批准设计？";
    "用户批准设计？" -> "呈现设计小节" [label="否，修改"];
    "用户批准设计？" -> "编写设计文档" [label="是"];
    "编写设计文档" -> "规范自审\n（内联修复）";
    "规范自审\n（内联修复）" -> "用户审查规范？";
    "用户审查规范？" -> "编写设计文档" [label="要求修改"];
    "用户审查规范？" -> "调用 writing-plans skill" [label="批准"];
}

终态是调用 writing-plans。 不要调用 frontend-design、mcp-builder 或任何其他实现 skill。brainstorming 之后你调用的唯一 skill 是 writing-plans。

流程 (The Process)

理解想法：

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

探索方案：

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

呈现设计：

• 一旦你确信理解了要构建什么，就呈现设计
• 按复杂度缩放每一节：直接的几句话即可，微妙的最多 200-300 字
• 每节后询问到目前为止是否合理
• 涵盖：架构、组件、数据流、错误处理、测试
• 准备好在不合理时回去澄清

为隔离和清晰而设计：

• 把系统分解为更小的单元，每个单元有单一明确的目的，通过定义良好的接口通信，并能独立理解和测试
• 对每个单元，你应该能回答：它做什么，你怎么使用它，它依赖什么？
• 别人能不读内部实现就理解一个单元做什么吗？你能不改消费者就改动内部吗？如果不能，边界还需要打磨。
• 更小、边界良好的单元也更容易让你处理——你能更好地推理可以一次性放入上下文的代码，当文件聚焦时你的编辑更可靠。当一个文件变大时，那通常是一个信号：它承担了太多职责。

在现有代码库中工作：

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

设计之后 (After the Design)

文档：

• 把验证过的设计（spec）写入 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md
  • （用户对 spec 位置的偏好优先于此默认值）
• 如果可用，使用 elements-of-style:writing-clearly-and-concisely skill
• 把设计文档提交到 git

规范自审（Spec Self-Review）： 写完 spec 文档后，以全新的眼光审视它：

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

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

用户审查关卡（User Review Gate）： spec 审查循环通过后，在继续之前请用户审查书面规范：

"Spec 已写入并提交到 <path>。请审查它，并告诉我是否想在开始编写实现计划之前做任何改动。"

等待用户响应。如果他们要求改动，做出改动并重新运行 spec 审查循环。仅在用户批准后继续。

实现：

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

关键原则 (Key Principles)

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

视觉伴侣 (Visual Companion)

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

提供伴侣（即时）： 不要预先提供。等到一个问题确实"展示比讲述更清晰"——一个真正的模型/布局/图表问题，而不仅仅是一个 UI 话题。第一次发生时，那时再提供，作为独立消息：

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

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

逐问题决定： 即使在用户接受之后，也要为每个问题决定使用浏览器还是终端。测试标准是：用户看到它是否比读到它更容易理解？

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

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

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