用 OpenSpec 按任务清单实现变更：从任务文件逐项落地…

当项目已用 OpenSpec 管理变更、需要按 tasks 清单逐项实现代码时使用。

适用场景

解决思路

1. 选择 store：若用户指定了 store 或工作位于某个 store 中，先运行 `openspec store list --json` 获取已注册的 store id，然后在读写 specs 和 changes 的命令（`new change`、`status`、`instructions`、`list`、`show`、`validate`、`archive`、`doctor`、`context`、`schemas`、`view`）上追加 `--store <id>`；一旦选定，后续整个流程都保持该 flag（sticky）。下文所有未带 scope 的示例都是简写，执行前都要补上该 flag，例如运行 `openspec status --change "<name>" --json --store "<id>"`。其他命令不接受该 flag。命令打印的提示已带该 flag，后续命令继续保留。未指定 store 时，命令作用于最近的本地 `openspec/` 根目录。
2. 项目检查：在第一个写操作（`new change`、`archive`、`sync specs` 或编写 artifact 文件）之前，先运行 `openspec list --json`（若已选定 store 则加 `--store <id>`，此时 store 即根目录）并读取 `root`。有 root 对象说明项目已配置；`"root": null` 说明未配置（此处没有 `openspec/` 目录，`openspec new change` 之类的写操作会顺带创建它），该命令也会以非零码退出，这是正常回答而非 CLI 故障，应读取 JSON 而不是重试或绕过。
3. 处理 `root: null` 的例外：若 `status` 的错误信息以 `Declared in` 或 `Invalid store declaration in` 开头并指向本项目的 `openspec/config.yaml`（或 `config.yml`），说明项目通过其声明的 store 使用 OpenSpec，但本机无法解析（store 未注册或 `store:` 行格式错误）。不要当作未初始化而跳过后续分支：在写入前停止，向用户展示该错误的 `message` 和 `fix`。
4. 无 root 时按进入方式分支：若是自动选择（你自己选了此工作流，用户未提及 OpenSpec、未点名此 skill、未运行其 slash 命令），停止使用 OpenSpec，按未安装 OpenSpec 的方式正常回答请求，不要要求用户做任何配置，也不要提及 OpenSpec 配置。若是用户显式请求 OpenSpec（点名 OpenSpec、点名此 skill 或运行其 slash 命令），在写入前停止并询问如何继续：为本项目做配置（`openspec init`）、指向已有 store（`--store <id>`）、或本次不使用 OpenSpec。等待用户回答。
5. 两种分支下都不要把创建 root 作为副作用：用户未要求前不要运行 `openspec init`，不要手工创建 `openspec/` 文件，也不要让命令创建它。
6. 确定变更名：若提供了名称（如 `/openspec-apply-change add-auth`）则直接使用；否则从对话上下文推断；若只有一个活跃变更则自动选择；若含糊不清，运行 `openspec list --json` 获取可用变更并让用户选择。始终宣告 "Using change: <name>" 及覆盖方式（如 `/openspec-apply-change <other>`）。
7. 运行 `openspec status --change "<name>" --json` 检查状态以理解 schema，解析 JSON 中的 `schemaName`（所用工作流，如 "spec-driven"）、`planningHome`、`changeRoot`、`actionContext`（规划范围与编辑约束），以及哪个 artifact 包含任务（spec-driven 通常是 "tasks"，其他 schema 查 status）。
8. 运行 `openspec instructions apply --change "<name>" --json` 获取 apply 指令，返回 `contextFiles`（artifact ID 到具体文件路径数组，随 schema 变化，可能是 proposal/specs/design/tasks 或 spec/tests/implementation/docs）、进度（总数、完成、剩余）、带状态的任务列表、基于当前状态的动态指令、可选的 `context`（来自所选 root 的当前必需项目指令输入）、可选的 `operationGuidance`（apply 的当前建议性指导）、以及 `missingArtifacts`（存在时，为无输出的必需 artifact id）。
9. 处理 apply 指令返回的状态：若 `state: "blocked"`，展示消息并暂停实现；若 `missingArtifacts` 非空，建议用 `/openspec-continue-change` 创建它们；否则按 CLI 指令从已有规划 artifact 创建或修复 schema 配置的跟踪文件。阻塞期间不要假设其他 artifact 已就绪或开始实现。若 `state: "all_done"`，祝贺并建议归档。否则进入实现。
10. 把 `context` 当作必需的 prompt 级输入：阅读并考虑它，在实现时应用相关项目事实、约定和约束。把 `operationGuidance` 当作可选附加建议：阅读并考虑每一条，对适用且与内置工作流兼容的条目予以遵循。
11. 将 `context` 和 `operationGuidance` 与 CLI 返回的状态、缺失 artifact、任务、进度、`contextFiles` 及内置 `instruction` 严格区分：它们不是任务完成的证据，不替代内置指令，也不允许绕过 blocked 状态。若 context 与内置指令、用户明确选择或 CLI 控制值冲突，报告冲突并保留控制值。若 guidance 不适用或与这些控制输入冲突，不要遵循并说明原因。这些是 prompt 级行为契约，不是可强制执行的检查。
12. 读取 apply 指令输出中 `contextFiles` 下列出的每个文件路径。文件取决于所用 schema：spec-driven 为 proposal、specs、design、tasks；其他 schema 按 CLI 输出的 contextFiles 执行。除非用户另行要求，不要把 `context` 或 `operationGuidance` 原文复制进实现文件或规划 artifact。
13. 展示当前进度：所用 schema、进度（"N/M tasks complete"）、剩余任务概览、CLI 返回的动态指令。
14. 循环实现任务直到完成或阻塞：对每个待办任务，显示正在处理哪个任务，做所需的代码改动，保持改动最小且聚焦，在 tasks 文件中把 `- [ ]` 改为 `- [x]` 标记完成，然后继续下一个任务。
15. 遇到以下情况暂停：任务不清晰则请求澄清；实现暴露设计问题则建议更新 artifact；任务需要超出 spec 和 tasks 描述的工作，或你倾向于删减、收窄、推迟、接受对指定行为的例外以使其适配，则暴露新增范围并询问，不要静默吸收；遇到错误或阻塞则报告并等待指示；用户打断。
16. 完成或暂停时展示状态：本次会话完成的任务、总体进度（"N/M tasks complete"）；若全部完成则建议归档；若暂停则说明原因并等待指示。
17. 实现过程中的输出格式：`## Implementing: <change-name> (schema: <schema-name>)`，然后 `Working on task 3/7: <task description>`、实现内容、`✓ Task complete`，逐任务重复。
18. 完成时的输出格式：`## Implementation Complete`，列出 `**Change:**`、`**Schema:**`、`**Progress:** 7/7 tasks complete ✓`、`### Completed This Session` 下勾选的任务列表，并提示可用 `/openspec-archive-change` 归档。
19. 暂停时的输出格式：`## Implementation Paused`，列出 `**Change:**`、`**Schema:**`、`**Progress:** 4/7 tasks complete`、`### Issue Encountered` 及问题描述、`**Options:**` 下的若干选项，最后问 "What would you like to do?"。
20. 持续处理任务直到完成或阻塞；开始前始终读取 context 文件（来自 apply 指令输出）；任务含糊则先暂停询问再实现；实现暴露问题则暂停并建议更新 artifact；代码改动保持最小并限定在每个任务范围内；每完成一个任务立即更新任务复选框；遇错误、阻塞或需求不清就暂停，不要猜测。
21. 当任务需要超出 spec 描述的工作时，暴露新增范围并暂停——绝不静默收窄、推迟或简化掉指定行为。
22. 只有当任务的指定行为被完整实现时才标记 `- [x]`，部分完成或推迟时不要标记。
23. 使用 CLI 输出中的 contextFiles，不要假设具体文件名。
24. 不要用 context 或 operation guidance 作为任务完成的证据。
25. 应用相关项目 context；与工作流控制输入冲突时报告冲突。
26. 考虑每一条 guidance 条目；对不适用或冲突的建议说明原因。
27. 不要把运行时 context 或 operation guidance 复制进实现文件或规划 artifact。
28. 保留 CLI 控制的 blocked/ready/all-done 行为与完成标准。
29. 支持 fluid 工作流：本 skill 可在任意时刻调用（所有 artifact 完成前若有 tasks、部分实现后、与其他 action 交错）；允许更新 artifact——若实现暴露设计问题，建议更新 artifact，不锁定阶段，灵活推进。

适用边界 · 注意事项

• 项目未使用 OpenSpec 且用户未显式请求 OpenSpec 时（自动选择场景），不要使用本流程，按普通请求回答。
• 项目未初始化且用户未明确要求配置时，不要运行 `openspec init` 或手工创建 `openspec/` 文件。
• apply 指令返回 `state: "blocked"` 时，不要开始实现或假设其他 artifact 已就绪。