---
name: brainstorming
description: 开始创造性工作（新功能、建组件、加能力、改行为）之前、动手实现之前使用——澄清用户意图与需求，比较方案，把设计共识写成项目活文档并记录决策，再交给 workflow-planning 拆单；小而清楚的改动不必用它。
---

# brainstorming — 把想法变成有共识的设计

先有被认可的设计，再有任何实现。

<HARD-GATE>
在设计呈现给用户并获认可之前，不调任何实现类技能、不写代码、不搭脚手架、不做任何实现动作。
</HARD-GATE>

**范围说明**：要不要走本技能由主 loop 判定——小而清楚的改动直接做，不走设计环节。一旦进入本技能就按流程走；中途发现其实不需要设计，说明并交回。设计本身按复杂度伸缩：简单的东西几句话就是一份合格的设计。

## 流程

1. **摸清项目上下文**——相关文件、文档、最近提交。若请求横跨多个独立子系统，先说明，帮用户拆成子项目，再脑暴第一个；每个子项目各走一遍「设计 → 拆单 → 实现」。
2. **一次只问一个澄清问题**——目的、约束、成功判据。优先给多选项。宿主有原生的规划模式 / 提问工具就用它。
3. **提出 2–3 个方案**并比较取舍，先摆推荐项。坚决 YAGNI。在既有代码库里遵循既有模式，只带进这项工作本身需要的定向改进——不做无关重构。
4. **分节呈现设计**（架构、组件、数据流、错误处理、测试），每节按其复杂度定篇幅，逐节取得认可。
5. **写下来**（见下），自审，再交用户审阅书面稿。
6. **交棒给 `workflow-planning`** 拆单落单。这是本技能之后唯一会调用的技能。

## 设计落在哪里

设计文档**就是**功能活文档的第一版——没有单独的 spec 文件，也没有事后再搬一次的沉淀步骤：

- **功能类工作**：项目的 `.spec/knowledge/features/<topic>.md`，用定稿口吻（写它**是什么**，不写讨论过程），frontmatter 照项目的模板，状态从「设计中」起步并登记进 `.spec/knowledge/README.md` 导航；状态随实现推进而流转，文档本身不挪位置。
- **一次性工程任务**（没有长期存在的东西要描述）：不建功能文档；设计作为需求单正文的一节，随 `workflow-planning` 落单。
- **取舍、被否方案、「为什么」**：项目的 `.spec/decisions/` 下新增一份 ADR。功能文档只保留设计现状。
- **任务真值只有 Workflow 单**：设计里凡是要有人去做的事，由 `workflow-planning` 落成单，文档里引用单号；不在文档里另开待办清单。
- 讨论过程本身不入库。用户对文档位置有偏好时以用户为准。
- 提交设计文档。

**交用户之前先自审**：占位符（「待定」「稍后补」、含糊的需求）→ 补实；内部矛盾 → 修掉；范围——是一份实现计划的量，还是需要再拆；歧义——任何能读出两种意思的需求 → 选定一种并写明。就地改，不用再审一轮。

**用户审阅门**：「设计已写入并提交到 `<路径>`，请先审阅，再拆单。」等待；按要求修改并重跑自审；获认可才继续。