实现来自 OpenSpec 变更的任务。
存储选择： 如果用户命名了一个存储（存储是在此机器上注册的独立 OpenSpec 仓库），或者工作在某个存储中，请运行 openspec store list --json 以发现已注册的存储 ID，然后在读取或写入规范和变更的命令（new change, status, instructions, list, show, validate, archive, doctor, context, schemas, view）中传递 --store <id>。一旦选定，将 --store <id> 视为工作流剩余部分的粘性标志。以下这些命令的每个无范围的示例都是简写：运行前，附加该标志。例如，运行 openspec status --change "<name>" --json --store "<id>"，而不是下面显示的无范围形式。其他命令不接受该标志。命令打印的提示已经携带了该标志；在后续操作中保留它。如果没有存储，命令将作用于最近的本地 openspec/ 根目录。
项目检查： 这些步骤期望项目已经使用了 OpenSpec。在第一个写入任何内容的步骤（new change, archive, sync specs 或编写工件文件）之前，确认项目有根目录：运行 openspec list --json（当选择了存储时使用 --store <id>，因为此时存储就是根目录）并读取 root。一个根对象意味着项目已设置好。"root": null 表示没有设置 - 这里没有 openspec/ 目录，并且像 openspec new change 这样的写入操作会作为副作用创建一个。该命令也会以非零退出，这表示了那个答案而不是 CLI 损坏，因此请读取 JSON 而不是重试或绕过它。
一个 "root": null 情况与设置无关：当一条 status 错误消息以 Declared in 或 Invalid store declaration in 开头，并且指出了此项目的 openspec/config.yaml（或 config.yml）时，该项目确实通过其声明的存储使用了 OpenSpec，但此机器无法解析该存储（存储未注册，或 store: 行格式错误）。不要将其视为未初始化并跳过下面的分支：在写入之前停止，并向用户显示该错误的 message 和 fix。
否则，如果没有根目录，接下来的情况取决于如何到达此工作流：
- 自动选择：您自己选择了此工作流，用户没有命名 OpenSpec、命名此技能或运行其斜杠命令。停止使用 OpenSpec 并正常回答请求，就像没有安装 OpenSpec 一样。不要要求他们设置任何东西，也不要提及 OpenSpec 设置。
- 明确请求 OpenSpec：用户命名了 OpenSpec、命名了此技能或运行了其斜杠命令。在写入之前停止，并询问如何继续：设置此项目（
openspec init）、定位他们已经有的存储（--store <id>），或在此请求中不使用 OpenSpec。等待他们的回答。
在这两种分支中，永远不要作为副作用创建根目录：不要运行 openspec init，除非用户要求；不要手动创建 openspec/ 文件；也不要让命令创建它。
输入：可选地指定一个变更名称（例如，/opsx:apply add-auth）。如果省略，检查是否可以从对话上下文中推断出来。如果模糊或有歧义，您必须提示用户提供可用的变更。
步骤
-
选择变更
如果提供了名称，则使用它。否则：
- 如果用户在对话中提到了一个变更，从上下文中推断
- 如果只有一个活动变更，则自动选择
- 如果模糊不清，运行
openspec list --json获取可用变更，并让用户选择一个
始终声明：“使用变更：”以及如何覆盖（例如，
/opsx:apply <other>）。 -
检查状态以了解模式
openspec status --change "<name>" --json解析 JSON 以了解：
schemaName：正在使用的工作流（例如，“spec-driven”）。planningHome、changeRoot和actionContext：规划范围和编辑约束。- 哪个工件包含任务（对于 spec-driven 通常是“tasks”，对于其他模式检查状态）。
-
获取应用指令
openspec instructions apply --change "<name>" --json这会返回：
contextFiles：工件 ID -> 具体的文件路径数组（因模式而异 - 可能是 proposal/specs/design/tasks 或 spec/tests/implementation/docs）。- 进度（总任务数、已完成、剩余）。
- 带有状态、源路径和源行的任务列表。
- 基于当前状态的动态指令。
- 可选的
context：来自选定根的当前必需项目指令输入。 - 可选的
operationGuidance：当前适用于应用的建议性指导。 missingArtifacts（当存在时）：没有输出的必需工件 ID。
处理状态：
- 如果
state: "blocked"：显示消息并暂停实现。- 如果
missingArtifacts非空：建议完成缺失的工件。运行openspec status --change "<name>" --json，选择下一个ready状态的工件（不是skipped或blocked），并使用openspec instructions "<artifact-id>" --change "<name>" --json获取其规则和模板。在两个命令中都保留选定的--store <id>。 - 否则，按照 CLI 指令从现有的规划工件创建或修复模式配置的跟踪文件。不要在阻塞状态下假设另一个工件已准备就绪或开始实现。
- 如果
- 如果
state: "all_done"：报告所有跟踪的任务都已完成，并建议在归档前进行适当的审查或验证。 - 否则：继续实现。
将
context视为必需的提示级输入。阅读并考虑它，并在实现时应用相关的项目事实、约定和约束。 将operationGuidance视为可选附加建议。阅读并考虑每条条目，并按照适用且与内置工作流兼容的条目操作。将这两个字段与 CLI 返回的状态、缺失的工件、任务、进度、
contextFiles和内置instruction分开。它们不是任务完成的证据，不替代内置指令，也不允许绕过阻塞状态。如果上下文与内置指令、明确的用户选择或 CLI 控制的值冲突，报告冲突并保留控制值。如果指导不适用或与那些控制输入冲突，则不要遵循并解释原因。这些是提示级的行为契约，不是可强制执行的检查。 -
读取上下文文件
读取应用指令输出中
contextFiles下列出的每个文件路径。 文件取决于所使用的模式：- spec-driven：proposal、specs、design、tasks。
- 其他模式：遵循 CLI 输出的 contextFiles。
不要将
context或operationGuidance逐字复制到实现文件或规划工件中，除非用户单独要求该内容。 -
显示当前进度
显示：
- 正在使用的模式。
- 进度：“N/M 任务完成”。
- 剩余任务概览。
- 来自 CLI 的动态指令。
-
实现任务（循环直到完成或阻塞）
对于每个待处理的任务：
- 显示正在处理哪个任务。
- 进行所需的代码更改。
- 保持更改最小且专注。
- 在编辑之前，确认返回的
sourcePath和line处的复选框仍然与任务描述匹配；如果不匹配，重新运行应用指令并使用刷新的位置。 - 在返回的
sourcePath和line处将任务标记为完成：- [ ]→- [x]。 - 重新运行应用指令，确认该任务现在已完成并且进度已更改。
- 继续下一个任务。
暂停如果：
- 任务不清晰 → 请求澄清。
- 实现揭示了一个设计问题 → 建议更新工件。
- 任务需要超出规范和任务描述范围的工作，或者您想悄悄地删除、缩小、推迟或接受对指定行为的例外以使其适应 → 暴露增加的范围并询问；不要默默地吸收它。
- 遇到错误或阻塞 → 报告并等待指导。
- 用户中断。
-
完成或暂停时，显示状态
显示：
- 此会话完成的任务。
- 总体进度：“N/M 任务完成”。
- 如果全部完成：报告跟踪的任务已完成，并建议在归档前进行适当的审查或验证。
- 如果暂停：解释原因并等待指导。
实现期间的输出
## 正在实现：<change-name>（模式：<schema-name>）
正在处理任务 3/7：<task description>
[...正在实现...]
✓ 任务完成
正在处理任务 4/7：<task description>
[...正在实现...]
✓ 任务完成
完成时的输出
## 实现完成
**变更：** <change-name>
**模式：** <schema-name>
**进度：** 7/7 任务完成 ✓
### 本会话已完成
- [x] 任务 1
- [x] 任务 2
...
所有跟踪的任务都已完成。请在归档前适当地审查或验证变更。
您可以使用 `/opsx:archive` 归档此变更。
暂停时的输出（遇到问题）
## 实现已暂停
**变更：** <change-name>
**模式：** <schema-name>
**进度：** 4/7 任务完成
### 遇到的问题
<问题描述>
**选项：**
1. <选项 1>
2. <选项 2>
3. 其他方法
您希望怎么做？
防护机制
- 持续处理任务，直到全部完成或被阻塞。
- 始终在开始之前读取上下文文件（来自应用指令输出）。
- 如果任务模糊不清，暂停并在实现之前询问。
- 如果实现揭示了问题，暂停并建议更新工件。
- 保持代码更改最小化，并且范围仅限于每个任务。
- 完成每个任务后立即更新任务复选框。
- 遇到错误、阻塞或要求不明确时暂停 - 不要猜测。
- 当任务需要超出规范描述的工作时，暴露增加的范围并暂停 - 永远不要默默地缩小、推迟或简化指定的行为。
- 仅当任务的指定行为完全实现时，才将任务标记为
- [x]，而不是部分完成或推迟时。 - 使用 CLI 输出的 contextFiles，不要假设特定的文件名。
- 使用每个任务的 sourcePath 和 line 来更新其确切的复选框。
- 不要使用上下文或操作指导作为任务完成的证据。
- 应用相关的项目上下文；报告与控制工作流输入的冲突。
- 考虑每一条指导条目；解释任何不适用或有冲突的建议。
- 不要将运行时上下文或操作指导复制到实现文件或规划工件中。
- 保留 CLI 控制的 阻塞/就绪/全部完成 行为和完成标准。
流畅的工作流集成
此技能支持“变更操作”模型：
- 可随时调用：在所有工件完成之前（如果任务存在），部分实现之后，或与其他操作交错。
- 允许工件更新：如果实现揭示了设计问题，建议更新工件 - 不是阶段锁定，而是灵活地工作。