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