用 OpenSpec 继续推进变更并生成下一个工件时

在已使用 OpenSpec 的项目中，为某个变更按 schema 顺序创建下一个规划工件并展示进度。

适用场景

解决思路

1. 若用户指定了 store（本机注册的独立 OpenSpec 仓库）或工作位于某个 store 中，先运行 `openspec store list --json` 获取已注册的 store id，然后在读写 specs 和 changes 的命令（`new change`、`status`、`instructions`、`list`、`show`、`validate`、`archive`、`doctor`、`context`、`schemas`、`view`）上追加 `--store <id>`；选定后该 flag 在后续流程中保持粘性，例如运行 `openspec status --change "<name>" --json --store "<id>"`；其他命令不接受该 flag；命令打印的提示已带该 flag，后续调用要保留；未指定 store 时命令作用于最近的本地 `openspec/` 根目录。
2. 在首次写入（`new change`、`archive`、`sync specs` 或编写工件文件）前做项目检查：运行 `openspec list --json`（选定 store 时加 `--store <id>`，此时 store 即根目录）并读取 `root`；有 root 对象说明项目已配置；`"root": null` 说明未配置，此处没有 `openspec/` 目录，写入命令会顺带创建它，且命令会以非零退出码结束——这是答案而非 CLI 故障，应读取 JSON 而不要重试或绕过。
3. 若 `status` 错误信息以 `Declared in` 或 `Invalid store declaration in` 开头并指向本项目的 `openspec/config.yaml`（或 `config.yml`），说明项目通过其声明的 store 使用 OpenSpec，但本机无法解析（store 未注册或 `store:` 行格式错误）；不要当作未初始化而跳过后续分支，应在写入前停止并向用户展示该错误的 `message` 和 `fix`。
4. 若无 root 且是自动选择的工作流（你自己选了它，用户未提及 OpenSpec、未点名该技能、未运行其斜杠命令），停止使用 OpenSpec，按没有安装 OpenSpec 的方式正常回答请求，不要要求用户做任何设置，也不要提及 OpenSpec 设置。
5. 若无 root 且是显式 OpenSpec 请求（用户点名 OpenSpec、点名该技能或运行其斜杠命令），在写入前停止并询问如何继续：设置本项目（`openspec init`）、指向已有 store（`--store <id>`）或本次请求不使用 OpenSpec；等待用户回答。
6. 两种分支下都不要顺带创建根目录：用户未要求前不要运行 `openspec init`，不要手工创建 `openspec/` 文件，也不要让命令创建它。
7. 确定变更：若提供了名称则直接使用；否则从对话上下文推断用户提到的变更；若只有一个活跃变更则自动选择；若有歧义，运行 `openspec list --json` 获取按最近修改排序的可用变更并让用户选择。
8. 提示选择时，展示最近修改的前 3-4 个变更作为选项，包含：变更名称、schema（取 `schema` 字段，否则为 "spec-driven"）、状态（如 "0/5 tasks"、"complete"、"no tasks"）、最近修改时间（取 `lastModified` 字段）；将最近修改的变更标记为 "(Recommended)"，因为它很可能是用户想继续的。
9. 始终声明："Using change: <name>" 以及如何覆盖（如 `/openspec-continue-change <other>`）。
10. 运行 `openspec status --change "<name>" --json` 并解析 JSON 了解当前状态，响应包含：`schemaName`（所用工作流 schema，如 "spec-driven"）、`artifacts`（各工件及其状态 "done"、"skipped"、"ready"、"blocked"）、`isPlanningComplete`（所有规划工件是否完成，旧版 CLI 用 `isComplete`）、`planningHome`、`changeRoot`、`artifactPaths`、`actionContext`（路径与作用域上下文，应使用这些而非假定仓库本地路径）。
11. 若所有规划工件已完成（`isPlanningComplete: true` 或旧版 `isComplete: true`）：祝贺用户，展示含所用 schema 的最终状态，建议 "Planning is complete! You can now implement this change. Once implementation and any tracked work are complete, archive it."，然后停止。
12. 若有工件可创建（状态中有 `status: "ready"` 的工件）：从状态输出中选取第一个 `status: "ready"` 的工件，运行 `openspec instructions <artifact-id> --change "<name>" --json` 获取其说明。
13. 解析 instructions 的 JSON，关键字段：`context`（项目背景，作为你的约束，不要写入输出）、`rules`（工件专属规则，作为你的约束，不要写入输出）、`template`（输出文件所用结构）、`instruction`（schema 专属指引）、`resolvedOutputPath`（写入工件的解析路径或模式）、`dependencies`（需阅读的已完成工件，`skipped: true` 的条目没有文件，不要去找）、`skipped`/`warning`（当变更声明 skip_specs 且该工件不得创建时出现，应改选其他工件）。
14. 创建工件文件：阅读已完成的依赖文件获取上下文——始终从磁盘重新读取，即使之前在对话中看过（用户可能已编辑）；若 `instruction` 字段把创建委托给特定技能或命令，则调用它来产出工件而非自己写文件，然后确认工件文件存在于 `resolvedOutputPath`；否则以 `template` 为结构填写各节；写入时把 `context` 和 `rules` 作为约束应用，但不要把它们复制进文件；写入 instructions 中指定的 `resolvedOutputPath`，若它是 glob 模式，则依据 schema 指引和变更上下文选择具体文件路径。
15. 展示创建了什么以及现在解锁了什么，创建一个工件后停止。
16. 若无工件可创建（全部阻塞）：这不应发生在有效 schema 下，展示状态并建议检查问题。
17. 创建工件后运行 `openspec status --change "<name>"` 展示进度。
18. 每次调用后输出：创建了哪个工件、所用 schema 工作流、当前进度（N/M 完成）、现在解锁了哪些工件，以及提示 "Want to continue? Just ask me to continue or tell me what to do next."。
19. 工件类型及其用途取决于 schema；instructions 输出中的 `instruction` 字段是每个工件的权威指引，即使工件名称熟悉（proposal.md、tasks.md 等）也要遵循，因为自定义 schema 可能为同名文件定义不同内容或流程。
20. 若 `instruction` 字段指示使用特定技能或命令创建工件，则调用它而非直接编写工件。
21. 每次调用只创建一个工件。
22. 创建新工件前始终阅读依赖工件——从磁盘重新读取，而非凭对话记忆（文件可能自上次查看后已变化）。
23. 绝不跳过工件或乱序创建。
24. 若上下文不清晰，创建前先询问用户。
25. 写入后确认工件文件存在再标记进度。
26. 使用 schema 的工件顺序，不要假定具体工件名称。
27. `context` 和 `rules` 是给你的约束，不是文件内容：不要把 `<context>`、`<rules>`、`<project_context>` 块复制进工件；它们指导你写什么，但绝不应出现在输出中。

适用边界 · 注意事项

• 项目未使用 OpenSpec（`openspec list --json` 返回 `"root": null`）且该工作流是自动选择的——应正常回答请求，不要提及或设置 OpenSpec。
• 项目通过本机无法解析的 store 声明使用 OpenSpec（status 错误以 `Declared in` 或 `Invalid store declaration in` 开头）——应在写入前停止并展示错误的 message 和 fix。
• 用户未要求时不要运行 `openspec init`、手工创建 `openspec/` 文件或让命令顺带创建根目录。