skills/openspec-continue-change/SKILL.md
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). 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:
openspec list --json to get available changes sorted by most recently modified, and ask the user to select oneWhen prompting, present the top 3-4 most recently modified changes as options, showing:
schema field if present, otherwise "spec-driven")lastModified field)Mark the most recently modified change as "(Recommended)" since it's likely what the user wants to continue.
Always announce: "Using change: <name>" and how to override (e.g., /openspec-continue-change <other>).
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")isComplete: Boolean indicating if all artifacts are completeplanningHome, changeRoot, artifactPaths, and actionContext: path and scope context. Use these instead of assuming repo-local paths.Act based on status:
If all artifacts are complete (isComplete: true):
If artifacts are ready to create (status shows artifacts with status: "ready"):
status: "ready" from the status outputopenspec instructions <artifact-id> --change "<name>" --json
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 fileinstruction: Schema-specific guidanceresolvedOutputPath: Resolved path or pattern to write the artifactdependencies: 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 artifactinstruction 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 resolvedOutputPathtemplate as the structure - fill in its sectionscontext and rules as constraints when writing - but do NOT copy them into the fileresolvedOutputPath specified in instructions. If it is a glob pattern, choose the concrete file path using the schema instruction and the change's contextIf no artifacts are ready (all blocked):
After creating an artifact, show progress
openspec status --change "<name>"
Output
After each invocation, show:
Artifact Creation Guidelines
The artifact types and their purpose depend on the schema. The instruction field from the instructions output is the authoritative guidance for each artifact - follow it even when the artifact has a familiar name (proposal.md, tasks.md, etc.), since custom schemas may define different content or a different process for the same file names.
If the instruction field directs you to use a specific skill or command to create the artifact, invoke it instead of writing the artifact directly.
Guardrails
context and rules are constraints for YOU, not content for the file
<context>, <rules>, <project_context> blocks into the artifact