用途：openspec-propose 用于快速描述想构建或修复的内容，并在一步内创建变更并生成全部规划产物。它只做规划，不修改项目代码；触发它的请求只授权规划，即使用户要求直接实现，也需在产物完成后停下，等待新的用户请求再启动 apply 工作流。
主要能力与默认产物：默认 spec-driven 模式下生成 proposal.md（做什么与为什么）、specs/<capability-path>/spec.md（系统必须做什么的增量规格，而非主规格）、design.md（怎么做）和 tasks.md（实施步骤）。<capability-path> 是 specs/ 下的目录，如 user-auth；已有能力保留完整路径，新能力遵循项目既有组织方式。
使用方式：输入应包含 kebab-case 变更名或需求描述；若信息不足，需询问用户想构建或修复什么。若存在影响范围、外部可观察行为、兼容性或验收标准的歧义，先询问；小细节可合理假设并记录在产物中。确定 schema：默认用配置的 schema，用户明确指定名称时加 --schema <schema-name>。创建变更：openspec new change "<name>"，指定 schema 时为 openspec new change "<name>" --schema "<schema-name>"。获取构建顺序：openspec status --change "<name>" --json，解析 applyRequires、artifacts、planningHome、changeRoot、artifactPaths、actionContext。按依赖顺序逐个创建：openspec instructions <artifact-id> --change "<name>" --json 获取 context、rules、template、instruction、resolvedOutputPath、dependencies；先重读磁盘上已完成的依赖文件，再按 template 写入 resolvedOutputPath，context 与 rules 仅作约束不得写入文件。若 instruction 指向特定技能或命令，应调用它生成产物。每完成一个产物后重新检查状态，直到所需集合全部完成、跳过或有意跳过。最后运行 openspec status --change "<name>" 并汇总变更名、位置、产物清单及跳过的条件产物。
存储选择：若用户指定 store（本机注册的独立 OpenSpec 仓库）或工作位于其中，先运行 openspec store list --json 获取 id，再在读写规格与变更的命令上追加 --store <id>（如 new change、status、instructions、list、show、validate、archive、doctor、context、view），一旦选定即在整个工作流中生效。其余命令不接受该参数。无 store 时作用于最近的本地 openspec/ 根。
适用场景：需要把模糊需求快速转化为结构化规划产物，供后续 apply 阶段实施。
限制：不编辑项目代码、不启动 apply 工作流；仅当 status 报告 skipped 或 instruction 明确标记可选时才跳过产物，specs 只能因 skipped 状态跳过，不得自行判断。status 只反映文件是否存在，不能据此认定依赖已满足，需依据 requires 边构建所需集合。若同名变更已存在，需询问是继续还是新建。产物的具体字段结构、条件产物判定由 schema 与 instructions 决定，资料未给出完整模板内容。