用途
Spark 用于把想法转化为完整的设计与规格说明，适用于用户想要头脑风暴一个想法，或设计某个功能、规格的场景。它通过自然的协作式对话推进，而不是直接进入实现。
主要能力
- 先探索项目上下文：查看文件、文档与近期提交记录。
- 在提问前评估范围：如果请求包含多个相互独立的子系统（例如“构建一个带聊天、文件存储、计费和数据分析的平台”），会立即指出，先帮助用户拆分为子项目，再对第一个子项目走正常设计流程。
- 逐个提出澄清问题，理解目的、约束与成功标准。
- 提出 2-3 种不同方案，说明取舍并给出推荐与理由。
- 分段呈现设计，每段按复杂度伸缩，逐段询问用户是否认可。
- 将设计文档写入 docs/spark/YYYY-MM-DD-<topic>-design.md 并提交到 git（用户对规格位置的偏好可覆盖此默认值）。
- 写完后进行规格自审：检查占位符（TBD、TODO、不完整章节、模糊需求）、内部一致性、范围是否适合单个实现计划、是否存在歧义，并就地修复。
- 用户评审关卡：请用户审阅已写好的规格，若要求修改则修改并重跑自审循环，用户批准后才继续。
使用方式
流程按清单顺序执行，每一项都需创建任务并完成：
- 探索项目上下文——检查文件、文档、近期提交。
- 提供可视化伴侣（若话题涉及视觉问题）——该提议必须单独成一条消息，不与其他内容合并。
- 逐个提出澄清问题——一次一个问题，理解目的/约束/成功标准。
- 提出 2-3 种方案——含取舍与推荐。
- 呈现设计——分段并按复杂度伸缩，每段后获取用户批准。
- 编写设计文档——保存到 docs/spark/YYYY-MM-DD-<topic>-design.md 并提交。
- 规格自审——快速内联检查占位符、矛盾、歧义、范围。
- 用户评审书面规格——请用户在继续前审阅规格文件。
- 交付规格给用户并停止——报告规格文件路径；不调用任何其他技能，不开始实现。
流程的终态是向用户交付规格。停止。不要调用其他技能，不要开始实现规划，不要写代码。报告规格路径并结束本轮，由用户自行决定如何使用该规格。
适用场景
- 用户想头脑风暴一个想法。
- 用户想设计一个功能或规格说明。
- 需要把模糊想法逐步澄清为可评审的设计文档。
- 在已有代码库中工作：先探索现有结构再提改动，遵循既有模式；若现有代码存在问题影响本次工作（如文件过大、边界不清、职责纠缠），将针对性改进纳入设计，但不做无关重构。
设计原则
- 一次只问一个问题，避免用多个问题压垮用户。
- 优先使用多选题，比开放式问题更易回答。
- 无情执行 YAGNI，从所有设计中移除不必要的功能。
- 始终先提出 2-3 种方案再定案。
- 增量验证：呈现设计并在继续前获得批准。
- 保持灵活：当某处说不通时回头澄清。
- 为隔离与清晰而设计：把系统拆成更小的单元，每个单元有单一明确目的，通过定义良好的接口通信，可独立理解与测试。对每个单元应能回答：它做什么、如何使用、依赖什么。
可视化伴侣
可视化伴侣是一个基于浏览器的辅助工具，用于在头脑风暴期间展示原型图、图表和视觉选项。它作为工具提供，而非一种模式。接受该伴侣意味着它可用于受益于视觉呈现的问题，但不意味着每个问题都走浏览器。
提供方式：当预判后续问题会涉及视觉内容（原型图、布局、图表）时，一次性征求同意，提议内容为：“我们正在讨论的一些内容，如果我能用网页浏览器展示给你看，可能会更容易解释。我可以在过程中整理原型图、图表、对比和其他视觉内容。这个功能还比较新，可能比较消耗 token。想试试吗？（需要打开一个本地 URL）”。该提议必须单独成一条消息，不得与澄清问题、上下文摘要或其他内容合并，消息中只包含该提议。等待用户回应后再继续；若用户拒绝，则继续纯文本头脑风暴。
逐题决策：即使用户接受，也要对每个问题单独决定用浏览器还是终端。判断标准是：用户看到它是否比读到它更容易理解。视觉内容（原型图、线框图、布局对比、架构图、并排视觉设计）用浏览器；文本内容（需求问题、概念选择、取舍列表、A/B/C/D 文本选项、范围决策）用终端。关于 UI 话题的问题不自动等于视觉问题。若用户同意使用伴侣，继续前需阅读详细指南：skills/brainstorming/visual-companion.md。
限制
- 终态是交付规格并停止，不调用其他技能、不开始实现规划、不写代码。
- 反模式提醒：“这太简单了不需要设计”——每个项目都要走此流程，包括待办清单、单函数工具、配置变更。简单项目正是未经审视的假设造成最多浪费的地方。设计可以很短（真正简单的项目几句话即可），但必须呈现并获得批准。
- 关于收费、价格、平台支持等具体信息，资料中暂未提供。