用途
vs-brainstorm 是一个头脑风暴与设计前置技能，目标是把模糊的想法通过协作式对话转化为完整的设计与规格。它适用于任何创意性工作之前：创建功能、构建组件、添加功能或修改行为。
主要流程与能力
第一轮回复要快：第一条消息必须是一个澄清式问题，在提问之前不要探索文件、创建任务或做任何研究，让对话立即运转起来。
按范围分级：在 1-2 个问题后评估范围。
- 小型：配置更改、UI 微调、单文件功能、需求明确。流程为：提问 → 设计（口头）→ 批准 → 实现。
- 中型：多文件功能、存在未知项、新组件。流程为：提问 → 设计 → 批准 → 编写规格 → 实现。
- 大型：新系统、架构决策、多个子系统、不熟悉的技术。流程为：提问 → 研究 → 设计 → 编写规格 → 自审 → 压力测试 → 实现。
除非有证据表明范围更大，默认按小型处理。只有中型/大型范围才创建任务。
提问：一次只问一个问题，避免信息过载；尽量使用多选题；关注目的、约束与成功标准；按需惰性探索上下文（文件、文档、提交），并且放在提问的后台进行；如果请求涉及多个独立子系统，立即指出并帮助拆分。
研究先例（仅大型范围）：仅在架构决策、新系统、全新功能、库/工具选型、不熟悉模式等大型场景触发。在继续提问的同时启动一个后台子代理。优先使用 octocode MCP 工具（githubSearchCode、githubViewRepoStructure），不可用时回退到 GitHub 搜索；若不存在外部搜索工具则静默跳过。提出方案前先给出简短先例部分：最多 2-4 条要点，30 秒内可读完，说明发现了什么、哪些项目、用了什么模式，用户先反应再提出方案。
提出方案：给出 2-3 种不同方案及权衡，先给出推荐方案并解释原因，有先例时引用先例。
呈现设计：每节按其复杂度展开，简单时几句话，复杂时最多 200-300 字；每节之后询问是否符合预期；覆盖架构、组件、数据流、错误处理、测试；随时准备回头澄清。设计要隔离且清晰：拆成更小、单一用途、接口明确的单元，每个单元可独立理解与测试。在现有代码库中工作时，先探索当前结构再提改动，遵循既有模式；若现有代码存在问题且影响本次工作，把针对性改进纳入设计，但不提出无关重构。
编写规格（仅中型/大型）：写入 docs/specs/YYYY-MM-DD-<topic>-design.md（用户偏好可覆盖此路径），并提交设计文档。大型范围还要做规格自审：占位符扫描（TBD、TODO、未完成部分）、内部一致性、范围检查、歧义检查，就地修复后继续。随后设置用户评审关口：告知规格已写入并提交到某路径，请用户评审并告知是否需要改动。
压力测试（仅大型）：用户批准规格后，建议在动手前对设计运行 /vs-grill-me 以发现潜在问题，用户可拒绝并直接进入实现。
进入实现：根据已批准的设计进入计划模式或开始实现。
关键原则
快速第一响应——先提问，不探索；按范围伸缩——小功能走轻流程；一次一个问题；无情地 YAGNI（去掉不必要功能）；先探索替代方案，再定方案；增量验证，每步获得批准后再继续。