openspec-apply-change

Implement tasks from an OpenSpec change.

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 (e.g.,

$openspec-apply-change (Codex) or /openspec-apply-change (other agents) add-auth

). 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 and ask the user to select one
Always announce: "Using change: <name>" and how to override (e.g.,
```
$openspec-apply-change (Codex) or /openspec-apply-change (other agents) <other>
```
).
Check status to understand the schema
bash
```
openspec status --change "<name>" --json
```
Parse the JSON to understand:
- ```
schemaName
```
  : The workflow being used (e.g., "spec-driven")
- ```
planningHome
```
  ,
```
changeRoot
```
  , and
```
actionContext
```
  : planning scope and edit constraints
- Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
Get apply instructions
bash
```
openspec instructions apply --change "<name>" --json
```
This returns:
- ```
contextFiles
```
  : artifact ID -> array of concrete file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
- Progress (total, complete, remaining)
- Task list with status
- Dynamic instruction based on current state
- Optional
```
context
```
  : current required project instruction input from the selected root
- Optional
```
operationGuidance
```
  : current advisory guidance for apply
Handle states:
- If
```
state: "blocked"
```
  (missing artifacts): show message, suggest using
```
$openspec-continue-change (Codex) or /openspec-continue-change (other agents)
```
  (if it is not installed, run
```
openspec status --change "<name>" --json
```
  to see the next artifact and
```
openspec instructions <artifact-id> --change "<name>" --json
```
  for how to create it)
- If
```
state: "all_done"
```
  : congratulate, suggest archive
- Otherwise: proceed to implementation
Treat
```
context
```
as a required prompt-level input. Read and consider it, and apply relevant project facts, conventions, and constraints while implementing. Treat
```
operationGuidance
```
as optional additive advice. Read and consider every entry, and follow entries that are applicable and compatible with the built-in workflow.
Keep both fields separate from CLI-returned state, missing artifacts, tasks, progress,
```
contextFiles
```
, and the built-in
```
instruction
```
. They are not evidence of task completion, do not replace the built-in instruction, and do not permit bypassing a blocked state. If context conflicts with the built-in instruction, an explicit user choice, or a CLI-controlled value, report the conflict and preserve the controlling value. If guidance is inapplicable or conflicts with those controlling inputs, do not follow it and explain why. These are prompt-level behavior contracts, not enforceable checks.
Read context files
Read every file path listed under
```
contextFiles
```
from the apply instructions output. The files depend on the schema being used:
- spec-driven: proposal, specs, design, tasks
- Other schemas: follow the contextFiles from CLI output
Do not copy
```
context
```
or
```
operationGuidance
```
verbatim into implementation files or planning artifacts unless the user separately asks for that content.
Show current progress

Display:
- Schema being used
- Progress: "N/M tasks complete"
- Remaining tasks overview
- Dynamic instruction from CLI
Implement tasks (loop until done or blocked)

For each pending task:
- Show which task is being worked on
- Make the code changes required
- Keep changes minimal and focused
- Mark task complete in the tasks file:
```
- [ ]
```
  →
```
- [x]
```
- Continue to next task
Pause if:
- Task is unclear → ask for clarification
- Implementation reveals a design issue → suggest updating artifacts
- Error or blocker encountered → report and wait for guidance
- User interrupts
On completion or pause, show status

Display:
- Tasks completed this session
- Overall progress: "N/M tasks complete"
- If all done: suggest archive
- If paused: explain why and wait for guidance

Output During Implementation

## Implementing: <change-name> (schema: <schema-name>)

Working on task 3/7: <task description>
[...implementation happening...]
✓ Task complete

Working on task 4/7: <task description>
[...implementation happening...]
✓ Task complete

Output On Completion

## Implementation Complete

**Change:** <change-name>
**Schema:** <schema-name>
**Progress:** 7/7 tasks complete ✓

### Completed This Session
- [x] Task 1
- [x] Task 2
...

All tasks complete! You can archive this change with `$openspec-archive-change (Codex) or /openspec-archive-change (other agents)`.

Output On Pause (Issue Encountered)

## Implementation Paused

**Change:** <change-name>
**Schema:** <schema-name>
**Progress:** 4/7 tasks complete

### Issue Encountered
<description of the issue>

**Options:**
1. <option 1>
2. <option 2>
3. Other approach

What would you like to do?

Guardrails

Keep going through tasks until done or blocked
Always read context files before starting (from the apply instructions output)
If task is ambiguous, pause and ask before implementing
If implementation reveals issues, pause and suggest artifact updates
Keep code changes minimal and scoped to each task
Update task checkbox immediately after completing each task
Pause on errors, blockers, or unclear requirements - don't guess
Use contextFiles from CLI output, don't assume specific file names
Do not use context or operation guidance as proof that a task is complete
Apply relevant project context; report conflicts with controlling workflow inputs
Consider every guidance entry; explain any inapplicable or conflicting advice
Do not copy runtime context or operation guidance into implementation files or planning artifacts
Preserve CLI-controlled blocked/ready/all-done behavior and completion criteria

Fluid Workflow Integration

This skill supports the "actions on a change" model:

Can be invoked anytime: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
Allows artifact updates: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly

openspec-apply-change

NPX Install

Tags

SKILL.md Content