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
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: openspec-apply-change-183description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks. Use when this capability is needed.4---56Implement tasks from an OpenSpec change.78**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.910**Steps**11121. **Select the change**1314 If a name is provided, use it. Otherwise:15 - Infer from conversation context if the user mentioned a change16 - Auto-select if only one active change exists17 - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select1819 Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).20212. **Check status to understand the schema**22 ```bash23 openspec status --change "<name>" --json24 ```25 Parse the JSON to understand:26 - `schemaName`: The workflow being used (e.g., "spec-driven")27 - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)28293. **Get apply instructions**3031 ```bash32 openspec instructions apply --change "<name>" --json33 ```3435 This returns:36 - Context file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)37 - Progress (total, complete, remaining)38 - Task list with status39 - Dynamic instruction based on current state4041 **Handle states:**42 - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change43 - If `state: "all_done"`: congratulate, suggest archive44 - Otherwise: proceed to implementation45464. **Read context files**4748 Read the files listed in `contextFiles` from the apply instructions output.49 The files depend on the schema being used:50 - **spec-driven**: proposal, specs, design, tasks51 - Other schemas: follow the contextFiles from CLI output52535. **Show current progress**5455 Display:56 - Schema being used57 - Progress: "N/M tasks complete"58 - Remaining tasks overview59 - Dynamic instruction from CLI60616. **Implement tasks (loop until done or blocked)**6263 **CRITICAL**: Before implementing, read `.claude/rules/openspec-tasks-mandatory-steps.mdc` to understand mandatory testing requirements.6465 For each pending task:66 - Show which task is being worked on67 - Make the code changes required68 - Keep changes minimal and focused69 70 **For Manual Testing Tasks (MANDATORY - AGENT MUST EXECUTE)**:71 - **Manual Endpoint Testing with curl**: If the task involves testing endpoints:72 - Start backend server if needed73 - Execute all curl commands yourself (GET, POST, PUT/PATCH, DELETE)74 - Test error cases (validation errors, 404, etc.)75 - Verify all responses76 - Restore database state after CREATE/UPDATE/DELETE operations77 - Document all curl commands and responses78 - **NEVER ask the user to run curl commands** - you must execute them yourself79 80 - **E2E Testing with Playwright MCP**: If the task involves frontend/E2E testing:81 - Start frontend and backend servers if needed82 - Use Playwright MCP tools (`browser_navigate`, `browser_click`, `browser_type`, etc.)83 - Execute complete user workflows84 - Test error scenarios85 - Verify data persistence86 - Restore test environment and database state87 - **NEVER ask the user to run E2E tests** - you must execute them yourself88 89 - **Mark task complete**: Only mark task as complete (`- [ ]` → `- [x]`) AFTER:90 - All code changes are complete91 - All required manual tests have been executed by you (the agent)92 - All test results have been verified93 - Database state has been restored (if applicable)94 - All test outcomes have been documented95 96 - Continue to next task9798 **Pause if:**99 - Task is unclear → ask for clarification100 - Implementation reveals a design issue → suggest updating artifacts101 - Error or blocker encountered → report and wait for guidance102 - User interrupts1031047. **On completion or pause, show status**105106 Display:107 - Tasks completed this session108 - Overall progress: "N/M tasks complete"109 - If all done: suggest archive110 - If paused: explain why and wait for guidance111112**Output During Implementation**113114```115## Implementing: <change-name> (schema: <schema-name>)116117Working on task 3/7: <task description>118[...implementation happening...]119✓ Task complete120121Working on task 4/7: <task description>122[...implementation happening...]123✓ Task complete124```125126**Output On Completion**127128```129## Implementation Complete130131**Change:** <change-name>132**Schema:** <schema-name>133**Progress:** 7/7 tasks complete ✓134135### Completed This Session136- [x] Task 1137- [x] Task 2138...139140All tasks complete! Ready to archive this change.141```142143**Output On Pause (Issue Encountered)**144145```146## Implementation Paused147148**Change:** <change-name>149**Schema:** <schema-name>150**Progress:** 4/7 tasks complete151152### Issue Encountered153<description of the issue>154155**Options:**1561. <option 1>1572. <option 2>1583. Other approach159160What would you like to do?161```162163**Guardrails**164- Keep going through tasks until done or blocked165- Always read context files before starting (from the apply instructions output)166- **CRITICAL**: Read `.claude/rules/openspec-tasks-mandatory-steps.mdc` before implementing to understand mandatory testing requirements167- If task is ambiguous, pause and ask before implementing168- If implementation reveals issues, pause and suggest artifact updates169- Keep code changes minimal and scoped to each task170- **For manual testing tasks**: Execute all tests yourself (curl for endpoints, Playwright MCP for E2E) - NEVER delegate to user171- **Mark tasks complete**: Only mark tasks as complete AFTER executing all required manual tests and verifying results172- Update task checkbox immediately after completing each task AND verifying all tests pass173- Pause on errors, blockers, or unclear requirements - don't guess174- Use contextFiles from CLI output, don't assume specific file names175- **Never ask user to run tests** - you must execute curl commands and E2E tests yourself176177**Fluid Workflow Integration**178179This skill supports the "actions on a change" model:180181- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions182- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly183184---185> Converted and distributed by [TomeVault](https://tomevault.io/claim/lidr-academy) — claim your Tome and manage your conversions.186<!-- tomevault:4.0:skill_md:2026-04-11 -->