cfc/.opencode/skills/openspec-continue-change/SKILL.md

---

name: openspec-continue-change description: 通过创建下一个产物继续处理 OpenSpec 变更。当用户想要推进他们的变更、创建下一个产物或继续他们的工作流时使用。 license: MIT compatibility: Requires openspec CLI. metadata: author: openspec version: "1.0"

generatedBy: "1.1.1"

通过创建下一个产物继续处理变更。

输入：可选择指定变更名称。如果省略，检查是否可以从对话上下文中推断。如果模糊或不明确，必须提示可用的变更。

步骤

1. 如果没有提供变更名称，提示选择

运行 openspec list --json 以获取按最近修改排序的可用变更。然后使用 AskUserQuestion 工具 让用户选择要处理哪个变更。

提供前 3-4 个最近修改的变更作为选项，显示：

• 变更名称
• Schema（如果有 schema 字段，否则为 "spec-driven"）
• 状态（例如，"0/5 tasks", "complete", "no tasks"）
• 最近修改时间（来自 lastModified 字段）

将最近修改的变更标记为 "(Recommended)"，因为这很可能是用户想要继续的。

重要：不要猜测或自动选择变更。始终让用户选择。

1. 检查当前状态

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

   解析 JSON 以了解当前状态。响应包括：

   • schemaName：正在使用的工作流 Schema（例如，"spec-driven"）
   • artifacts：产物数组及其状态（"done", "ready", "blocked"）
   • isComplete：指示是否所有产物都已完成的布尔值

2. 根据状态行动：

---

如果所有产物都已完成 (isComplete: true)：

• 祝贺用户
• 显示最终状态，包括使用的 Schema
• 建议："所有产物已创建！你现在可以实施此变更或将其归档。"
• 停止

---

如果有产物准备创建（状态显示有 status: "ready" 的产物）：

• 从状态输出中选择第一个 status: "ready" 的产物

• 获取其指令：

   openspec instructions <artifact-id> --change "<name>" --json
  

• 解析 JSON。关键字段是：

  • context：项目背景（给你的约束 - 不要包含在输出中）
  • rules：产物特定规则（给你的约束 - 不要包含在输出中）
  • template：用于输出文件的结构
  • instruction：Schema 特定的指导
  • outputPath：写入产物的位置
  • dependencies：已完成的产物，用于阅读上下文

• 创建产物文件：

  • 阅读任何已完成的依赖文件以获取上下文
  • 使用 template 作为结构 - 填充其部分
  • 应用 context 和 rules 作为约束 - 但不要将它们复制到文件中
  • 写入指令中指定的输出路径

• 显示已创建的内容以及现在解锁的内容

• 在创建一个产物后停止

---

如果没有产物准备好（全部阻塞）：

• 这在有效 Schema 中不应发生
• 显示状态并建议检查问题

1. 创建产物后，显示进度

   openspec status --change "<name>"
   

输出

每次调用后，显示：

• 创建了哪个产物
• 正在使用的 Schema 工作流
• 当前进度（N/M 完成）
• 现在解锁了哪些产物
• 提示："想要继续吗？只需让我继续或告诉我下一步做什么。"

产物创建指南

产物类型及其用途取决于 Schema。使用指令输出中的 instruction 字段来了解要创建什么。

常见产物模式：

spec-driven schema (proposal → specs → design → tasks):

• proposal.md：如果不清楚，询问用户关于变更的信息。填写 Why, What Changes, Capabilities, Impact。
  • Capabilities 部分至关重要 - 列出的每个 capability 都需要一个 spec 文件。
• specs//spec.md：为 proposal 的 Capabilities 部分中列出的每个 capability 创建一个 spec（使用 capability 名称，而不是变更名称）。
• design.md：记录技术决策、架构和实施方法。
• tasks.md：将实施分解为带复选框的任务。

对于其他 Schema，遵循 CLI 输出中的 instruction 字段。

护栏

• 每次调用创建一个产物
• 在创建新产物之前，始终阅读依赖产物
• 绝不跳过产物或乱序创建
• 如果上下文不清楚，在创建之前询问用户
• 在标记进度之前，验证写入后产物文件是否存在
• 使用 Schema 的产物序列，不要假设特定的产物名称
• 重要：context 和 rules 是给你的约束，不是文件内容
  • 不要将 <context>, <rules>, <project_context> 块复制到产物中
  • 这些指导你写什么，但绝不应出现在输出中