openspec-update-change

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Revise a change's existing planning artifacts and keep them coherent. Never edit code.

Store selection: If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run

openspec store list --json

to discover registered store ids, then pass

--store <id>

on the commands that read or write specs and changes (

new change

status

instructions

list

show

validate

archive

doctor

context

view

). Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local

openspec/

root.

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

Select the change

If a name is provided, use it. Otherwise:
- Infer from conversation context if the user mentioned a change
- Auto-select if only one active change exists
- If ambiguous, run
```
openspec list --json
```
  to get available changes sorted by most recently modified, and ask the user to select one
When prompting, 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 update.
Always announce: "Using change: <name>" and how to override (e.g.,
```
/openspec-update-change <other>
```
).
Get the change's artifacts
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", "skipped", "ready", "blocked")
- ```
isComplete
```
  : Boolean indicating if all artifacts are complete
- ```
planningHome
```
  ,
```
changeRoot
```
  ,
```
artifactPaths
```
  , and
```
actionContext
```
  : path and scope context. Use these instead of assuming repo-local paths.
The artifact ids and paths come from the active schema - do NOT assume them, and do NOT branch on hardcoded artifact names. Custom schemas must work unchanged.
The files to edit are
```
artifactPaths.<id>.existingOutputPaths
```
- the concrete files that exist on disk, already glob-expanded for glob artifacts (e.g.
```
specs/**/*.md
```
). Do NOT write to
```
resolvedOutputPath
```
: for a glob artifact it is still the glob pattern, not a real file.
Understand the request
- If the user asked for a specific revision ("the design now uses X"), that is the starting edit.
- If they only said "update" / "make this coherent", treat it as a coherence review: read the existing artifacts and check them against each other for contradictions, gaps, and duplication.
Read and reconcile
- Read the artifact(s) the request touches and the change's other existing artifacts.
- Apply the requested edit. Then check every other existing artifact against it - in ANY direction: an edit to a later artifact may require revising an earlier one, not only the other way around. Build order is a useful reading order, not a constraint on which artifacts may be revised.
- Note everything that is now inconsistent, missing, or contradictory.
- Revise only files that already exist (
```
existingOutputPaths
```
  ). Do NOT create artifacts that don't exist yet, and do NOT invent new files under a glob artifact - note them and point the user to
```
/openspec-continue-change
```
  to create them.
- If the change is already coherent, say so and make no edits.
Confirm and apply, one artifact at a time
- Show each proposed revision and why. Write only after the user confirms.
- If the user rejects a revision, do not write it - leave that artifact unchanged.
- When a substantial rewrite is needed, get that artifact's rules and template first:
  bash
```
openspec instructions <artifact-id> --change "<name>" --json
```
Point to the next step (guidance only - NEVER act on it)
- Artifacts still missing -> suggest
```
/openspec-continue-change
```
  to create them.
- Change already implemented (tasks checked off / already applied) -> the code may no longer match the revised plan; suggest
```
/openspec-apply-change
```
  to carry the delta into code.
- Everything done and implemented -> suggest
```
/openspec-archive-change
```
  .

Output

After each invocation, show:

Which artifacts were revised (and which proposed revisions were rejected)
Anything deferred to
```
/openspec-continue-change
```
(not-yet-created artifacts or files)
Where the change stands and the recommended next command

Guardrails

Planning artifacts only - NEVER edit implementation code. If the revised plan implies code changes, stop and point to
```
/openspec-apply-change
```
.
Use the artifact ids and paths reported by
```
openspec status
```
; never branch on hardcoded artifact names.
Edit only the concrete files in
```
existingOutputPaths
```
; never write to a glob
```
resolvedOutputPath
```
.
Do not advance the build frontier: no new artifacts, no new files under glob artifacts - that is
```
/openspec-continue-change
```
's job.
Confirm every edit with the user before writing.
If the request changes the change's intent rather than refining it, recommend starting fresh with
```
/openspec-new-change
```
(the "Update vs. Start Fresh" heuristic).
```
/openspec-continue-change
```
and
```
/openspec-new-change
```
may not be installed (core profile). When suggesting one that is unavailable, point to the CLI instead:
```
openspec status --change "<name>" --json
```
shows the next artifact and
```
openspec instructions <artifact-id> --change "<name>" --json
```
explains how to create it.

修订变更的现有规划工件并保持它们的一致性。绝不编辑代码。

存储库选择：如果用户指定了存储库（存储库是在本机注册的独立OpenSpec仓库），或者工作内容位于某个存储库中，请运行

openspec store list --json

来发现已注册的存储库ID，然后在读取或写入规范和变更的命令（

new change

、

status

、

instructions

、

list

、

show

、

validate

、

archive

、

doctor

、

context

、

view

）中添加

--store <id>

参数。其他命令不接受此参数。命令输出的提示信息已包含该参数；后续操作请保留该参数。如果未指定存储库，命令将作用于最近的本地

openspec/

根目录。

输入：可选择指定变更名称。如果未指定，请检查是否可以从对话上下文推断。如果模糊或有歧义，必须提示用户选择可用的变更。

