openspec-apply-change

name	openspec-apply-change
description	Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
allowed-tools	Bash(openspec:*)
license	MIT
compatibility	Requires openspec CLI.
metadata	{"author":"openspec","version":"1.0","generatedBy":"1.11.0"}

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, schemas, 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., /opsx:apply add-auth). 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 and ask the user to select one

   Always announce: "Using change: " and how to override (e.g., /opsx:apply <other>).

2. Check status to understand the schema

   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)

3. Get apply instructions

   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 /opsx:continue (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.

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 `/opsx:archive`.

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
• When a task needs work beyond what the spec describes, surface the added scope and pause - never silently narrow, defer, or simplify away specified behavior
• Only mark a task - [x] when its specified behavior is fully implemented, not when it is partially done or deferred
• 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