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: " and how to override (e.g., /opsx:apply <other>).
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")
- Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
Get apply instructions
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)
CRITICAL: Before implementing, read .claude/rules/openspec-tasks-mandatory-steps.mdc to understand mandatory testing requirements.
For each pending task:
- Show which task is being worked on
- Make the code changes required
- Keep changes minimal and focused
For Manual Testing Tasks (MANDATORY - AGENT MUST EXECUTE):
Manual Endpoint Testing with curl: If the task involves testing endpoints:
- Start backend server if needed
- Execute all curl commands yourself (GET, POST, PUT/PATCH, DELETE)
- Test error cases (validation errors, 404, etc.)
- Verify all responses
- Restore database state after CREATE/UPDATE/DELETE operations
- Document all curl commands and responses
- NEVER ask the user to run curl commands - you must execute them yourself
E2E Testing with Playwright MCP: If the task involves frontend/E2E testing:
- Start frontend and backend servers if needed
- Use Playwright MCP tools (
browser_navigate, browser_click, browser_type, etc.)
- Execute complete user workflows
- Test error scenarios
- Verify data persistence
- Restore test environment and database state
- NEVER ask the user to run E2E tests - you must execute them yourself
Mark task complete: Only mark task as complete (- [ ] → - [x]) AFTER:
- All code changes are complete
- All required manual tests have been executed by you (the agent)
- All test results have been verified
- Database state has been restored (if applicable)
- All test outcomes have been documented
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! Ready to archive this change.
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)
- CRITICAL: Read
.claude/rules/openspec-tasks-mandatory-steps.mdc before implementing to understand mandatory testing requirements
- 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
- For manual testing tasks: Execute all tests yourself (curl for endpoints, Playwright MCP for E2E) - NEVER delegate to user
- Mark tasks complete: Only mark tasks as complete AFTER executing all required manual tests and verifying results
- Update task checkbox immediately after completing each task AND verifying all tests pass
- Pause on errors, blockers, or unclear requirements - don't guess
- Use contextFiles from CLI output, don't assume specific file names
- Never ask user to run tests - you must execute curl commands and E2E tests yourself
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
1---2name: openspec-apply-change-43description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.4license: MIT5---67Implement tasks from an OpenSpec change.89**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.1011**Steps**12131. **Select the change**1415 If a name is provided, use it. Otherwise:16 - Infer from conversation context if the user mentioned a change17 - Auto-select if only one active change exists18 - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select1920 Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).21222. **Check status to understand the schema**23 ```bash24 openspec status --change "<name>" --json25 ```26 Parse the JSON to understand:27 - `schemaName`: The workflow being used (e.g., "spec-driven")28 - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)29303. **Get apply instructions**3132 ```bash33 openspec instructions apply --change "<name>" --json34 ```3536 This returns:37 - Context file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)38 - Progress (total, complete, remaining)39 - Task list with status40 - Dynamic instruction based on current state4142 **Handle states:**43 - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change44 - If `state: "all_done"`: congratulate, suggest archive45 - Otherwise: proceed to implementation46474. **Read context files**4849 Read the files listed in `contextFiles` from the apply instructions output.50 The files depend on the schema being used:51 - **spec-driven**: proposal, specs, design, tasks52 - Other schemas: follow the contextFiles from CLI output53545. **Show current progress**5556 Display:57 - Schema being used58 - Progress: "N/M tasks complete"59 - Remaining tasks overview60 - Dynamic instruction from CLI61626. **Implement tasks (loop until done or blocked)**6364 **CRITICAL**: Before implementing, read `.claude/rules/openspec-tasks-mandatory-steps.mdc` to understand mandatory testing requirements.6566 For each pending task:67 - Show which task is being worked on68 - Make the code changes required69 - Keep changes minimal and focused70 71 **For Manual Testing Tasks (MANDATORY - AGENT MUST EXECUTE)**:72 - **Manual Endpoint Testing with curl**: If the task involves testing endpoints:73 - Start backend server if needed74 - Execute all curl commands yourself (GET, POST, PUT/PATCH, DELETE)75 - Test error cases (validation errors, 404, etc.)76 - Verify all responses77 - Restore database state after CREATE/UPDATE/DELETE operations78 - Document all curl commands and responses79 - **NEVER ask the user to run curl commands** - you must execute them yourself80 81 - **E2E Testing with Playwright MCP**: If the task involves frontend/E2E testing:82 - Start frontend and backend servers if needed83 - Use Playwright MCP tools (`browser_navigate`, `browser_click`, `browser_type`, etc.)84 - Execute complete user workflows85 - Test error scenarios86 - Verify data persistence87 - Restore test environment and database state88 - **NEVER ask the user to run E2E tests** - you must execute them yourself89 90 - **Mark task complete**: Only mark task as complete (`- [ ]` → `- [x]`) AFTER:91 - All code changes are complete92 - All required manual tests have been executed by you (the agent)93 - All test results have been verified94 - Database state has been restored (if applicable)95 - All test outcomes have been documented96 97 - Continue to next task9899 **Pause if:**100 - Task is unclear → ask for clarification101 - Implementation reveals a design issue → suggest updating artifacts102 - Error or blocker encountered → report and wait for guidance103 - User interrupts1041057. **On completion or pause, show status**106107 Display:108 - Tasks completed this session109 - Overall progress: "N/M tasks complete"110 - If all done: suggest archive111 - If paused: explain why and wait for guidance112113**Output During Implementation**114115```116## Implementing: <change-name> (schema: <schema-name>)117118Working on task 3/7: <task description>119[...implementation happening...]120✓ Task complete121122Working on task 4/7: <task description>123[...implementation happening...]124✓ Task complete125```126127**Output On Completion**128129```130## Implementation Complete131132**Change:** <change-name>133**Schema:** <schema-name>134**Progress:** 7/7 tasks complete ✓135136### Completed This Session137- [x] Task 1138- [x] Task 2139...140141All tasks complete! Ready to archive this change.142```143144**Output On Pause (Issue Encountered)**145146```147## Implementation Paused148149**Change:** <change-name>150**Schema:** <schema-name>151**Progress:** 4/7 tasks complete152153### Issue Encountered154<description of the issue>155156**Options:**1571. <option 1>1582. <option 2>1593. Other approach160161What would you like to do?162```163164**Guardrails**165- Keep going through tasks until done or blocked166- Always read context files before starting (from the apply instructions output)167- **CRITICAL**: Read `.claude/rules/openspec-tasks-mandatory-steps.mdc` before implementing to understand mandatory testing requirements168- If task is ambiguous, pause and ask before implementing169- If implementation reveals issues, pause and suggest artifact updates170- Keep code changes minimal and scoped to each task171- **For manual testing tasks**: Execute all tests yourself (curl for endpoints, Playwright MCP for E2E) - NEVER delegate to user172- **Mark tasks complete**: Only mark tasks as complete AFTER executing all required manual tests and verifying results173- Update task checkbox immediately after completing each task AND verifying all tests pass174- Pause on errors, blockers, or unclear requirements - don't guess175- Use contextFiles from CLI output, don't assume specific file names176- **Never ask user to run tests** - you must execute curl commands and E2E tests yourself177178**Fluid Workflow Integration**179180This skill supports the "actions on a change" model:181182- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions183- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly