用途
Brainstorming 用于在任何创意工作开始之前，把模糊的想法转化为完整的设计与规格说明。它明确要求：在创建功能、构建组件、添加功能或修改行为之前，必须先使用本技能。其核心目标是通过自然的协作式对话，帮助用户把想法梳理成可执行的设计。
主要能力
- 探索项目上下文：检查文件、文档与最近的提交记录。
- 逐个提出澄清问题：一次只问一个问题，理解目的、约束与成功标准。
- 提出 2-3 种方案：说明各自的权衡，并给出推荐及理由。
- 分节呈现设计：每节按复杂度调整篇幅，逐节获得用户确认。
- 撰写设计文档：保存到 docs/plans/YYYY-MM-DD-<topic>-design.md 并提交到 git。
- 转入实施：调用 writing-plans 技能创建实施计划。
使用方式
该技能以清单（Checklist）形式要求为每一项创建任务并按顺序完成：
- 探索项目上下文——检查文件、文档、最近的提交。
- 提出澄清问题——一次一个，理解目的/约束/成功标准。
- 提出 2-3 种方案——附带权衡与推荐。
- 呈现设计——按复杂度分节，每节后获得用户确认。
- 撰写设计文档——保存到 docs/plans/YYYY-MM-DD-<topic>-design.md 并提交。
- 转入实施——调用 writing-plans 技能创建实施计划。
流程为：探索项目上下文 → 提出澄清问题 → 提出 2-3 种方案 → 分节呈现设计 → 用户是否批准设计（否则修订后重新呈现）→ 撰写设计文档 → 调用 writing-plans 技能。终态是调用 writing-plans，之后不要调用 frontend-design、mcp-builder 或任何其他实施类技能。
理解想法时：先查看当前项目状态（文件、文档、最近提交）；一次一个问题地细化想法；尽量使用多选题，也可用开放式问题；每条消息只问一个问题，若某主题需要更多探索则拆成多个问题；聚焦理解目的、约束与成功标准。
探索方案时：提出 2-3 种不同方案并说明权衡；以对话方式呈现选项，给出推荐与理由；先给出推荐选项并解释原因。
呈现设计时：确信理解要构建的内容后呈现设计；每节按复杂度调整篇幅，简单时几句话，复杂时最多 200-300 字；每节后询问是否看起来正确；覆盖架构、组件、数据流、错误处理、测试；若有不合理之处，随时返回澄清。
设计之后：将已验证的设计写入 docs/plans/YYYY-MM-DD-<topic>-design.md；如可用，使用 elements-of-style:writing-clearly-and-concisely 技能；将设计文档提交到 git；调用 writing-plans 技能创建详细实施计划，不要调用其他技能。
适用场景
适用于任何创意工作开始之前，包括创建功能、构建组件、添加功能或修改行为。文档特别指出：每个项目都要经过此流程，待办清单、单函数工具、配置变更都不例外。看似“简单”的项目恰恰是未经审视的假设造成最多返工的地方。设计可以很短（真正简单的项目几句话即可），但必须呈现并获得批准。
限制与原则
- 一次只问一个问题，不要用多个问题压垮用户。
- 尽量使用多选题，比开放式问题更易回答。
- 无情执行 YAGNI，从所有设计中移除不必要的功能。
- 始终先提出 2-3 种方案再定稿。
- 增量验证：呈现设计并在继续前获得批准。
- 保持灵活：遇到不合理之处返回澄清。
- 终态只能是调用 writing-plans，不得调用其他实施类技能。
关于收费、价格、平台支持等信息，资料中暂未提供。