You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .claude/commands/opsx/apply.md
+33-7Lines changed: 33 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,12 +1,15 @@
1
1
---
2
2
name: "OPSX: Apply"
3
-
description: Implement tasks from an OpenSpec change (Experimental)
4
-
category: Workflow
5
-
tags: [workflow, artifacts, experimental]
3
+
description: "Implement tasks from an OpenSpec change (Experimental)"
4
+
allowed-tools: Bash(openspec:*)
5
+
category: "Workflow"
6
+
tags: ["workflow", "artifacts", "experimental"]
6
7
---
7
8
8
9
Implement tasks from an OpenSpec change.
9
10
11
+
**Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
12
+
10
13
**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
14
12
15
**Steps**
@@ -16,7 +19,7 @@ Implement tasks from an OpenSpec change.
16
19
If a name is provided, use it. Otherwise:
17
20
- Infer from conversation context if the user mentioned a change
18
21
- 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
22
+
- If ambiguous, run `openspec list --json` to get available changes and ask the user to select one
20
23
21
24
Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
22
25
@@ -36,17 +39,32 @@ Implement tasks from an OpenSpec change.
36
39
```
37
40
38
41
This returns:
39
-
-`contextFiles`: artifact ID -> array of concrete file paths (varies by schema)
42
+
-`contextFiles`: artifact ID -> array of concrete file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
40
43
- Progress (total, complete, remaining)
41
44
- Task list with status
42
45
- Dynamic instruction based on current state
46
+
- Optional `context`: current required project instruction input from the selected root
47
+
- Optional `operationGuidance`: current advisory guidance for apply
43
48
44
49
**Handle states:**
45
-
- If `state: "blocked"` (missing artifacts): show message, suggest using `/opsx:continue`
50
+
- If `state: "blocked"` (missing artifacts): show message, suggest using `/opsx:continue` (if it is not installed, run `openspec status --change "<name>" --json` to see the next artifact and `openspec instructions <artifact-id> --change "<name>" --json` for how to create it)
46
51
- If `state: "all_done"`: congratulate, suggest archive
47
52
- Otherwise: proceed to implementation
48
53
49
-
**Workspace guard:** If status JSON reports `actionContext.mode: "workspace-planning"` and `allowedEditRoots` is empty, explain that full workspace apply is not supported in this slice. Treat linked repos and folders as read-only context, ask the user to select an affected area through an explicit implementation workflow, and STOP before editing files.
54
+
Treat `context` as a required prompt-level input. Read and consider it, and
55
+
apply relevant project facts, conventions, and constraints while implementing.
56
+
Treat `operationGuidance` as optional additive advice. Read and consider every
57
+
entry, and follow entries that are applicable and compatible with the built-in
58
+
workflow.
59
+
60
+
Keep both fields separate from CLI-returned state, missing artifacts, tasks,
61
+
progress, `contextFiles`, and the built-in `instruction`. They are not
62
+
evidence of task completion, do not replace the built-in instruction, and do
63
+
not permit bypassing a blocked state. If context conflicts with the built-in
64
+
instruction, an explicit user choice, or a CLI-controlled value, report the
65
+
conflict and preserve the controlling value. If guidance is inapplicable or
66
+
conflicts with those controlling inputs, do not follow it and explain why.
67
+
These are prompt-level behavior contracts, not enforceable checks.
50
68
51
69
4.**Read context files**
52
70
@@ -55,6 +73,9 @@ Implement tasks from an OpenSpec change.
55
73
-**spec-driven**: proposal, specs, design, tasks
56
74
- Other schemas: follow the contextFiles from CLI output
57
75
76
+
Do not copy `context` or `operationGuidance` verbatim into implementation
77
+
files or planning artifacts unless the user separately asks for that content.
78
+
58
79
5.**Show current progress**
59
80
60
81
Display:
@@ -146,6 +167,11 @@ What would you like to do?
146
167
- Update task checkbox immediately after completing each task
147
168
- Pause on errors, blockers, or unclear requirements - don't guess
148
169
- Use contextFiles from CLI output, don't assume specific file names
170
+
- Do not use context or operation guidance as proof that a task is complete
Copy file name to clipboardExpand all lines: .claude/commands/opsx/archive.md
+91-26Lines changed: 91 additions & 26 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,24 +1,59 @@
1
1
---
2
2
name: "OPSX: Archive"
3
-
description: Archive a completed change in the experimental workflow
4
-
category: Workflow
5
-
tags: [workflow, archive, experimental]
3
+
description: "Archive a completed change in the experimental workflow"
4
+
allowed-tools: Bash(openspec:*)
5
+
category: "Workflow"
6
+
tags: ["workflow", "archive", "experimental"]
6
7
---
7
8
8
9
Archive a completed change in the experimental workflow.
9
10
11
+
**Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
12
+
13
+
`<capability-path>` is the spec directory relative to `specs/` (for example, `user-auth` or `identity/user-auth`). Preserve the full path from each delta spec when resolving its main spec.
14
+
10
15
**Input**: Optionally specify a change name after `/opsx:archive` (e.g., `/opsx:archive add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
11
16
12
17
**Steps**
13
18
14
-
1.**If no change name provided, prompt for selection**
19
+
1.**Select the change**
15
20
16
-
Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
21
+
If a name is provided, use it. Otherwise:
22
+
- Infer from conversation context if the user mentioned a change
23
+
- Auto-select if only one active change exists
24
+
- If ambiguous, run `openspec list --json` to get available changes and ask the user to select one
17
25
18
-
Show only active changes (not already archived).
26
+
When prompting, show only active changes (not already archived).
19
27
Include the schema used for each change if available.
20
28
21
-
**IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
29
+
Always announce: "Using change: <name>" and how to override (e.g., `/opsx:archive <other>`).
30
+
31
+
**Load current archive inputs before the existing archive checks:**
32
+
33
+
After resolving the selected change and planning root, run:
Keep the same selected-root flags on this command. This lookup is advisory and
38
+
optional: it only supplies extra prompt inputs, so it must never block archiving.
39
+
If it exits non-zero or returns invalid JSON — for example on an older CLI that
40
+
does not support this command yet — continue the archive workflow with no
41
+
context and no operation guidance. Do not report an error and do not stop.
42
+
43
+
A successful response may omit both optional fields. Treat `context` as a
44
+
required prompt-level input: read and consider it, and apply relevant project
45
+
facts, conventions, and constraints. Treat `operationGuidance` as optional
46
+
additive advice: read and consider every entry, and follow entries that are
47
+
applicable and compatible with the built-in archive workflow.
48
+
49
+
Keep both fields separate from built-in steps, explicit user choices, resolved
50
+
paths, CLI checks, and command contracts. If context conflicts with one of those
51
+
controlling inputs, report the conflict and preserve the controlling value. If
52
+
guidance is inapplicable or conflicts with a controlling input, do not follow it
53
+
and explain why. Do not infer replacement paths, skipped prompts, or flags from
54
+
either field, and do not copy their text verbatim into specs, change artifacts,
55
+
or archive summaries unless the user separately asks for it. These are
56
+
prompt-level behavior contracts, not enforceable checks.
22
57
23
58
2.**Check artifact completion status**
24
59
@@ -27,11 +62,9 @@ Archive a completed change in the experimental workflow.
27
62
Parse the JSON to understand:
28
63
-`schemaName`: The workflow being used
29
64
-`planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context
30
-
-`artifacts`: List of artifacts with their status (`done` or other)
65
+
-`artifacts`: List of artifacts with their status (`done`, `skipped`, or other)
31
66
32
-
If status reports `actionContext.mode: "workspace-planning"`, explain that workspace archive is not supported in this slice and STOP. Do not move workspace changes into repo-local archives or edit linked repos.
33
-
34
-
**If any artifacts are not `done`:**
67
+
**If any artifacts are neither `done` nor `skipped`** (skipped artifacts satisfy the requirement - the change declares skip_specs):
35
68
- Display warning listing incomplete artifacts
36
69
- Prompt user for confirmation to continue
37
70
- Proceed if user confirms
@@ -51,18 +84,44 @@ Archive a completed change in the experimental workflow.
51
84
52
85
4.**Assess delta spec sync state**
53
86
54
-
Use `artifactPaths.specs.existingOutputPaths` from status JSON to check for delta specs. If none exist, proceed without sync prompt.
87
+
Use `artifactPaths.specs.existingOutputPaths` from status JSON as the only
88
+
delta-spec source. If the `specs` entry is missing or
89
+
`existingOutputPaths` is empty, proceed without a sync prompt and do not infer
90
+
delta specs from other artifacts.
55
91
56
92
**If delta specs exist:**
57
-
- Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
93
+
- Compare each delta spec with its corresponding main spec at `<planningHome.root>/openspec/specs/<capability-path>/spec.md` (use the store-aware `planningHome.root` from step 2, not a hardcoded repo path)
58
94
- Determine what changes would be applied (adds, modifications, removals, renames)
59
95
- Show a combined summary before prompting
60
96
61
97
**Prompt options:**
62
98
- If changes needed: "Sync now (recommended)", "Archive without syncing"
63
99
- If already synced: "Archive now", "Sync anyway", "Cancel"
64
100
65
-
If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <includetheanalyzeddeltaspecsummary>"). Proceed to archive regardless of choice.
101
+
Route on the answer:
102
+
- "Cancel" — stop, do not archive
103
+
- "Archive without syncing" or "Archive now" — proceed to archive
104
+
- "Sync now" or "Sync anyway" — sync, then verify (below)
105
+
- Anything else — ask again rather than archiving
106
+
107
+
Before a selected sync writes any main spec, run
108
+
`openspec instructions specs --change "<name>" --json` once with the same
109
+
selected-root flags. Require a zero exit status and valid artifact-instruction
110
+
JSON. If the lookup fails or returns invalid JSON, report the error and stop
111
+
before writing any main spec or moving the change. A valid response with omitted
112
+
`rules` is the no-rules case. Apply returned `rules` only to the content and
113
+
form of main specs produced by this merge; do not use them as archive guidance,
114
+
change CLI behavior, or copy the rule text into any output file.
115
+
116
+
Then run the `/opsx:sync` workflow inline (agent-driven intelligent merge) for change '<name>', passing the delta spec analysis and the fetched specs-rule snapshot from above, and wait for it to finish. The inline sync must reuse that snapshot without fetching `specs` instructions again. Do not delegate it to a background task — step 5 would move `changeRoot` out from under a sync that is still reading it, leaving the change archived and the main specs never updated. If your agent can only run it by delegation, delegate synchronously and wait for the result.
117
+
118
+
Then re-run the comparison from the top of this step against every capability that has a delta spec in `artifactPaths.specs.existingOutputPaths` — not only the ones the sync reports it touched. A successful sync leaves nothing left to apply, so each capability must now read as already synced:
119
+
- ADDED requirements present
120
+
- MODIFIED requirements carrying the scenario and description changes named in the delta, with their other scenarios intact
121
+
- REMOVED requirements gone — and where this sync retired a capability (removed its last requirement, leaving `## Requirements` empty), its main spec deleted rather than left empty; a spec the sync deliberately kept and reported is also a match
122
+
- RENAMED requirements present under the new name and absent under the old one
123
+
124
+
If the sync failed, or any capability does not match, report what differs and stop — do not archive. Nothing has moved and `changeRoot` is intact, so the user can fix the mismatch or re-run the sync and start the archive again.
66
125
67
126
5.**Perform the archive**
68
127
@@ -71,14 +130,14 @@ Archive a completed change in the experimental workflow.
71
130
mkdir -p "<planningHome.changesDir>/archive"
72
131
```
73
132
74
-
Generate target name using current date: `YYYY-MM-DD-<change-name>`
133
+
Generate the target name: use the change name as-is when it already starts with a `YYYY-MM-DD-` prefix; otherwise prepend the current date as `YYYY-MM-DD-<change-name>`. Never stack a second date (same rule as `openspec archive`).
75
134
76
135
**Check if target already exists:**
77
136
- If yes: Fail with error, suggest renaming existing archive or using different date
78
137
- If no: Move `changeRoot` to the archive directory
0 commit comments