brainstorming

1# 头脑风暴：从想法到设计
2 
3通过自然的协作对话，帮助用户将想法转化为完整的设计和规格文档。
4 
5先了解当前项目上下文，然后逐个提问来细化想法。一旦理解了要构建的内容，呈现设计方案并获得用户认可。
6 
7<HARD-GATE>
8在呈现设计方案并获得用户认可之前，不要编写任何代码、搭建任何项目脚手架，或执行任何实现操作。无论项目看起来多简单，这一规则都适用。
9</HARD-GATE>
10 
11## 反模式："这个太简单了不需要设计"
12 
13一旦触发了这个 skill，即使项目看起来很简单（一个 todo list、一个单函数工具），也要走设计流程。"简单"项目恰恰最容易因为未检验的假设而浪费工作量。设计可以很短（对于真正简单的项目只需几句话），但必须呈现并获得认可。
14 
15## 检查清单
16 
17必须为以下每一项创建任务，并按顺序完成：
18 
191. **探索项目上下文** — 检查文件、文档、最近的提交
202. **适时提供可视化伴侣** — 不要一开始就提供。当某个问题用"看"比"说"更清楚时，在那个时刻提出（单独一条消息）；用户同意后为他们打开浏览器标签页。如果整个过程不需要可视化，就不要提。详见下方"可视化伴侣"章节。
213. **提出澄清问题** — 每次只问一个，理解目的/约束/成功标准
224. **提出 2-3 个方案** — 附带权衡分析和你的推荐
235. **呈现设计** — 按复杂度分节展示，每节之后获得用户认可
246. **编写设计文档** — 保存到 `docs/specs/YYYY-MM-DD-<主题>-design.md` 并提交
257. **规格自审** — 快速检查占位符、矛盾、歧义、范围（见下方）
268. **用户审阅规格** — 请用户审阅规格文件后再继续
279. **过渡到实现** — 创建实施计划并开始工作
28 
29## 流程图
30 
31```
32探索项目上下文 → 提出澄清问题 → 提出 2-3 个方案 → 分节呈现设计
33    ↓
34用户认可设计？ —[否，修改]→ 返回呈现设计
35    ↓ 是
36编写设计文档 → 规格自审（就地修复） → 用户审阅规格？
37    ↓                                      ↓ 需要修改 → 返回编写设计文档
38    ↓                                      ↓ 通过
39    └──────────────────────────────────── 开始实现
40```
41 
42**终态是开始实现。** 用户批准规格后，创建分步实施计划并开始编码。
43 
44## 流程详解
45 
46**理解想法：**
47 
48- 先了解当前项目状态（文件、文档、最近提交）
49- 在深入提问之前先评估范围：如果需求描述了多个独立子系统（例如"构建一个有聊天、文件存储、计费和分析的平台"），立即指出这一点。不要花时间细化一个需要先拆分的项目
50- 如果项目对一份规格来说太大，帮助用户分解为子项目：独立的部分有哪些，它们如何关联，应该按什么顺序构建？然后对第一个子项目走正常设计流程。每个子项目有自己的 规格 → 计划 → 实现 循环
51- 对范围合适的项目，逐个提问来细化想法
52- 尽量使用选择题，开放式也可以
53- 每条消息只问一个问题——如果某个话题需要更多探讨，拆成多个问题
54- 关注：目的、约束、成功标准
55 
56**探索方案：**
57 
58- 提出 2-3 个不同方案及其权衡
59- 以对话方式呈现选项，附带你的推荐和理由
60- 先说你推荐的方案并解释为什么
61 
62**呈现设计：**
63 
64- 一旦你认为理解了要构建的内容，呈现设计
65…