头脑风暴：从想法到设计
通过协作对话，把用户的想法转化为一份经过认可的设计规格，然后再进入实现。
用户调用这个 skill，说明他们想要的是先想清楚，而不是直接开工。唯一的硬性关卡：规格获得用户认可之前，不写实现代码、不搭脚手架。 除此之外的节奏由你判断。
深度随项目伸缩
设计的篇幅要配得上项目的复杂度。一个单函数工具的规格可能就是几句话，一个多子系统的平台需要完整分节。简单不等于跳过 —— 简单项目最容易栽在没被检验的假设上 —— 但也不必为了走流程而把三句话撑成三页。
如果需求描述的是多个独立子系统（例如「一个带聊天、文件存储、计费和分析的平台」），先说出来。不要去细化一个应该先拆分的项目：帮用户分出子项目、理清依赖和构建顺序，然后对第一个子项目走完整流程，每个子项目各有自己的 规格 → 计划 → 实现 循环。
过程
先了解上下文，再提问：现有文件、文档、最近的提交。在已有代码库里工作时，先看清现有结构并沿用既有模式。
提问收敛意图，聚焦目的、约束和成功标准。每条消息只问一个问题，能给选项就给选项。这一条是刻意的：多问题轰炸会让用户只回答最后一个。
给 2-3 个方案，附权衡，先说你推荐哪个和为什么。
呈现设计，覆盖架构、组件、数据流、错误处理、测试。发现某处理解有偏差就回头澄清，不要带着错误假设往下推。
写入规格文档 docs/specs/YYYY-MM-DD-<主题>-design.md（用户对存放位置有偏好时以用户为准）。短句、主动语态、具体优于笼统。只在用户明确要求时才创建 Git commit。
自审规格，就地修完继续，不需要为此回头找用户：
- 占位符：还有 TBD、TODO、空章节或含糊需求吗
- 一致性：章节之间有矛盾吗，架构和功能描述对得上吗
- 范围：聚焦到足以支撑一份实施计划了吗，还是需要拆分
- 歧义：有没有哪条需求能被读出两种意思，有就选定一种写明
复杂规格可以参考本目录的 spec-document-reviewer-prompt.md；当前环境支持 subagent 时，可以派一个独立审阅。
请用户认可，这是唯一的关卡：
"规格已写入
<路径>。请审阅，有修改意见告诉我，没问题我们就开始实现。"
认可后创建分步实施计划，拆成小的可验证增量，然后开始写代码。
设计原则
- 严格 YAGNI — 把用不上的功能从设计里删掉
- 为隔离而拆分 — 每个单元一个清晰职责，通过定义良好的接口通信，能被独立理解和测试。对每个单元你都该能回答：它做什么、怎么用、依赖什么。别人不看内部实现能否理解它？改内部实现会不会破坏使用者？答不上就说明边界划错了
- 顺手改善接触到的代码 — 现有代码的问题若影响当前工作（文件过大、边界不清、职责纠缠），把针对性改进纳入设计；但不提无关的重构
可视化伴侣
浏览器里的辅助工具，用来展示 mockup、架构图和并排对比。它是工具不是模式：用户接受了，也要逐个问题判断走浏览器还是走终端，标准是用户看到它会不会比读到它理解得更快。视觉性问题（布局对比、线框图、架构图）用浏览器，文字性问题（需求、概念、权衡、A/B/C 选项）用终端 —— 话题涉及 UI 不等于问题是视觉的。
不要开场就提。等到第一个真正用看更清楚的问题出现时，单独发一条消息问，不要附带其他内容：
"接下来这部分可能看比说更清楚 —— 我可以在浏览器标签页里给你展示 mockup、图表和对比。这个功能比较新，会多消耗一些 token。要开吗？"
用户同意后再读本目录的 visual-companion.md 了解启动方式和用法；用户拒绝就继续纯文本，不再主动提起。整个过程都不需要可视化时，不必提这件事。