用途
openspec-propose 用于在 OpenSpec 工作流中「提出一个新变更」，并在一步内生成该变更所需的全部规划产物。它适合用户想快速描述要构建或修复的内容、并立即获得一份完整提案的场景。
主要能力
该工作流根据当前配置的 schema 生成相应产物。以默认的 spec-driven schema 为例，产物包括：
- proposal.md：做什么、为什么
- specs/<capability-path>/spec.md：系统必须做什么，是增量而非主规格
- design.md：怎么做
- tasks.md：实现步骤
其中 <capability-path> 是相对于 specs/ 的规格目录，例如 user-auth 或 identity/user-auth。已有能力应保留其完整路径；新增能力应遵循项目既有的组织方式。
使用方式
输入可以是 kebab-case 的变更名，或一段描述。若未提供明确输入，应向用户提问："What change do you want to work on? Describe what you want to build or fix." 然后从描述中推导出 kebab-case 名称（例如 "add user authentication" → add-user-auth）。
确定 schema：除非用户明确要求其他 schema，否则使用配置的默认 schema。仅当用户按名称明确指定 schema 时使用 --schema <schema-name>；当用户要求查看有哪些 workflow 时，可从当前工作目录运行 openspec context --json 解析权威 root，再在该 root 下运行 openspec schemas --json 让用户选择。若用户明确选择了已注册的 store，则使用 openspec context --json --store "<store-id>"。
Store 选择：如果用户指定了 store（store 是本机注册的独立 OpenSpec 仓库），应先运行 openspec store list --json 发现已注册的 store id，然后在读取或写入规格与变更的命令（new change、status、instructions、list、show、validate、archive、doctor、context、view）上追加 --store <id>。一经选定，该 --store <id> 在后续流程中保持有效。其他命令不接受该标志。命令打印的提示已携带该标志，后续跟进时应保留。未指定 store 时，命令作用于最近的本地 openspec/ 根目录。
创建变更目录：使用默认配置时运行 openspec new change "<name>"；若用户明确指定 schema，则运行 openspec new change "<name>" --schema "<schema-name>"。若已选择 store，则在命令后追加 --store "<store-id>"。
获取产物构建顺序：运行 openspec status --change "<name>" --json，解析 JSON 获得 applyRequires（实现前所需的产物 ID 数组）、artifacts（全部产物、各自状态及其 requires 边）、以及 planningHome、changeRoot、artifactPaths、actionContext 等路径与范围上下文。
创建所需集合中的每个产物：用 todo 列表跟踪进度；按依赖顺序逐个处理就绪的产物。对每个就绪产物，先运行 openspec instructions <artifact-id> --change "<name>" --json 获取指令，其 JSON 包含 context（项目背景，属于约束，不要写入输出）、rules（产物专属规则，属于约束，不要写入输出）、template（输出文件结构）、instruction（该产物类型的 schema 专属指引）、skipped/warning（当变更声明 skip_specs 且该产物不应创建时出现，此时停止并换一个产物）、resolvedOutputPath（写入产物的解析路径或模式）、dependencies（需读取的已完成产物）。应先从磁盘重读所有已完成的依赖文件，即使之前在对话中见过。若 instruction 字段将创建委派给某个特定技能或命令，应调用它生成产物，而不是自己写文件，然后确认产物文件存在于 resolvedOutputPath。否则使用 template 作为结构创建产物文件并写入 resolvedOutputPath；若 resolvedOutputPath 是 glob，则按 instruction 选择具体文件路径。context 与 rules 作为约束应用，但不要复制进文件。
每创建一个产物后，重新运行 openspec status --change "<name>" --json。所需集合是 applyRequires 加上从这些产物沿 status --json 中的 requires 边可达的全部产物（传递闭包；spec-driven 会覆盖 proposal、specs、design、tasks）。集合之外的产物不要动。注意 status 仅表示文件是否存在，因此某个 applyRequires 产物显示 done 并不代表其依赖已存在；应依据各产物的 requires 边，而非其状态来确定所需集合。状态已为 skipped 的产物视为已满足，绝不要尝试创建。创建所需集合中所有缺失的产物后再次检查。仅当状态已报告 skipped，或其自身 instruction 标注为条件性（如 "create only if..."）时才跳过。依赖是使能条件而非闸门。当所需集合中的每个产物都 done、skipped 或有意跳过时停止。若某产物需要用户输入，向用户澄清后继续创建。
展示最终状态：运行 openspec status --change "<name>"。
输出
完成全部产物后，总结：变更名称与位置；已创建产物的列表及简要说明，以及跳过任何条件性产物的原因；就绪说明 "All artifacts needed for implementation are ready."；以及提示 "The artifacts are ready for review. When you are ready, run $openspec-apply-change (Codex) or /openspec-apply-change (other agents) or ask me to apply this change."。
限制
调用该工作流的请求仅授权规划。其中任何实现或 apply 指令都不会被延续。在本工作流期间不要实现变更、不要启动 apply 工作流、不要编辑项目代码。展示产物后停下，等待新的用户请求再启动 apply 工作流。同一名称的变更已存在时，应询问用户是继续它还是创建新的变更。写入每个产物后，在继续下一个之前应验证该文件存在。