用途：openspec-propose 是 OpenSpec 的规划工作流，当用户想快速描述要构建的内容并获得完整提案时使用。它创建变更并一步生成 schema 定义的全部规划产物，但不修改项目代码。
主要能力：按默认 spec-driven schema 生成 proposal.md（做什么与为什么）、specs/<capability-path>/spec.md（系统必须做什么，作为增量而非主 spec）、design.md（如何做）、tasks.md（实现步骤）。支持通过 --schema 指定工作流，或列出可用 workflows 供选择。支持注册的 store：先用 openspec store list --json 发现 id，再在读写 spec 与变更的命令（new change、status、instructions、list、show、validate、archive、doctor、context、view）上追加 --store <id>，选定后保持粘性。
使用方式：输入需包含 kebab-case 变更名或描述。若未提供，先询问用户。先用 openspec new change "<name>"（可选 --schema "<schema-name>"）创建变更目录；运行 openspec status --change "<name>" --json 获取 applyRequires、artifacts 依赖边与路径上下文；然后按依赖顺序，对每个就绪产物运行 openspec instructions <artifact-id> --change "<name>" --json，读取已完成依赖文件，按 template 结构写入 resolvedOutputPath。逐个创建后重新运行 status，直到所需集合（applyRequires 及其沿 requires 边可达的产物）全部为 done 或 skipped。最后运行 openspec status --change "<name>" 并汇总变更名、位置与产物清单。
适用场景：需要先形成完整、可评审的规划文档，再进入实现阶段的变更。用户可在评审后运行 $openspec-apply-change（Codex）或 /openspec-apply-change（其他代理）启动 apply。
限制：本工作流仅授权规划，即使原始请求要求构建或修复，也不得编辑项目代码、不得启动 apply 或实现；展示产物后应停止并等待新的用户请求。遇到会影响范围、外部可观察行为、兼容性或验收标准的歧义须先询问，微小细节可合理假设并记录。status 仅反映文件是否存在，仍需依据 requires 边构建必需集合；标为 skipped 的产物必须不存在，不得创建；条件性产物（如 spec-driven 的 design.md）仅在 instruction 标明可选时跳过。context 与 rules 是给执行者的约束，不得写入产物文件；<capability-path> 需沿用既有能力的完整路径。