$npx -y skills add VILA-Lab/FigMirror --skill openspec-apply-changeImplement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
| 1 | Implement tasks from an OpenSpec change. |
| 2 | |
| 3 | **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. |
| 4 | |
| 5 | **Steps** |
| 6 | |
| 7 | 1. **Select the change** |
| 8 | |
| 9 | If a name is provided, use it. Otherwise: |
| 10 | - Infer from conversation context if the user mentioned a change |
| 11 | - Auto-select if only one active change exists |
| 12 | - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select |
| 13 | |
| 14 | Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`). |
| 15 | |
| 16 | 2. **Check status to understand the schema** |
| 17 | ```bash |
| 18 | openspec status --change "<name>" --json |
| 19 | ``` |
| 20 | Parse the JSON to understand: |
| 21 | - `schemaName`: The workflow being used (e.g., "spec-driven") |
| 22 | - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others) |
| 23 | |
| 24 | 3. **Get apply instructions** |
| 25 | |
| 26 | ```bash |
| 27 | openspec instructions apply --change "<name>" --json |
| 28 | ``` |
| 29 | |
| 30 | This returns: |
| 31 | - Context file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs) |
| 32 | - Progress (total, complete, remaining) |
| 33 | - Task list with status |
| 34 | - Dynamic instruction based on current state |
| 35 | |
| 36 | **Handle states:** |
| 37 | - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change |
| 38 | - If `state: "all_done"`: congratulate, suggest archive |
| 39 | - Otherwise: proceed to implementation |
| 40 | |
| 41 | 4. **Read context files** |
| 42 | |
| 43 | Read the files listed in `contextFiles` from the apply instructions output. |
| 44 | The files depend on the schema being used: |
| 45 | - **spec-driven**: proposal, specs, design, tasks |
| 46 | - Other schemas: follow the contextFiles from CLI output |
| 47 | |
| 48 | 5. **Show current progress** |
| 49 | |
| 50 | Display: |
| 51 | - Schema being used |
| 52 | - Progress: "N/M tasks complete" |
| 53 | - Remaining tasks overview |
| 54 | - Dynamic instruction from CLI |
| 55 | |
| 56 | 6. **Implement tasks (loop until done or blocked)** |
| 57 | |
| 58 | For each pending task: |
| 59 | - Show which task is being worked on |
| 60 | - Make the code changes required |
| 61 | - Keep changes minimal and focused |
| 62 | - Mark task complete in the tasks file: `- [ ]` → `- [x]` |
| 63 | - Continue to next task |
| 64 | |
| 65 | **Pause if:** |
| 66 | - Task is unclear → ask for clarification |
| 67 | - Implementation reveals a design issue → suggest updating artifacts |
| 68 | - Error or blocker encountered → report and wait for guidance |
| 69 | - User interrupts |
| 70 | |
| 71 | 7. **On completion or pause, show status** |
| 72 | |
| 73 | Display: |
| 74 | - Tasks completed this session |
| 75 | - Overall progress: "N/M tasks complete" |
| 76 | - If all done: suggest archive |
| 77 | - If paused: explain why and wait for guidance |
| 78 | |
| 79 | **Output During Implementation** |
| 80 | |
| 81 | ``` |
| 82 | ## Implementing: <change-name> (schema: <schema-name>) |
| 83 | |
| 84 | Working on task 3/7: <task description> |
| 85 | [...implementation happening...] |
| 86 | ✓ Task complete |
| 87 | |
| 88 | Working on task 4/7: <task description> |
| 89 | [...implementation happening...] |
| 90 | ✓ Task complete |
| 91 | ``` |
| 92 | |
| 93 | **Output On Completion** |
| 94 | |
| 95 | ``` |
| 96 | ## Implementation Complete |
| 97 | |
| 98 | **Change:** <change-name> |
| 99 | **Schema:** <schema-name> |
| 100 | **Progress:** 7/7 tasks complete ✓ |
| 101 | |
| 102 | ### Completed This Session |
| 103 | - [x] Task 1 |
| 104 | - [x] Task 2 |
| 105 | ... |
| 106 | |
| 107 | All tasks complete! Ready to archive this change. |
| 108 | ``` |
| 109 | |
| 110 | **Output On Pause (Issue Encountered)** |
| 111 | |
| 112 | ``` |
| 113 | ## Implementation Paused |
| 114 | |
| 115 | **Change:** <change-name> |
| 116 | **Schema:** <schema-name> |
| 117 | **Progress:** 4/7 tasks complete |
| 118 | |
| 119 | ### Issue Encountered |
| 120 | <description of the issue> |
| 121 | |
| 122 | **Options:** |
| 123 | 1. <option 1> |
| 124 | 2. <option 2> |
| 125 | 3. Other approach |
| 126 | |
| 127 | What would you like to do? |
| 128 | ``` |
| 129 | |
| 130 | **Guardrails** |
| 131 | - Keep going through tasks until done or blocked |
| 132 | - Always read context files before starting (from the apply instructions output) |
| 133 | - If task is ambiguous, pause and ask before implementing |
| 134 | - If implementation reveals issues, pause and suggest artifact updates |
| 135 | - Keep code changes minimal and scoped to each task |
| 136 | - Update task checkbox immediately after completing each task |
| 137 | - Pause on errors, blockers, or unclear requirements - don't guess |
| 138 | - Use contextFiles from CLI output, don't assume specific file names |
| 139 | |
| 140 | **Fluid Workflow Integration** |
| 141 | |
| 142 | This skill supports the "actions on a change" model: |
| 143 | |
| 144 | - **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions |
| 145 | - **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly |