v1.0 to v1.0

1 added, 1 removed. Audit A to A.

---

name: openspec-apply-change

description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks. Also use when the user says "openspec apply", "opsx apply", or "openspec implement".

allowed-tools: Bash(openspec:*), Bash(bun:*)

license: MIT

compatibility: Requires openspec CLI.

metadata:

author: openspec

version: "1.0"

---

## This repository (Asymmetric-al/core)

These repo-owned sections sit above the official OpenSpec skill. Reconcile this

overlay after upstream refreshes before running `bun run skills:sync`.

Use the locally pinned CLI only: `bun run openspec -- <command>`. Do not invoke

`@latest`. Core does not use Stores. Pass an explicit change ID before any

mutating OpenSpec operation. Follow `AGENTS.md` and `docs/ai/rules/openspec.md`.

Do not bypass TDD, exact `base-maia`, data-access boundaries, security, or

repository checks. Do not archive unmerged or incomplete work. Do not run

`openspec update` against the live customized repository. Do not treat product

runtime Eve as a coding agent.

Allowed-tools metadata includes `Bash(bun:*)` so the local wrapper can run.

### Triggers

- The matching OpenSpec workflow is requested: Explore, Propose, Update, Apply,

Verify, Sync, or Archive.

- Numbered commands `/1-start-project` through `/4-close-project` wrap these

workflows.

### Workflow

1. Read `openspec/config.yaml`, `openspec/project.md`, and the relevant specs

or active change.

2. Invoke `bun run openspec --` with the explicit change ID for mutating work.

3. Keep Core TDD, UI, data-boundary, and Guardian rules in force.

4. Leave the change active until implementation has merged.

### Checklist

- [ ] Local pinned CLI used via `bun run openspec --`

- [ ] Explicit change ID used for mutating operations

- [ ] Stores were not introduced

- [ ] Incomplete or unmerged work was not archived

- [ ] `openspec update` was not run against the live repo

- [ ] Product Eve was not treated as a coding agent

Implement tasks from an OpenSpec change.

**Project check:** Before writing, run `bun run openspec -- list --json` and confirm the root is the Core checkout containing its local `openspec/` tree. A missing root, Store declaration, or external root is a configuration error: stop before writing and report it. Do not initialize a root or select an external Store.

**Input**: Optionally specify a change name (e.g., `/openspec-apply-change add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.

**Steps**

1. **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 ask the user to select one

Always announce: "Using change: <name>" and how to override (e.g., `/openspec-apply-change <other>`).

2. **Check status to understand the schema**

```bash

openspec status --change "<name>" --json

```

Parse the JSON to understand:

- `schemaName`: The workflow being used (e.g., "spec-driven")

- `planningHome`, `changeRoot`, and `actionContext`: planning scope and edit constraints

- Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)

3. **Get apply instructions**

```bash

openspec instructions apply --change "<name>" --json

```

This returns:

- `contextFiles`: artifact ID -> array of concrete file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)

- Progress (total, complete, remaining)

- Task list with status, source path, and source line

- Dynamic instruction based on current state

- Optional `context`: current required project instruction input from the selected root

- Optional `operationGuidance`: current advisory guidance for apply

- `missingArtifacts` (when present): required artifact ids with no output

**Handle states:**

- If `state: "blocked"`: show the message and pause implementation.

- - If `missingArtifacts` is non-empty: suggest using `/openspec-continue-change` to create them.

+ - If `missingArtifacts` is non-empty: verify whether `/openspec-continue-change` is installed before suggesting it. Core does not install it; if unavailable, use `bun run openspec -- status --change "<name>" --json` to identify the next artifact and `bun run openspec -- instructions "<artifact-id>" --change "<name>" --json` for its template and instructions. Creating the missing artifact is a separate authorized step; keep implementation paused.

- Otherwise, follow the CLI instruction to create or repair the schema-configured tracking file from existing planning artifacts. Do not assume another artifact is ready or start implementation while blocked.

- If `state: "all_done"`: report that all tracked tasks are complete and suggest review or verification as appropriate before archiving

- Otherwise: proceed to implementation

Treat `context` as a required prompt-level input. Read and consider it, and

apply relevant project facts, conventions, and constraints while implementing.

Treat `operationGuidance` as optional additive advice. Read and consider every

entry, and follow entries that are applicable and compatible with the built-in

workflow.

Keep both fields separate from CLI-returned state, missing artifacts, tasks,

progress, `contextFiles`, and the built-in `instruction`. They are not

evidence of task completion, do not replace the built-in instruction, and do

not permit bypassing a blocked state. If context conflicts with the built-in

instruction, an explicit user choice, or a CLI-controlled value, report the

conflict and preserve the controlling value. If guidance is inapplicable or

conflicts with those controlling inputs, do not follow it and explain why.

These are prompt-level behavior contracts, not enforceable checks.

4. **Read context files**

Read every file path listed under `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

Do not copy `context` or `operationGuidance` verbatim into implementation

files or planning artifacts unless the user separately asks for that content.

5. **Show current progress**

Display:

- Schema being used

- Progress: "N/M tasks complete"

- Remaining tasks overview

- Dynamic instruction from CLI

6. **Implement tasks (loop until done or blocked)**

For each pending task:

- Show which task is being worked on

- Make the code changes required

- Keep changes minimal and focused

- Before editing, confirm the checkbox at the returned `sourcePath` and `line` still matches the task description; if it does not, rerun the apply instructions and use the refreshed location

- Mark the task complete at its returned `sourcePath` and `line`: `- [ ]` → `- [x]`

- Rerun the apply instructions and confirm that task is now done and progress changed

- Continue to next task

**Pause if:**

- Task is unclear → ask for clarification

- Implementation reveals a design issue → suggest updating artifacts

- A task needs work beyond what the spec and tasks describe, or you are tempted to drop, narrow, defer, or accept exceptions to specified behavior to make it fit → surface the added scope and ask; do not absorb it silently

- Error or blocker encountered → report and wait for guidance

- User interrupts

7. **On completion or pause, show status**

Display:

- Tasks completed this session

- Overall progress: "N/M tasks complete"

- If all done: report that tracked tasks are complete and suggest review or verification as appropriate before archiving

- 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 tracked tasks are complete. Review or verify the change as appropriate

before archiving. You can archive this change with `/openspec-archive-change`.

```

**Output On Pause (Issue Encountered)**

```

## Implementation Paused

**Change:** <change-name>

**Schema:** <schema-name>

**Progress:** 4/7 tasks complete

### Issue Encountered

**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)

- 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

- Update task checkbox immediately after completing each task

- Pause on errors, blockers, or unclear requirements - don't guess

- When a task needs work beyond what the spec describes, surface the added scope and pause - never silently narrow, defer, or simplify away specified behavior

- Only mark a task `- [x]` when its specified behavior is fully implemented, not when it is partially done or deferred

- Use contextFiles from CLI output, don't assume specific file names

- Use each task's sourcePath and line to update its exact checkbox

- Do not use context or operation guidance as proof that a task is complete

- Apply relevant project context; report conflicts with controlling workflow inputs

- Consider every guidance entry; explain any inapplicable or conflicting advice

- Do not copy runtime context or operation guidance into implementation files or planning artifacts

- Preserve CLI-controlled blocked/ready/all-done behavior and completion criteria

**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