步骤

选择变更

如果提供了名称，则使用该名称。否则：
- 如果用户提到过某个变更，从对话上下文推断
- 如果只有一个活跃变更，自动选择
- 如果存在歧义，运行
```
openspec list --json
```
  获取按最近修改时间排序的可用变更，并让用户选择一个
提示时，展示最近修改的3-4个变更作为选项，包含：
- 变更名称
- 架构（如果存在
```
schema
```
  字段则使用该字段，否则为“规范驱动”）
- 状态（例如：“0/5 任务”、“已完成”、“无任务”）
- 最近修改时间（来自
```
lastModified
```
  字段）
将最近修改的标记为“(推荐)”，因为这很可能是用户想要更新的变更。
务必告知：“正在使用变更：<名称>”以及如何覆盖（例如：
```
/openspec-update-change <其他变更>
```
）。
获取变更的工件
bash
```
openspec status --change "<name>" --json
```
解析JSON以了解当前状态。响应包含：
- ```
schemaName
```
  ：正在使用的工作流架构（例如：“规范驱动”）
- ```
artifacts
```
  ：包含状态（“done”、“skipped”、“ready”、“blocked”）的工件数组
- ```
isComplete
```
  ：布尔值，表示所有工件是否已完成
- ```
planningHome
```
  、
```
changeRoot
```
  、
```
artifactPaths
```
  和
```
actionContext
```
  ：路径和范围上下文。请使用这些信息，不要假设仓库本地路径。
工件ID和路径来自活跃架构——不要假设它们，也不要基于硬编码的工件名称进行分支处理。自定义架构必须无需修改即可正常工作。
需要编辑的文件是
```
artifactPaths.<id>.existingOutputPaths
```
——磁盘上已存在的具体文件，对于glob工件（例如
```
specs/**/*.md
```
）已进行glob展开。不要写入
```
resolvedOutputPath
```
：对于glob工件，它仍然是glob模式，而非真实文件。
理解请求
- 如果用户要求进行特定修订（“现在设计使用X”），这就是起始编辑点。
- 如果用户仅说“更新”/“使其保持一致”，则将其视为一致性审查：读取现有工件并检查它们之间是否存在矛盾、遗漏和重复。
读取与协调
- 读取请求涉及的工件以及变更的其他现有工件。
- 应用请求的编辑。然后检查所有其他现有工件是否与之一致——任何方向：对后续工件的编辑可能需要修订先前的工件，而不仅仅是反过来。构建顺序是有用的读取顺序，但不是限制哪些工件可以修订的约束。
- 记录所有现在不一致、缺失或矛盾的内容。
- 仅修订已存在的文件（
```
existingOutputPaths
```
  ）。不要创建尚未存在的工件，也不要在glob工件下创建新文件——记录这些情况并引导用户使用
```
/openspec-continue-change
```
  来创建它们。
- 如果变更已经一致，请告知用户并不要进行任何编辑。
确认并应用，逐个工件进行
- 展示每个提议的修订内容及其原因。仅在用户确认后再写入。
- 如果用户拒绝某个修订，不要写入——保持该工件不变。
- 当需要大幅重写时，先获取该工件的规则和模板：
  bash
```
openspec instructions <artifact-id> --change "<name>" --json
```
指出下一步（仅提供指导——绝不主动执行）
- 仍有缺失的工件 -> 建议使用
```
/openspec-continue-change
```
  来创建它们。
- 变更已实施（任务已勾选/已应用）-> 代码可能不再与修订后的计划匹配；建议使用
```
/openspec-apply-change
```
  将差异同步到代码中。
- 所有工作已完成并实施 -> 建议使用
```
/openspec-archive-change
```
  。

输出

每次调用后，展示：

哪些工件已修订（以及哪些提议的修订被拒绝）
哪些内容推迟到
```
/openspec-continue-change
```
处理（尚未创建的工件或文件）
当前变更的状态以及推荐的下一个命令

约束规则

仅处理规划工件——绝不编辑实现代码。如果修订后的计划意味着需要修改代码，请停止操作并引导用户使用
```
/openspec-apply-change
```
。
使用
```
openspec status
```
返回的工件ID和路径；绝不要基于硬编码的工件名称进行分支处理。
仅编辑
```
existingOutputPaths
```
中的具体文件；绝不写入glob类型的
```
resolvedOutputPath
```
。
不要推进构建边界：不创建新工件，不在glob工件下创建新文件——这是
```
/openspec-continue-change
```
的职责。
写入前务必让用户确认每个编辑。
如果请求改变了变更的意图而非细化它，建议使用
```
/openspec-new-change
```
重新开始（“更新 vs. 重新开始”启发式规则）。
```
/openspec-continue-change
```
和
```
/openspec-new-change
```
可能未安装（核心配置文件）。当建议使用的命令不可用时，请指向CLI：
```
openspec status --change "<name>" --json
```
会显示下一个工件，
```
openspec instructions <artifact-id> --change "<name>" --json
```
会说明如何创建它。