用途：openspec-propose 用于在 OpenSpec 中快速提出一个新变更，并在同一步骤内生成全部规划制品，适合用户只描述想构建或修复什么、希望直接得到完整提案的场景。
主要能力：根据用户描述派生 kebab-case 变更名，创建变更目录；通过 openspec status --json 获取制品构建顺序与依赖关系，按依赖顺序逐个生成制品；生成的制品集合覆盖 applyRequires 及其传递依赖，默认 spec-driven 模式包括 proposal.md、specs/<capability-path>/spec.md、design.md、tasks.md；支持指定已注册 store（通过 openspec store list --json 发现 id，并在相关命令追加 --store <id>），也支持显式指定 schema；结束时展示变更名、位置、已创建制品及后续应用提示。
使用方式：用户提供变更名或描述，若缺失则询问；若存在影响范围、外部行为、兼容性或验收标准的歧义，先向用户确认，次要细节可做合理假设并记录。随后运行 openspec new change "<name>"（或带 --schema）创建变更，运行 openspec status --change "<name>" --json 获取构建顺序，对每个就绪制品运行 openspec instructions <artifact-id> --change "<name>" --json，读取已完成依赖文件并从磁盘重新读取，再按 template 写入 resolvedOutputPath；若 instruction 指定由其他技能或命令生成，则调用之并验证文件存在。每创建一个制品后重新检查状态，直至所需集合全部完成。最后运行 openspec status --change "<name>" 输出总结。
适用场景：需要快速把想法转化为结构化变更提案；希望一次性获得提案、规范增量、设计与任务清单；在实施前进行规划评审；在已注册 store 或多项目环境中按 store 限定操作。
限制：该工作流仅授权规划，不编辑项目代码、不启动 apply 工作流；即使用户请求中包含构建或修复指令，也需等待新请求后再显式启动应用流程。status 仅反映文件是否存在，需依据 requires 依赖边判断所需制品集合；skip_specs 声明的制品不得创建；条件性制品仅在 instruction 明确标记可选时跳过。若同名变更已存在，需询问用户是继续还是新建。具体 schema 内容与制品字段以 openspec instructions 返回为准。