openspec-continue-change

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Continue working on a change by creating the next artifact.

Input: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.

Steps

If no change name provided, prompt for selection
Run
```
openspec list --json
```
to get available changes sorted by most recently modified. Then use the AskUserQuestion tool to let the user select which change to work on.
Present the top 3-4 most recently modified changes as options, showing:
- Change name
- Schema (from
```
schema
```
  field if present, otherwise "spec-driven")
- Status (e.g., "0/5 tasks", "complete", "no tasks")
- How recently it was modified (from
```
lastModified
```
  field)
Mark the most recently modified change as "(Recommended)" since it's likely what the user wants to continue.

IMPORTANT: Do NOT guess or auto-select a change. Always let the user choose.
Check current status
bash
```
openspec status --change "<name>" --json
```
Parse the JSON to understand current state. The response includes:
- ```
schemaName
```
  : The workflow schema being used (e.g., "spec-driven")
- ```
artifacts
```
  : Array of artifacts with their status ("done", "ready", "blocked")
- ```
isComplete
```
  : Boolean indicating if all artifacts are complete
Act based on status:
If all artifacts are complete (
isComplete: true
):
- Congratulate the user
- Show final status including the schema used
- Suggest: "All artifacts created! You can now implement this change or archive it."
- STOP
If artifacts are ready to create (status shows artifacts with
```
status: "ready"
```
):
- Pick the FIRST artifact with
```
status: "ready"
```
  from the status output
- Get its instructions:
  bash
```
openspec instructions <artifact-id> --change "<name>" --json
```
- Parse the JSON. The key fields are:
  - ```
  context
```
  : Project background (constraints for you - do NOT include in output)
- ```
rules
```
    : Artifact-specific rules (constraints for you - do NOT include in output)
  - ```
  template
```
  : The structure to use for your output file
- ```
instruction
```
    : Schema-specific guidance
  - ```
  outputPath
```
  : Where to write the artifact
- ```
dependencies
```
    : Completed artifacts to read for context
- Create the artifact file:
  - Read any completed dependency files for context
  - Use
```
template
```
    as the structure - fill in its sections
  - Apply
```
context
```
    and
```
rules
```
    as constraints when writing - but do NOT copy them into the file
  - Write to the output path specified in instructions
- Show what was created and what's now unlocked
- STOP after creating ONE artifact
If no artifacts are ready (all blocked):
- This shouldn't happen with a valid schema
- Show status and suggest checking for issues
After creating an artifact, show progress
bash
```
openspec status --change "<name>"
```

Output

After each invocation, show:

Which artifact was created
Schema workflow being used
Current progress (N/M complete)
What artifacts are now unlocked
Prompt: "Want to continue? Just ask me to continue or tell me what to do next."

Artifact Creation Guidelines

The artifact types and their purpose depend on the schema. Use the

instruction

field from the instructions output to understand what to create.

Common artifact patterns:

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

proposal.md: Ask user about the change if not clear. Fill in Why, What Changes, Capabilities, Impact.
- The Capabilities section is critical - each capability listed will need a spec file.
specs/<capability>/spec.md: Create one spec per capability listed in the proposal's Capabilities section (use the capability name, not the change name).
design.md: Document technical decisions, architecture, and implementation approach.
tasks.md: Break down implementation into checkboxed tasks.

For other schemas, follow the

instruction

field from the CLI output.

Guardrails

Create ONE artifact per invocation
Always read dependency artifacts before creating a new one
Never skip artifacts or create out of order
If context is unclear, ask the user before creating
Verify the artifact file exists after writing before marking progress
Use the schema's artifact sequence, don't assume specific artifact names
IMPORTANT:
```
context
```
and
```
rules
```
are constraints for YOU, not content for the file
- Do NOT copy
```
<context>
```
  ,
```
<rules>
```
  ,
```
<project_context>
```
  blocks into the artifact
- These guide what you write, but should never appear in the output

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

输入：可选择性指定变更名称。如果未指定，检查是否可以从对话语境中推断。若语境模糊或不明确，必须提示用户选择可用的变更。

步骤

