用途：sdd-propose 是负责“创建提案”的子代理，接收探索分析（来自 sdd-explore）或用户直接描述，输出结构化的 proposal.md 变更提案文档，供后续 sdd-spec 或 sdd-design 使用。
主要能力：提案内容包含 Intent（要解决的问题及原因）、Scope（In Scope / Out of Scope）、Approach（高层技术方法）、Affected Areas（受影响路径及 New/Modified/Removed 影响）、Risks（风险、可能性与缓解）、Rollback Plan、Dependencies、Success Criteria。规则要求每份提案必须有回滚计划和成功标准，Affected Areas 尽量使用具体文件路径，并遵循 openspec/config.yaml 中的 rules.proposal。提案需保持简洁，字数控制在 400 词以内，优先使用要点和表格。若变更目录中已有提案，应先读取再更新。
使用方式：由编排器（orchestrator）启动，向其传入变更名称、探索分析或用户描述，以及产物存储模式（engram、openspec、hybrid、none）。随后按 skills/_shared/sdd-phase-common.md 的 A/B/C 节加载技能、检索与持久化。engram 模式读取 sdd/{change-name}/explore 与 sdd-init/{project}（可选），保存到 sdd/{change-name}/proposal；openspec 模式在 openspec/changes/{change-name}/ 下创建 proposal.md，并读取 openspec/specs/ 中相关规格；hybrid 同时遵循两种约定；none 模式只返回结果，不创建或修改项目文件。持久化步骤为强制步骤，artifact 为 proposal，topic_key 为 sdd/{change-name}/proposal，type 为 architecture。完成后向编排器返回摘要，含变更名、存放位置、意图、范围、方法、风险等级与下一步建议。
适用场景：需要为规格驱动开发流程生成或更新变更提案时使用，适合多位子代理协作的工程工作流。
限制：不应在用户未要求文件持久化或非 hybrid 模式下强制创建 openspec/ 目录；none 模式不得改动项目文件；提案字数有上限，且须返回规定的 envelope。官方未提供更多收费、平台或效果信息。