$npx -y skills add comol/ai_rules_1c --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 | ## Question-asking discipline (read first) |
| 6 | |
| 7 | Apply phase has a **single consolidated preflight round** at the start, then near-silence during the implementation loop. The user round-trip budget for apply is one batched question round upfront, not one micro-question per task. |
| 8 | |
| 9 | - **Preflight (step 5b below)** — bundle every genuine remaining blocker into one `AskUserQuestion` call. Scope: empty highly-desirable `.dev.env` fields needed by tasks in this session's plan, plus `design.md → ## Open Questions` items whose dependent task is in this session's plan. Nothing else. |
| 10 | - **Implementation loop (step 6 below)** — **no mid-loop questions** except: a new fact surfaces from the live state that conflicts with a locked artifact decision (metadata missing, platform-version mismatch with `CompatibilityMode`, БСП subsystem absent, typical-form structure blocks the planned approach); or the user explicitly re-opens a decision. Routine ambiguity in a task ("what name for this private helper?", "function or procedure?", "what level of logging?") is **never** a legitimate mid-loop pause — it is a propose-phase defect that the propose-phase clarification gate should have caught. Make a reasonable, codebase-consistent choice and record it via `remember` or `memory.md` Captured-during-work. |
| 11 | - **The full rule lives in `content/rules/sdd-integrations.md → Apply-phase clarification discipline`. Load it on any non-trivial apply session.** |
| 12 | |
| 13 | **Steps** |
| 14 | |
| 15 | 1. **Select the change** |
| 16 | |
| 17 | If a name is provided, use it. Otherwise: |
| 18 | - Infer from conversation context if the user mentioned a change |
| 19 | - Auto-select if only one active change exists |
| 20 | - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select |
| 21 | |
| 22 | Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`). |
| 23 | |
| 24 | 2. **Check status to understand the schema** |
| 25 | ```bash |
| 26 | openspec status --change "<name>" --json |
| 27 | ``` |
| 28 | Parse the JSON to understand: |
| 29 | - `schemaName`: The workflow being used (e.g., "spec-driven") |
| 30 | - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others) |
| 31 | |
| 32 | 3. **Get apply instructions** |
| 33 | |
| 34 | ```bash |
| 35 | openspec instructions apply --change "<name>" --json |
| 36 | ``` |
| 37 | |
| 38 | This returns: |
| 39 | - Context file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs) |
| 40 | - Progress (total, complete, remaining) |
| 41 | - Task list with status |
| 42 | - Dynamic instruction based on current state |
| 43 | |
| 44 | **Handle states:** |
| 45 | - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change |
| 46 | - If `state: "all_done"`: congratulate, suggest archive |
| 47 | - Otherwise: proceed to implementation |
| 48 | |
| 49 | 4. **Read context files** |
| 50 | |
| 51 | Read the files listed in `contextFiles` from the apply instructions output. |
| 52 | The files depend on the schema being used: |
| 53 | - **spec-driven**: proposal, specs, design, tasks |
| 54 | - Other schemas: follow the contextFiles from CLI output |
| 55 | |
| 56 | 5. **Show current progress and emit the opening message (preflight round)** |
| 57 | |
| 58 | a. Display: |
| 59 | - Schema being used |
| 60 | - Progress: "N/M tasks complete" |
| 61 | - Remaining tasks overview |
| 62 | - Dynamic instruction from CLI |
| 63 | |
| 64 | b. **Emit the apply-phase opening message** following the template in `content/rules/sdd-integrations.md → Apply-phase opening template`: |
| 65 | |
| 66 | ```text |
| 67 | Using change: <name>. |
| 68 | |
| 69 | ## Locked from artifacts (proceeding without re-asking) |
| 70 | - <decision>: <one-line value> — `<file>:<section>` |
| 71 | - ... |
| 72 | |
| 73 | ## Plan for this session |
| 74 | - <ordered list of task ids that will be executed in this run> |
| 75 | |
| 76 | ## Genuine blockers (preflight — single consolidated round) |
| 77 | - <empty .dev.env field needed by a task in this session's plan> — required by tasks <ids> |
| 78 | - <design.md Open Question whose dependent task is in this session's plan> — CONFUSION block (quote question + list options with consequences + the agent's recommendation + "→ Which one to pick?") |
| 79 | - ... |
| 80 | ``` |
| 81 | |
| 82 | c. **Preflight scope filter** — for each candidate question, include in `## Genuine blockers` only if it passes **all** of: |
| 83 | - **Not** answered in `proposal.md` / `design.md` / delta `specs/` / `tasks.md` (those decisions are locked — quote them in `## Locked from artifacts` instead). |
| 84 | - **Not** an advisory field (`PREFIX`, `COMPANY`, `DEVELOPER`) or a defaulted field (`INFOBASE_KIND`, `EXTENSION_NAME`, `EXPORT_PATH`, `NEW_OBJECTS_IN`, `IBCMD_CONFIG`). |