用途
Brainstorming 用于在开始任何创造性工作之前，把模糊的想法转化为完整成型的设计与规格说明。它通过自然的协作式对话完成这一过程，适用于新功能、UI/组件、行为变更等场景。
主要能力
该技能定义了一套有序的检查清单流程：
- 探索项目上下文——检查文件、文档、最近的提交记录。
- 提出澄清问题——每次只问一个，理解目的、约束与成功标准。
- 提出 2-3 种方案——附带权衡取舍与推荐意见。
- 呈现设计——按复杂度分段，每段之后获取用户确认。
- 编写设计文档——保存到 docs/plans/YYYY-MM-DD-<topic>-design.md 并提交。
- 规格自审——检查占位符、矛盾、歧义与范围。
- 用户审阅书面规格——在继续之前请用户审阅规格文件。
- 转入实现——创建具体的实现计划。
流程中还包含一个 digraph 流程图，描述了从探索上下文、提问、提出方案、呈现设计、用户批准、编写文档、自审、用户审阅到创建实现计划的完整路径，并包含“不批准则修订”“要求修改则重写文档”等回退分支。
使用方式
理解想法阶段：先查看当前项目状态（文件、文档、最近提交）。在提出详细问题之前评估范围：如果请求描述了多个独立子系统（例如“构建一个包含聊天、文件存储、计费和数据分析的平台”），应立即指出，不要花时间细化一个需要先分解的项目。如果项目对单个规格来说太大，帮助用户分解为子项目：哪些是独立部分、它们如何关联、应按什么顺序构建，然后通过正常设计流程对第一个子项目进行头脑风暴。每个子项目都有自己的规格 → 计划 → 实现循环。对于范围合适的项目，每次只问一个问题来细化想法，尽量使用多选题，每条消息只问一个问题。
探索方案阶段：提出 2-3 种不同方案及其权衡，先给出推荐选项并解释原因，以对话方式呈现选项、推荐与理由。
呈现设计阶段：一旦认为理解了要构建的内容，就呈现设计。每个部分的篇幅按复杂度缩放：简单时几句话，复杂时最多 200-300 字。每部分之后询问是否看起来正确。覆盖架构、组件、数据流、错误处理、测试。如果某些内容不合理，准备好返回澄清。
隔离与清晰设计：把系统拆分为更小的单元，每个单元有单一明确目的，通过定义良好的接口通信，可独立理解与测试。对每个单元应能回答：它做什么、如何使用、依赖什么。
在现有代码库中工作：提出更改前先探索当前结构，遵循现有模式。如果现有代码存在问题影响当前工作（如文件过大、边界不清、职责纠缠），将针对性改进纳入设计。不要提出无关重构，专注于服务当前目标。
设计之后：将验证过的设计（规格）写入 docs/plans/YYYY-MM-DD-<topic>-design.md，用户对规格位置的偏好可覆盖此默认值，并将设计文档提交到 git。
规格自审：写完后以全新视角检查——占位符扫描（任何 TBD、TODO、不完整部分或模糊需求）、内部一致性（各节是否矛盾、架构是否与功能描述匹配）、范围检查（是否足够聚焦于单个实现计划）、歧义检查（任何需求是否可有两种解释）。发现问题就地修复，无需重新审阅。
用户审阅关卡：规格审阅循环通过后，请用户在继续之前审阅书面规格：“Spec written and committed to <path>. Please review it and let me know if you want to make any changes before we move to the implementation plan.” 等待用户回复。如果要求修改，则修改并重新运行规格审阅循环。只有用户批准后才继续。
实现：在编写任何代码之前创建具体的实现计划。如果有 writing-plans 技能可用，则调用它；否则内联生成分步计划。
适用场景
适用于任何创造性工作之前，包括新功能、UI/组件、行为变更等。文档明确强调：每个项目都要经过此流程，待办清单、单函数工具、配置变更也不例外。“简单”项目正是未经检验的假设造成最多浪费工作的地方。设计可以很短（真正简单的项目几句话即可），但必须呈现并获得批准。
关键原则
- 每次只问一个问题——不要用多个问题压垮用户。
- 优先多选题——可能时比开放式问题更容易回答。
- 无情执行 YAGNI——从所有设计中移除不必要的功能。
- 探索替代方案——在定案前始终提出 2-3 种方案。
- 增量验证——呈现设计，在继续之前获得批准。
- 保持灵活——当某些内容不合理时返回澄清。
限制
资料未提供该技能的安装命令、收费方式、支持平台或具体运行环境等信息。