ZDEV-XXR/make-videos-with-Remotion

实现 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/ 文件；也不要让任何命令创建它。

输入：可选地指定一个变更名称（例如，/openspec-apply-change add-auth）。如果省略，检查是否可以从对话上下文中推断出来。如果模糊或存在歧义，您必须提示用户选择可用的变更。

步骤

1. 选择变更

   如果提供了名称，则使用它。否则：

   • 如果用户提到了变更，从对话上下文中推断
   • 如果只有一个活跃的变更，则自动选择
   • 如果存在歧义，运行 openspec list --json 获取可用变更，并让用户选择一个

   始终宣布：“使用变更：<名称>”以及如何覆盖（例如，/openspec-apply-change <其他>）。

2. 检查状态以了解模式

   openspec status --change "<name>" --json
   

   解析 JSON 以了解：

   • schemaName：正在使用的工作流（例如，“spec-driven”）
   • planningHome、changeRoot 和 actionContext：规划范围和编辑约束
   • 哪个工件包含任务（对于 spec-driven 通常是“tasks”，对于其他模式请检查状态）

3. 获取应用指令

   openspec instructions apply --change "<name>" --json
   

   这将返回：

   • contextFiles：工件 ID 到具体文件路径的数组（因模式而异——可能是 proposal/specs/design/tasks 或 spec/tests/implementation/docs）
   • 进度（总计、已完成、剩余）
   • 任务列表及其状态、源路径和源行号
   • 基于当前状态的动态指令
   • 可选的 context：当前所选根目录必需的项目指令输入
   • 可选的 operationGuidance：当前适用于 apply 的建议性指导
   • 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 分开对待。它们不是任务完成的证据，不能替代内置指令，也不允许绕过阻塞状态。如果 context 与内置指令、明确的用户选择或 CLI 控制的值冲突，报告冲突并保留控制值。如果指导不适用或与那些控制输入冲突，不要遵循它，并解释原因。这些是提示级的行为契约，不是可强制执行的检查。

4. 读取上下文文件

   读取 apply 指令输出中 contextFiles 下列出的每个文件路径。 文件取决于所使用的模式：

   • spec-driven：proposal、specs、design、tasks
   • 其他模式：遵循 CLI 输出中的 contextFiles

   不要将 context 或 operationGuidance 逐字复制到实现文件或规划工件中，除非用户单独要求这些内容。

5. 显示当前进度

   显示：

   • 正在使用的模式
   • 进度：“N/M 个任务完成”
   • 剩余任务概览
   • CLI 提供的动态指令

6. 实现任务（循环直到完成或被阻塞）

   对于每个待处理的任务：

   • 显示正在处理的任务
   • 进行所需的代码更改
   • 保持更改最小化和聚焦
   • 在编辑之前，确认返回的 sourcePath 和 line 处的复选框仍然匹配任务描述；如果不匹配，重新运行 apply 指令并使用刷新的位置
   • 在返回的 sourcePath 和 line 处将任务标记为完成：- [ ] → - [x]
   • 重新运行 apply 指令并确认该任务现在已完成且进度已更改
   • 继续下一个任务

   如果出现以下情况则暂停：

   • 任务不明确 → 请求澄清
   • 实现揭示了设计问题 → 建议更新工件
   • 任务需要超出规范和任务描述的工作，或者您倾向于悄悄缩小、推迟或接受对指定行为的例外以使其符合要求 → 说明新增范围并询问；不要静默吸收
   • 遇到错误或阻塞 → 报告并等待指导
   • 用户中断

7. 完成或暂停时，显示状态

   显示：

   • 本次会话完成的任务
   • 整体进度：“N/M 个任务完成”
   • 如果全部完成：报告跟踪任务已完成，并建议在归档前进行适当的审查或验证
   • 如果暂停：解释原因并等待指导

实现期间的输出

## 正在实现：<变更名称>（模式：<模式名称>）

正在处理任务 3/7：<任务描述>
[...实现过程...]
✓ 任务完成

正在处理任务 4/7：<任务描述>
[...实现过程...]
✓ 任务完成

完成时的输出

## 实现完成

**变更：** <变更名称>
**模式：** <模式名称>
**进度：** 7/7 个任务完成 ✓

### 本次会话完成
- [x] 任务 1
- [x] 任务 2
...

所有跟踪任务已完成。请在归档前适当审查或验证变更。您可以通过 `/openspec-archive-change` 归档此变更。

暂停时的输出（遇到问题）

## 实现已暂停

**变更：** <变更名称>
**模式：** <模式名称>
**进度：** 4/7 个任务完成

### 遇到的问题
<问题描述>

**选项：**
1. <选项 1>
2. <选项 2>
3. 其他方法

您希望做什么？

护栏

• 持续处理任务直到完成或被阻塞
• 在开始之前始终读取上下文文件（来自 apply 指令输出）
• 如果任务模糊，暂停并在实现前询问
• 如果实现揭示问题，暂停并建议更新工件
• 保持代码更改最小化并限定在每个任务范围内
• 立即在完成每个任务后更新任务复选框
• 遇到错误、阻塞或不明确的请求时暂停——不要猜测
• 当任务需要超出规范描述的工作时，说明新增范围并暂停——永远不要悄悄缩小、推迟或简化指定的行为
• 只有当指定行为完全实现时才将任务标记为 - [x]，而不是部分完成或推迟时
• 使用 CLI 输出的 contextFiles，不要假设特定的文件名
• 使用每个任务的 sourcePath 和 line 来更新其确切的复选框
• 不要使用 context 或 operation guidance 作为任务完成的证据
• 应用相关的项目上下文；报告与控制性工作流输入的任何冲突
• 考虑每一条指导条目；解释任何不适用或冲突的建议
• 不要将运行时 context 或 operation guidance 复制到实现文件或规划工件中
• 保留 CLI 控制的 blocked/ready/all-done 行为和完成标准

流体工作流集成

此技能支持“对变更执行操作”模型：

• 随时可调用：在所有工件完成之前（如果存在任务）、部分实现之后、与其他操作交错进行
• 允许更新工件：如果实现揭示设计问题，建议更新工件——不受阶段锁定，工作流畅