Apply

• If the user specified a change name (e.g., /openspec:apply add-dark-mode), use that
• Otherwise, check for changes in openspec/changes/ that have a tasks.md with unchecked items
• If multiple active changes exist, list them and ask which to work on
• If no change has tasks, suggest running /openspec:propose first

Step 2: Load Change Context

Read all available artifacts for the active change from openspec/changes/<change-name>/:

• Required: tasks.md — the implementation checklist
• If exists: proposal.md — for understanding the why
• If exists: specs/ — for requirements and expected behavior
• If exists: design.md — for technical approach and architecture decisions

Also read existing project code to understand:

• Current file structure and conventions
• Related existing code that needs to be modified

Report what was loaded:

Change: [change-name]
Tasks: [N] total, [N] remaining, [N] completed
Artifacts: proposal.md ✓, specs/ ✓, design.md [✓/–], tasks.md ✓

Step 3: Execute Tasks

Work through unchecked tasks in order:

For each task:

1. Read the task description carefully
2. Understand what needs to be done (consult specs/design if needed)
3. Implement the code change
4. Immediately mark the task [x] in tasks.md after completing it
5. Report what was done

Handling updates to artifacts: During implementation, you may discover that:

• The specs need clarification → update specs/<capability>/spec.md directly
• The design needs adjustment → update design.md directly
• New tasks are needed → add them to tasks.md

This is expected and intentional — artifacts are living documents, not frozen plans.

Progress format after each task:

[x] 2.1 Implement theme context provider (src/contexts/ThemeContext.tsx)
    Progress: 4/12 tasks complete (33%)

If a task is blocked:

⚠️ Blocked: 2.3 Wire up localStorage persistence
   Reason: [what's preventing completion]
   Options:
     1. [Suggested resolution]
     2. Skip and come back: add a note to tasks.md and mark as skipped
     3. Update the task description and try again

Ask the user how to proceed before continuing.

Step 4: Stop at Blockers or Checkpoints

Stop and check in with the user when:

• A task fails and the path forward is unclear
• Implementation reveals a significant discrepancy from the design
• A task requires a decision that affects multiple future tasks
• All tasks in a logical group are complete (natural checkpoint)

At each checkpoint:

Checkpoint: [What was completed]

  ✓ [task group completed]

  Remaining: [N] tasks
    [list next few tasks]

Continue? (yes/no) Or describe any changes needed.

Step 5: Completion

When all tasks are marked complete:

Change Applied: [change-name]

  All [N] tasks completed ✓

  Changed files:
    [list of files created or modified]

  Next step: Run /openspec:archive to archive this change
  Or run /openspec:verify to validate the implementation matches the artifacts

Behavior Rules

• Mark tasks immediately: Update tasks.md checkbox to [x] as soon as a task is done — don't batch updates
• Update artifacts freely: If you discover something that needs changing in specs or design, update the artifact and continue
• Don't over-plan: If a task is clear enough to do, do it. Don't ask for clarification on straightforward tasks.
• Be honest about blockers: Report when something is blocking you rather than guessing or making incorrect assumptions
• Respect the existing codebase: Follow existing patterns, conventions, and code style
• One task at a time: Complete each task fully before moving to the next