brainstorming

头脑风暴：从想法到设计

通过自然的协作对话，帮助用户将想法转化为完整的设计和规格文档。

先了解当前项目上下文，然后逐个提问来细化想法。一旦理解了要构建的内容，呈现设计方案并获得用户认可。

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

一旦触发了这个 skill，即使项目看起来很简单（一个 todo list、一个单函数工具），也要走设计流程。"简单"项目恰恰最容易因为未检验的假设而浪费工作量。设计可以很短（对于真正简单的项目只需几句话），但必须呈现并获得认可。

检查清单

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

1. 探索项目上下文 — 检查文件、文档、最近的提交
2. 适时提供可视化伴侣 — 不要一开始就提供。当某个问题用"看"比"说"更清楚时，在那个时刻提出（单独一条消息）；用户同意后为他们打开浏览器标签页。如果整个过程不需要可视化，就不要提。详见下方"可视化伴侣"章节。
3. 提出澄清问题 — 每次只问一个，理解目的/约束/成功标准
4. 提出 2-3 个方案 — 附带权衡分析和你的推荐
5. 呈现设计 — 按复杂度分节展示，每节之后获得用户认可
6. 编写设计文档 — 保存到 docs/specs/YYYY-MM-DD-<主题>-design.md 并提交
7. 规格自审 — 快速检查占位符、矛盾、歧义、范围（见下方）
8. 用户审阅规格 — 请用户审阅规格文件后再继续
9. 过渡到实现 — 创建实施计划并开始工作

流程图

探索项目上下文 → 提出澄清问题 → 提出 2-3 个方案 → 分节呈现设计
    ↓
用户认可设计？ —[否，修改]→ 返回呈现设计
    ↓ 是
编写设计文档 → 规格自审（就地修复） → 用户审阅规格？
    ↓                                      ↓ 需要修改 → 返回编写设计文档
    ↓                                      ↓ 通过
    └──────────────────────────────────── 开始实现

终态是开始实现。 用户批准规格后，创建分步实施计划并开始编码。

流程详解

理解想法：

• 先了解当前项目状态（文件、文档、最近提交）
• 在深入提问之前先评估范围：如果需求描述了多个独立子系统（例如"构建一个有聊天、文件存储、计费和分析的平台"），立即指出这一点。不要花时间细化一个需要先拆分的项目
• 如果项目对一份规格来说太大，帮助用户分解为子项目：独立的部分有哪些，它们如何关联，应该按什么顺序构建？然后对第一个子项目走正常设计流程。每个子项目有自己的 规格 → 计划 → 实现 循环
• 对范围合适的项目，逐个提问来细化想法
• 尽量使用选择题，开放式也可以
• 每条消息只问一个问题——如果某个话题需要更多探讨，拆成多个问题
• 关注：目的、约束、成功标准

探索方案：

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

呈现设计：

• 一旦你认为理解了要构建的内容，呈现设计
• 每节的详细程度与其复杂度匹配：简单的几句话，复杂的可到 200-300 字
• 每节之后询问用户是否正确
• 覆盖：架构、组件、数据流、错误处理、测试
• 准备好在某处不清楚时回头澄清

为隔离和清晰而设计：

• 将系统拆分为更小的单元，每个单元有一个清晰的职责，通过定义良好的接口通信，可以独立理解和测试
• 对每个单元，你应该能回答：它做什么，怎么使用它，它依赖什么？
• 别人能不看内部实现就理解一个单元的功能吗？能修改内部实现而不破坏使用者吗？如果不能，说明边界需要重新划分
• 更小、边界清晰的单元也更容易处理——对能在上下文中完整容纳的代码，推理更准确，编辑更可靠。当文件变得很大时，通常意味着它做了太多事

在已有代码库中工作：

• 在提出变更之前先了解现有结构。遵循现有模式
• 如果现有代码的问题影响到当前工作（例如文件过大、边界不清、职责纠缠），将针对性改进纳入设计——就像一个好开发者在工作时顺手改善接触到的代码
• 不要提出无关的重构。专注于当前目标

设计之后

文档：

• 将验证过的设计（规格）写入 docs/specs/YYYY-MM-DD-<主题>-design.md
  • （用户对规格存放位置的偏好优先于此默认路径）
• 写作要清晰简洁——短句、主动语态、具体细节优于模糊概括
• 将设计文档提交到 git