用途：在 OpenSpec 中提出一个新变更，并一次性生成该变更所需的全部规划产物。适用于用户想快速描述要构建或修复的内容，并拿到完整提案的场景。
主要能力：按 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 变更名或需求描述，否则先询问用户。创建变更：openspec new change "<name>"，指定 schema 时加 --schema "<schema-name>"。获取产物构建顺序：openspec status --change "<name>" --json，解析 applyRequires、artifacts 及其 requires 依赖边、planningHome、changeRoot、artifactPaths、actionContext。按依赖顺序逐个获取指令：openspec instructions <artifact-id> --change "<name>" --json，读取 template、instruction、resolvedOutputPath、dependencies，先重读磁盘上的依赖产物，再写入对应路径。若用户指定 store，先运行 openspec store list --json 获取 id，并在支持 --store 的命令上追加 --store "<id>"，选定后保持粘性。完成后运行 openspec status --change "<name>" 展示最终状态。
适用场景：需要结构化规划、评审后再实施的变更；需要生成规格增量与任务拆分的项目。
限制：本工作流仅授权规划，不得编辑项目代码、不得启动 apply 工作流或实现，即使原始请求要求构建或修复；产物呈现后应停止，等待新的用户请求再进入 apply。必须创建 apply 阶段传递依赖的全部产物，而非仅 apply.requires 列出的 id；status 仅反映文件是否存在，需依据 requires 边判断。已标记 skipped 的产物不得创建。存在会实质影响范围、外部可观察行为、兼容性或验收标准的歧义时须先询问；次要细节可合理假设并记录。同名变更已存在时询问是继续还是新建。具体命令输出格式与 schema 细节以实际 CLI 为准，资料未提供更多平台或收费信息。