openspec-apply-change

name	openspec-apply-change
description	Implements the pending tasks of an OpenSpec change against its proposal, specs, and design, looping until done or blocked. Use for "implement this change", "start/continue implementing", "work through the tasks", or "keep going on <change>". Can be invoked any time tasks exist, before or after other artifacts are finished, and interleaved with artifact updates — it is not phase-locked to a single point in the change's lifecycle.
compatibility	Requires the openspec CLI on PATH.

Implement OpenSpec change tasks

Work through a change's task checklist against real code, one task at a time, checking each off only once it is actually done.

Steps

1. Select the change. Use a given name; otherwise infer from context, or auto-select if only one active change exists. If ambiguous, run openspec list --json and let the user choose. Always announce which change is in use.

2. Check status: openspec status --change "<name>" --json — read schemaName and which artifact holds the tasks.

3. Get apply instructions:

   openspec instructions apply --change "<name>" --json
   

   Returns contextFiles (artifact ID -> file paths), task progress, the task list with status, and a dynamic instruction. If state: "blocked" (missing artifacts), suggest /openspec-continue-change. If state: "all_done", congratulate and suggest /openspec-archive-change.

4. Read every file listed under contextFiles before starting — for rhdh-spec-driven that is proposal, specs, design, and tasks.

5. Choose an execution mode for this run, per /rhdh-spec-driven-schema's schema.yaml apply block: direct mode for mechanical, low-risk work; team mode (implementer + independent verifier subagents) for semantically complex, ADR-bound, or broad cross-layer work. Announce the choice and rationale before making changes; do not silently switch mid-run.

6. Work through pending tasks until done or blocked: show which task is active, make minimal focused changes, flip - [ ] to - [x] immediately on completion, continue to the next task. Pause on an unclear task, a design issue surfaced by implementation, an error, or user interruption.

7. Journal as you go, invoking /openspec-journal: mode.chosen once at start, task.start/task.complete per task (or per assigned range in team mode), verifier.result per verdict in team mode, task.blocked on pause, decision for load-bearing calls, handoff as the last line before stopping and the first line on resume. Also keep the default turn bookending (turn.start/turn.end) described there.

8. On completion or pause, show status: tasks completed this session, overall progress (N/M), and either a suggestion to archive or an explanation of the pause with options.

Output

During implementation, show each task starting and completing. On completion, show final progress and readiness to archive. On pause, show the issue, 2-3 options, and "Other approach", then wait.

Guardrails

• Always read context files before starting.
• Keep changes minimal and scoped to each task.
• Pause on errors, blockers, or unclear requirements — never guess.
• Use contextFiles from the CLI output; never assume file names.
• If implementation reveals a design issue, pause and suggest an artifact update rather than silently diverging from the design.

Completion

Complete when every task attempted this session is either checked off with matching code changes, or explicitly reported as paused with the reason and options — never left silently half-done — and the apply-phase journal events for the session were written.