openspec-continue-change

Continue working on a change by creating the next artifact.

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). Once selected, treat --store <id> as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run openspec status --change "<name>" --json --store "<id>", not the unscoped form shown below. 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

1. 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 continue.

   Always announce: "Using change: " and how to override (e.g., $openspec-continue-change (Codex) or /openspec-continue-change (other agents) <other>).

2. Check current status

   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")
   • isPlanningComplete: Boolean indicating if all planning artifacts are complete. Older CLI versions expose the same value as isComplete.
   • planningHome, changeRoot, artifactPaths, and actionContext: path and scope context. Use these instead of assuming repo-local paths.

3. Act based on status:

   ---

   If all planning artifacts are complete (isPlanningComplete: true, or legacy isComplete: true):

   • Congratulate the user
   • Show final status including the schema used
   • Suggest: "Planning is complete! You can now implement this change. Once implementation and any tracked work are complete, 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:

     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
     • resolvedOutputPath: Resolved path or pattern to write the artifact
     • dependencies: Completed artifacts to read for context (entries with skipped: true have no files - do not look for them)
     • skipped/warning: present when the change declares skip_specs and this artifact must NOT be created - pick another artifact
   • Create the artifact file:
     • Read any completed dependency files for context - always re-read them from disk, even if you saw them earlier in the conversation (the user may have edited them)
     • If the instruction field delegates creation to a specific skill or command, invoke it to produce the artifact instead of writing the file yourself, then verify the artifact file exists at resolvedOutputPath
     • Otherwise 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 resolvedOutputPath specified in instructions. If it is a glob pattern, choose the concrete file path using the schema instruction and the change's context
   • Show what was created and what's now unlocked
   • STOP after creating ONE artifact