用途：deep-design 用于把已确认的 Product Brief 转化为可执行的 Build Contract，让另一个智能体能直接实施，而无需自行发明产品或设计决策。它只设计实现契约，不做生产实现；隔离的视觉预览仅在环境允许且被要求时作为设计证据，不属于生产改动。
主要能力：先验证输入，确认目标用户、期望结果、约束、非目标、决策、成功场景与关键假设，并在提出改动前检查现有系统；对已有 UI 区分必须行为与可替换呈现，对新 UI 以确认的任务和状态为基础。随后沿相关系统边界梳理行为，只解决本次改动所需内容，包括公共行为、数据与状态、接口、错误、迁移兼容、无障碍、安全、可观测性、发布与回滚，并尽量沿用现有项目模式。必要时引入领域、架构、前端、原型、视觉设计等专业能力，但专业结论要回写进合同，不产生并行流程。UI 结构或交互重要时走 UI 设计分支，后端改动可跳过。
使用方式：需要先有已确认的 Product Brief；问题只针对涉及目标、优先级、风险偏好、审美或权限的关键决策。优先使用当前客户端可调用的原生提问接口，如不可用则用简洁文字提问。设计完成后按字段产出 Build Contract，涵盖真实来源、期望行为、必须保留项、非目标、接口数据状态错误、无障碍与安全、UI 范围与批准方向、证据与预览状态、动效与组件选择、目标视口、必须通过的场景、实现切片与任务、验证发布计划、剩余风险。任务应可纵向执行、依赖清晰、可追溯到行为与场景。合同需经确认，且无未决的重要行为、接口、任务、验证、发布或权限问题（含预览批准）后，才交给 deep-build。
限制：不实现生产改动；不虚构 OpenSpec 配置或 schema；相关 OpenSpec 变更已激活时沿用其官方流程并以其产物为唯一物理合同。资料未提供具体价格、平台支持范围与完整示例。