用途
openspec-propose 用于为一次新变更生成完整的规划产物，让用户用一句话描述想构建的内容，即可得到一份可评审的提案。它属于规划阶段的工作流，明确不进入实现阶段：触发该工作流的请求只授权规划，即便请求中要求构建或修复，也不会编辑项目代码、不会启动 apply 工作流。产物呈现后工作流即停止，需等待用户新的请求再进入 apply。
主要能力
在默认的 spec 驱动 schema 下，生成的产物包括：
- proposal.md（做什么与为什么）
- specs/<capability-path>/spec.md（系统必须做什么，是增量 delta，而非主规范）
- design.md（如何做）
- tasks.md（实现步骤）
<capability-path> 是相对于 specs/ 的规范目录（例如 user-auth 或 identity/user-auth）。对于已有能力，需保留其完整路径；新能力则遵循项目已有的组织方式。
工作流还能根据 OpenSpec 的状态接口，解析 applyRequires（实现前所需的产物 ID）与各产物的依赖关系，按依赖顺序逐个创建产物，直到必需集合全部满足。必需集合不只是 applyRequires，还包括从其出发沿 requires 边可传递到达的全部产物。
使用方式
输入应包含一个 kebab-case 变更名，或对要构建内容的描述。如果未提供清晰输入，会向用户开放式提问：“你想处理什么变更？描述你想构建或修复的内容。”并从描述推导出 kebab-case 名称（例如“add user authentication”对应 add-user-auth）。若请求存在会实质性影响范围、外部可观察行为、兼容性或验收标准的歧义，会先向用户确认；小细节则做合理假设并记录在规划产物中。
工作流会确定 schema（默认使用配置的默认 schema，除非用户明确指定 --schema <schema-name>），创建变更目录，获取产物构建顺序，然后按依赖顺序逐个创建产物：读取该产物的 instructions（其中包含 context、rules、template、instruction、resolvedOutputPath、dependencies 等），读取已完成依赖文件（始终从磁盘重读），按模板写入文件，并在每次创建后重新运行状态检查。
关于 store：store 是本机注册的独立 OpenSpec 仓库。若用户指定某个 store 或工作位于其中，会运行 openspec store list --json 发现已注册的 store id，然后在读取或写入 specs 与变更的相关命令上传递 --store <id>（包括 new change、status、instructions、list、show、validate、archive、doctor、context、view）。一旦选定，该 --store <id> 在工作流余下部分保持粘性；命令打印的提示也会带上该标志，后续跟进需继续保留。未使用 store 时，命令作用于最近的本地 openspec/ 根目录。
当用户准备好实现时，必须显式启动 apply 工作流。最终提示用户可运行 $openspec-apply-change（Codex）或 /openspec-apply-change（其他智能体），或要求应用该变更。
产物创建原则
以每个产物类型对应的 instruction 字段为权威指引；若 instruction 指定用某个技能或命令创建产物，则调用它而不是自行写文件，并随后确认 resolvedOutputPath 处的文件存在。以 schema 定义各产物应包含的内容，以 template 作为输出文件的结构。context 与 rules 是给执行者的约束，不是文件内容，不得把 <context>、<rules>、<project_context> 块复制进产物。
适用场景
用户希望快速描述一个要构建或修复的内容并直接获得完整提案；希望在编写代码前先产出提案、规范增量、设计与任务清单；希望在明确授权后才进入实现。也适用于存在多个 OpenSpec store、需要指定变更落点的情况。
限制与边界
- 该工作流仅做规划，禁止实现变更、启动 apply 工作流或编辑项目代码。
- 必须创建 apply 阶段传递依赖的全部产物，而不只是 apply.requires 中列出的 ID。
- 状态检查只反映文件是否存在，因此 applyRequires 产物显示 done 并不意味着其依赖已存在；应依据各产物的 requires 边而非 status 构建必需集合。
- 状态为 skipped 的产物视为已满足（变更在 .openspec.yaml 中声明了 skip_specs），绝不可尝试创建它。
- 仅在 status 已报告 skipped，或其自身 instruction 标明为条件性（如“仅在……时创建”）时才可跳过某产物。spec 驱动下的 design.md 属于条件性；specs 只能依据上述 skipped 状态跳过，不能凭自身判断。
- 依赖是使能条件而非门禁：若某必需产物仅因跳过了条件性依赖而仍被阻塞，仍应写出它。
- 若已存在同名变更，会询问用户是继续该变更还是新建。
- 每个产物写入后需验证文件存在再继续下一个。
暂未提供
该资料未说明定价、收费模式、支持平台与具体效果数据等信息。