# Brainstorming

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

- Skill: `vinvcn/brainstorming` (Agent Skill, multi-file: 8 files)
- Install (CLI): `npx skillmds@latest add vinvcn/brainstorming`
- Raw SKILL.md: https://api.skillmd.com/api/skills/vinvcn/brainstorming/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: vinvcn (https://skillmd.com/u/vinvcn)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/vinvcn/brainstorming

---


# 将想法头脑风暴成设计

通过自然的协作式对话，帮助把想法转化为成型的设计和规范。

先理解当前项目上下文，然后一次只问一个问题来细化想法。一旦你理解要构建什么，就展示设计并获得用户批准。

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

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

每个项目都要经过这个流程。待办清单、单功能工具、配置变更，全都一样。“简单”项目最容易因为未经审视的假设造成最多浪费。设计可以很短（真正简单的项目几句话即可），但你必须展示它并获得批准。

## 检查清单

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

1. **探索项目上下文** — 检查文件、文档、近期提交
2. **提供 visual companion**（如果主题会涉及视觉问题）— 这必须是一条独立消息，不能和澄清问题合并。见下方 Visual Companion 小节。
3. **提出澄清问题** — 一次一个，理解目的/约束/成功标准
4. **提出 2-3 种方案** — 包含权衡和你的建议
5. **展示设计** — 按复杂度分节展示，每节后获得用户批准
6. **编写设计文档** — 保存到 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` 并提交
7. **规范自审** — 快速内联检查占位符、矛盾、歧义、范围（见下文）
8. **用户审阅已写好的规范** — 继续前请用户审阅规范文件
9. **过渡到实现** — 调用 writing-plans skill 创建实现计划

## 流程

```dot
digraph brainstorming {
    "Explore project context" [shape=box];
    "Visual questions ahead?" [shape=diamond];
    "Offer Visual Companion\n(own message, no other content)" [shape=box];
    "Ask clarifying questions" [shape=box];
    "Propose 2-3 approaches" [shape=box];
    "Present design sections" [shape=box];
    "User approves design?" [shape=diamond];
    "Write design doc" [shape=box];
    "Spec self-review\n(fix inline)" [shape=box];
    "User reviews spec?" [shape=diamond];
    "Invoke writing-plans skill" [shape=doublecircle];

    "Explore project context" -> "Visual questions ahead?";
    "Visual questions ahead?" -> "Offer Visual Companion\n(own message, no other content)" [label="yes"];
    "Visual questions ahead?" -> "Ask clarifying questions" [label="no"];
    "Offer Visual Companion\n(own message, no other content)" -> "Ask clarifying questions";
    "Ask clarifying questions" -> "Propose 2-3 approaches";
    "Propose 2-3 approaches" -> "Present design sections";
    "Present design sections" -> "User approves design?";
    "User approves design?" -> "Present design sections" [label="no, revise"];
    "User approves design?" -> "Write design doc" [label="yes"];
    "Write design doc" -> "Spec self-review\n(fix inline)";
    "Spec self-review\n(fix inline)" -> "User reviews spec?";
    "User reviews spec?" -> "Write design doc" [label="changes requested"];
    "User reviews spec?" -> "Invoke writing-plans skill" [label="approved"];
}
```

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

## 具体流程

**理解想法：**

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

**探索方案：**

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

**展示设计：**

- 一旦你认为已经理解要构建什么，就展示设计
- 每节篇幅按复杂度调整：直接的内容用几句话，有细微差别的内容最多 200-300 词
- 每节后询问目前看起来是否正确
- 覆盖：架构、组件、数据流、错误处理、测试
- 如果某些内容说不通，准备回头澄清

**为隔离性和清晰性而设计：**

- 把系统拆成更小的单元，每个单元都有一个清晰目的，通过定义良好的接口通信，并且可以独立理解和测试
- 对每个单元，你都应该能回答：它做什么、如何使用、依赖什么？
- 别人能否不读内部实现就理解一个单元做什么？你能否修改内部实现而不破坏使用方？如果不能，边界还需要调整。
- 更小、边界清晰的单元也更便于你处理 - 当你能一次把代码放进上下文里时，推理会更好；文件更聚焦时，编辑也更可靠。文件变大通常说明它做了太多事。

**在现有代码库中工作：**

- 提出改动前先探索当前结构。遵循既有模式。
- 如果现有代码存在会影响工作的缺陷（例如文件过大、边界不清、职责纠缠），把有针对性的改进纳入设计 - 就像优秀开发者会改进自己正在处理的代码。
- 不要提出无关重构。专注于服务当前目标的内容。

## 设计之后

**文档：**

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

**规范自审：**
写完规范文档后，以新的视角审视它：

1. **占位符扫描：** 是否有“TBD”、“TODO”、未完成章节或模糊需求？修复它们。
2. **内部一致性：** 是否有章节彼此矛盾？架构是否匹配功能描述？
3. **范围检查：** 它是否足够聚焦，可以进入单个实现计划，还是需要拆解？
4. **歧义检查：** 是否有需求可能被解读成两种不同含义？如果有，选择一种并明确写出。

内联修复所有问题。无需重新审阅 — 直接修复并继续。

**用户审阅门禁：**
规范审阅循环通过后，请用户在继续前审阅已写好的规范：

> “规范已写入并提交到 `<path>`。请审阅它，并告诉我在我们开始写实现计划前是否需要修改。”

等待用户回复。如果用户要求修改，完成修改并重新运行规范审阅循环。只有在用户批准后才能继续。

**实现：**

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

## 核心原则

- **一次一个问题** - 不要用多个问题压倒对方
- **优先选择题** - 可行时比开放式问题更容易回答
- **严格 YAGNI** - 从所有设计中移除不必要功能
- **探索替代方案** - 敲定前始终提出 2-3 种方案
- **增量验证** - 展示设计，获得批准后再继续
- **保持灵活** - 当内容说不通时，回头澄清

## Visual Companion

一个基于浏览器的 companion，用于在头脑风暴期间展示模型稿、图表和视觉选项。它是一个工具，而不是一种模式。接受 companion 意味着它可用于受益于视觉呈现的问题；并不意味着每个问题都要通过浏览器处理。

**提供 companion：** 当你预计接下来的问题会涉及视觉内容（模型稿、布局、图表）时，先提供一次并征得同意：
> “我们正在处理的一些内容，如果我能在 Web 浏览器里展示给你，可能会更容易解释。我可以随着讨论推进整理模型稿、图表、对比和其他视觉材料。这个功能还很新，可能会消耗较多 token。要试试吗？（需要打开一个本地 URL）”

**这个提议必须是一条独立消息。** 不要把它和澄清问题、上下文摘要或任何其他内容合并。消息应只包含上面的提议，不能有其他内容。继续前等待用户回复。如果用户拒绝，就用纯文本继续头脑风暴。

**逐问题决策：** 即使用户接受了，也要针对每个问题判断使用浏览器还是终端。判断标准：**用户看到它会不会比阅读文字更容易理解？**

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

关于 UI 主题的问题不自动等于视觉问题。“在这个上下文里 personality 是什么意思？”是概念问题 — 使用终端。“哪种 wizard layout 更好？”是视觉问题 — 使用浏览器。

如果用户同意使用 companion，继续前阅读详细指南：
`skills/brainstorming/visual-companion.md`