用途：把用户想构建或修复的内容，一次性转化为 OpenSpec 变更提案及全部规划产物。该工作流只授权规划，不修改项目代码，也不启动实现；产物完成后即停止，等待用户新请求再进入 apply 工作流。
主要能力：按 schema 生成产物。默认 spec-driven schema 包括 proposal.md（做什么与为什么）、specs/<capability-path>/spec.md（系统必须做什么，是增量而非主 spec）、design.md（怎么做）、tasks.md（实现步骤）。capability-path 为 specs/ 下的相对目录，如 user-auth 或 identity/user-auth；已有能力保留完整路径，新能力遵循项目既有组织方式。
使用方式：输入需含 kebab-case 变更名或需求描述，否则先询问。若存在影响范围、外部可观察行为、兼容性或验收标准的歧义，先向用户确认；细节可合理假设并记录。默认使用配置的 schema，用户明确指定时用 --schema <schema-name>。创建变更目录：openspec new change "<name>"（指定 schema 时加 --schema）。用 openspec status --change "<name>" --json 获取 applyRequires、artifacts 及依赖边、路径上下文。按依赖顺序逐个产物执行 openspec instructions <artifact-id> --change "<name>" --json，读取 context、rules、template、instruction、resolvedOutputPath、dependencies，重读磁盘上的依赖文件，按 template 写入 resolvedOutputPath；若 instruction 指向特定技能或命令，则调用它并确认文件存在。每步后重跑 status，直到 applyRequires 及其传递依赖全部完成。最后运行 openspec status --change "<name>" 并汇总变更名、位置、产物清单与跳过项。
Store 选择：若用户指定 store 或工作位于其中，先运行 openspec store list --json 获取 id，再在读写 specs 与 changes 的命令（new change、status、instructions、list、show、validate、archive、doctor、context、view）上追加 --store <id>，选定后保持粘性；其他命令不接受该标志。未指定时作用于最近的本地 openspec/ 根。
限制：不得实现变更、启动 apply 或编辑项目代码；context 与 rules 是约束，不得写入产物文件；status 仅反映文件是否存在，需按 requires 边判断依赖；已标记 skipped 的产物不得创建；design.md 等条件性产物仅在 instruction 标明可选时跳过；同名变更已存在时先询问是继续还是新建。