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

通过创建下一个 artifact 来继续处理变更。

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

**步骤**

1. **如果未提供变更名称,提示选择**

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

   将最近修改的前 3-4 个变更作为选项呈现,显示:
   - 变更名称
   - Schema(如果存在 `schema` 字段则显示,否则为 "spec-driven")
   - 状态(例如 "0/5 个任务"、"完成"、"无任务")
   - 最近修改时间(来自 `lastModified` 字段)

   将最近修改的变更标记为 "(推荐)",因为这可能是用户想要继续的内容。

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

2. **检查当前状态**
   ```bash
   openspec status --change "<name>" --json
   ```
   解析 JSON 以了解当前状态。响应包括:
   - `schemaName`: 正在使用的工作流 schema(例如 "spec-driven")
   - `artifacts`: 包含状态的 artifacts 数组("done"、"ready"、"blocked")
   - `isComplete`: 指示所有 artifacts 是否完成的布尔值

3. **根据状态采取行动**:

   ---

   **如果所有 artifacts 都已完成(`isComplete: true`)**:
   - 祝贺用户
   - 显示最终状态,包括使用的 schema
   - 建议: "所有 artifacts 已创建! 现在可以实施此变更或归档它。"
   - 停止

   ---

   **如果 artifacts 准备创建**(状态显示 `status: "ready"` 的 artifacts):
   - 从状态输出中选择**第一个** `status: "ready"` 的 artifact
   - 获取其说明:
     ```bash
     openspec instructions <artifact-id> --change "<name>" --json
     ```
   - 解析 JSON。关键字段是:
     - `context`: 项目背景(对您的约束 - 不要包含在输出中)
     - `rules`: Artifact 特定规则(对您的约束 - 不要包含在输出中)
     - `template`: 用于输出文件的结构
     - `instruction`: Schema 特定指导
     - `outputPath`: artifact 的写入位置
     - `dependencies`: 已完成的 artifacts,读取以获取上下文
   - **创建 artifact 文件**:
     - 读取任何已完成的依赖文件以获取上下文
     - 使用 `template` 作为结构 - 填充其各个部分
     - 在写入时应用 `context` 和 `rules` 作为约束 - 但不要将它们复制到文件中
     - 写入说明中指定的输出路径
   - 显示创建的内容以及现在解锁的内容
   - 创建一个 artifact 后停止

   ---

   **如果没有 artifacts 准备好(全部被阻塞)**:
   - 使用有效的 schema 不应该发生这种情况
   - 显示状态并建议检查问题

4. **创建 artifact 后,显示进度**
   ```bash
   openspec status --change "<name>"
   ```

**输出**

每次调用后,显示:
- 创建了哪个 artifact
- 正在使用的 Schema 工作流
- 当前进度(已完成 N/M)
- 现在解锁了哪些 artifacts
- 提示: "想要继续吗? 只需让我继续或告诉我下一步该做什么。"

**Artifact 创建指南**

artifact 类型及其用途取决于 schema。使用说明输出中的 `instruction` 字段来了解要创建什么。

常见 artifact 模式:

**spec-driven schema**(proposal → specs → design → tasks):
- **proposal.md**: 如果不清楚,询问用户关于变更的信息。填写为什么、什么变更、能力、影响。
  - Capabilities 部分至关重要 - 列出的每个能力都需要一个 spec 文件。
- **specs/<capability>/spec.md**: 为 proposal 的 Capabilities 部分列出的每个能力创建一个 spec(使用能力名称,而不是变更名称)。
- **design.md**: 记录技术决策、架构和实施方法。
- **tasks.md**: 将实施分解为带复选框的任务。

对于其他 schemas,遵循 CLI 输出中的 `instruction` 字段。

**护栏**
- 每次调用创建一个 artifact
- 在创建新 artifact 之前始终读取依赖 artifacts
- 永远不要跳过 artifacts 或无序创建
- 如果上下文不清楚,在创建前询问用户
- 写入后验证 artifact 文件存在,然后再标记进度
- 使用 schema 的 artifact 序列,不要假设特定的 artifact 名称
- **重要**: `context` 和 `rules` 是对您的约束,不是文件内容
  - 不要将 `<context>`、`<rules>`、`<project_context>` 块复制到 artifact 中
  - 这些指导您写什么,但永远不应出现在输出中