Name: openspec-apply-change
Rating: 92
Author: em-jones

Implement tasks from an OpenSpec change.

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 and use the AskUserQuestion tool to let the user select
Always announce: "Using change: <name>" and how to override (e.g., /opsx-apply <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")
- •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:
- •Context 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
Handle states:
- •If state: "blocked" (missing artifacts): show message, suggest using openspec-continue-change
- •If state: "all_done": congratulate, suggest archive
- •Otherwise: proceed to implementation
•
Read context files

Read the files listed in 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
•
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
- •
  TD Integration (if applicable):
  - •Check if the task has a td ID (e.g., td-xxxxx)
  - •If yes, use td start <id> to begin work on that task
  - •Log progress with td log "msg" as you implement
  - •On completion, mark in tasks.md: - [ ] → - [x]
  - •td is the source of truth; openspec tasks.md reflects td state
- •If no td integration, just update the tasks file locally: - [ ] → - [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, optionally sync td state back to openspec (if applicable)

If the change has an associated epic ID in the proposal frontmatter:
- •After completing implementation, td is the source of truth
- •Optional: Run the openspec-td-sync skill to update tasks.md to reflect current td state
- •This ensures the openspec artifact matches actual work state in td
- •Recommended before archiving to have a clean state snapshot
•
Show final status

Display:
- •Tasks completed this session
- •Overall progress: "N/M tasks complete"
- •If all done: suggest archive with /opsx-archive
- •If paused: explain why and wait for guidance
- •TD Note (if applicable): Remind that td is source of truth; tasks.md should stay in sync

Output During Implementation

code

## 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

code

## 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! Ready to archive this change.

Output On Pause (Issue Encountered)

code

## 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

TD Integration (v1 Schema)

When using the spec-td schema (v1):

•
Source of Truth: td CLI is the definitive task tracker
•
Openspec Filesystem: tasks.md is a human-readable snapshot of td state
•
Workflow:
1. •Tasks in tasks.md should reference td IDs (e.g., td-xxxxx: Task title)
2. •When implementing, use td start <id> to begin work on the actual task in td
3. •Log progress with td log, make decisions with td log --decision, etc.
4. •After completion, sync back to openspec with openspec-td-sync skill
5. •Before archiving, ensure tasks.md matches current td state
•
Benefits:
- •Reduces token consumption by using td as source of truth
- •Agents work with familiar td CLI
- •Openspec filesystem remains human-readable for auditing
- •Handoffs between sessions include both td and openspec context

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
•Works with td: Task tracking happens in td; openspec artifacts stay synchronized