用途：把尚未明确的目标、约束和关键取舍收敛成足以指导实现的设计。适用于用户要求先讨论、先审方案或暂不实现时；不用于 bug 修复、配置修改或照已有方案实现。
主要能力：沿用用户已有决定，不重新审批已认可的方案；先读取与当前设计有关的代码和文档，能查到的事实不问用户，只有历史决定影响当前取舍时才追溯提交；聚焦目的、约束和成功标准，优先问最影响设计的一个问题；存在真实替代方案时比较权衡并给出推荐，路径明确时不凑数提供多个方案。
设计深度随复杂度伸缩：简单工具可以是几句话；复杂系统说明相关的边界、数据流、失败处理和验证方式；多个子系统需要分阶段时说明依赖与构建顺序，不擅自把完整交付缩成第一个子项目。交付前消除会影响实施的缺口、矛盾和歧义。
使用方式：需要持久规格时写入 docs/specs/YYYY-MM-DD-<主题>-design.md，优先使用用户指定的位置；短小、一次性的设计可直接在回复中给出，不强制创建文件；只在用户明确要求时创建 Git commit。复杂规格可用 spec-document-reviewer-prompt.md 做审阅，只有已获授权且当前环境支持时才委派独立审阅。
可视化伴侣：仅在布局、线框图或空间关系更适合视觉讨论时提出使用浏览器伴侣；用户同意后再读 visual-companion.md 并启动，拒绝则继续纯文本；话题涉及 UI 本身不构成启动理由。
限制：未经认可不写实现代码、不搭脚手架；用户已要求实现时，只澄清会实质改变范围、成本或结果的未决问题，普通可逆选择沿用项目惯例并说明假设，不额外插入完整设计审批；设计明确且实现已获授权后，继续完成实现及对应验证，不在第一版代码或计划完成时提前交回。保留能解释设计的约束和取舍，避免未请求的功能、抽象或顺手重构。