头脑风暴：从想法到设计

把尚未明确的目标、约束和关键取舍收敛成足以指导实现的设计。沿用用户已有的决定，不重新审批已认可的方案。

范围与完成条件

• 用户要求先讨论、先审方案或暂不实现时，以设计交付为终点；未经认可不写实现代码、不搭脚手架。
• 用户已要求实现时，只澄清会实质改变范围、成本或结果的未决问题；普通、可逆的选择沿用项目惯例并说明假设，不额外插入一次完整设计审批。
• 设计明确且实现已获授权后，继续完成实现及对应验证，不在第一版代码或计划完成时提前交回。

收敛设计

先读取与当前设计有关的代码和文档，能查到的事实不问用户。只有历史决定影响当前取舍时才追溯提交。

聚焦目的、约束和成功标准，优先问最影响设计的一个问题。存在真实替代方案时比较权衡并给出推荐；路径明确时不为凑数提供多个方案。

设计深度随复杂度伸缩：简单工具可以是几句话；复杂系统说明相关的边界、数据流、失败处理和验证方式。多个子系统需要分阶段时，说明依赖与构建顺序，不擅自把用户要求的完整交付缩成第一个子项目。

需要持久规格时写入 docs/specs/YYYY-MM-DD-<主题>-design.md，优先使用用户指定的位置。短小、一次性的设计可以直接在回复中给出，不强制创建文件。只在用户明确要求时创建 Git commit。

交付前消除会影响实施的缺口、矛盾和歧义。复杂规格可用 spec-document-reviewer-prompt.md 做审阅；只有已获授权且当前环境支持时才委派独立审阅。

保留能解释设计的约束和取舍，避免未请求的功能、抽象或顺手重构。

可视化伴侣

仅在布局、线框图或空间关系更适合视觉讨论时提出使用浏览器伴侣。用户同意后再读 visual-companion.md 并启动；拒绝则继续纯文本。话题涉及 UI 本身不构成启动理由。