若未提供变更名称，提示用户选择
运行
```
openspec list --json
```
获取按最近修改时间排序的可用变更。然后使用AskUserQuestion工具让用户选择要处理的变更。
展示最近修改的3-4个变更作为选项，包含以下信息：
- 变更名称
- Schema（若
```
schema
```
  字段存在则使用该字段值，否则为"spec-driven"）
- 状态（例如："0/5 任务"、"已完成"、"无任务"）
- 最近修改时间（来自
```
lastModified
```
  字段）
将最近修改的标记为"(推荐)"，因为这很可能是用户想要继续处理的变更。

重要提示：请勿猜测或自动选择变更，务必让用户自行选择。
检查当前状态
bash
```
openspec status --change "<name>" --json
```
解析JSON以了解当前状态。响应包含：
- ```
schemaName
```
  : 正在使用的工作流schema（例如："spec-driven"）
- ```
artifacts
```
  : 包含状态（"done"、"ready"、"blocked"）的工件数组
- ```
isComplete
```
  : 表示所有工件是否已完成的布尔值
根据状态执行操作:
若所有工件已完成（
isComplete: true
）:
- 向用户表示祝贺
- 展示最终状态，包括所使用的schema
- 建议："所有工件已创建完成！您现在可以实施此变更或将其归档。"
- 停止操作
若有工件可创建（状态显示存在
```
status: "ready"
```
的工件）:
- 从状态输出中选择第一个
```
status: "ready"
```
  的工件
- 获取其创建说明：
  bash
```
openspec instructions <artifact-id> --change "<name>" --json
```
- 解析JSON。关键字段包括：
  - ```
  context
```
  : 项目背景（是约束您的规则，请勿写入输出文件）
- ```
rules
```
    : 工件特定规则（是约束您的规则，请勿写入输出文件）
  - ```
  template
```
  : 输出文件要使用的结构
- ```
instruction
```
    : 特定于schema的指导说明
  - ```
  outputPath
```
  : 工件的写入路径
- ```
dependencies
```
    : 需读取以获取上下文的已完成工件
- 创建工件文件:
  - 读取所有已完成的依赖工件以获取上下文
  - 使用
```
template
```
    作为结构，填充各部分内容
  - 编写时需遵循
```
context
```
    和
```
rules
```
    的约束，但请勿将其复制到文件中
  - 写入到说明中指定的输出路径
- 展示已创建的工件以及现在解锁的内容
- 每次调用仅创建一个工件，之后停止操作
若无工件可创建（全部处于阻塞状态）:
- 有效的schema下不应出现此情况
- 展示状态并建议检查问题
创建工件后，展示进度
bash
```
openspec status --change "<name>"
```

输出

每次调用后，展示以下内容：

已创建的工件
正在使用的schema工作流
当前进度（已完成N/M）
现在解锁的工件
提示："要继续吗？只需让我继续或告诉我下一步要做什么。"

工件创建指南

工件类型及其用途取决于所使用的schema。使用说明输出中的

instruction

字段了解要创建的内容。

常见工件模式：

spec-driven schema（提案→规范→设计→任务）：

proposal.md：若变更内容不明确，询问用户。填写原因、变更内容、功能、影响。
- 功能部分至关重要——列出的每个功能都需要一个规范文件。
specs/<capability>/spec.md：为提案功能部分中列出的每个功能创建一个规范（使用功能名称，而非变更名称）。
design.md：记录技术决策、架构和实现方案。
tasks.md：将实现过程拆分为带复选框的任务。

对于其他schema，请遵循CLI输出中的

instruction

字段。

约束规则

每次调用仅创建一个工件
创建新工件前务必读取依赖工件
切勿跳过工件或打乱顺序创建
若上下文不明确，创建前询问用户
标记进度前，验证工件文件是否已成功写入
使用schema规定的工件顺序，不要假设特定的工件名称
重要提示：
```
context
```
和
```
rules
```
是约束您的规则，而非文件内容
- 请勿将
```
<context>
```
  、
```
<rules>
```
  、
```
<project_context>
```
  块复制到工件中
- 这些规则指导您的编写，但绝不能出现在输出文件中