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
Revise a change's existing planning artifacts and keep them coherent with one another. Planning artifacts only - it never edits code.
324
324
325
325
**Syntax:**
326
-
```
326
+
327
+
```text
327
328
/opsx:update [change-name]
328
329
```
329
330
330
331
**Arguments:**
332
+
331
333
| Argument | Required | Description |
332
334
|----------|----------|-------------|
333
335
|`change-name`| No | Which change to update (inferred from context if not provided) |
334
336
335
337
**What it does:**
338
+
336
339
- Reads the change's artifacts via `openspec status --change <name> --json`
337
340
- Applies your requested revision, or reviews the artifacts for contradictions if you didn't name one
338
341
- Reconciles the other existing artifacts in any direction (a design edit may ripple back to the proposal)
339
342
- Confirms every edit with you before writing, one artifact at a time
340
343
- Ends by recommending the next step: `/opsx:continue` (artifacts missing), `/opsx:apply` (carry a revised plan into code), or `/opsx:archive` (all done)
341
344
342
345
**Example:**
343
-
```
346
+
347
+
```text
344
348
You: /opsx:update add-dark-mode - we're storing the theme in a cookie now, not localStorage
- It won't create missing artifacts - that's `/opsx:continue`
360
365
- If the change was already implemented, follow up with `/opsx:apply` so the code matches the revised plan
361
366
- If your revision changes the *intent* of the change, start fresh with a new change instead (see [When to Update vs. Start Fresh](opsx.md#when-to-update-vs-start-fresh))
@@ -666,7 +671,7 @@ Different AI tools use slightly different command syntax. Use the format that ma
666
671
| Windsurf |`/opsx-propose`, `/opsx-apply`|
667
672
| Copilot (IDE) |`/opsx-propose`, `/opsx-apply`|
668
673
| Kimi CLI | Skill-based invocations such as `/skill:openspec-propose`, `/skill:openspec-apply-change` (no generated `opsx-*` command files) |
669
-
| Trae |Skill-based invocations such as `/openspec-propose`, `/openspec-apply-change` (no generated `opsx-*` command files)|
674
+
| Trae |`/opsx-propose`, `/opsx-apply`|
670
675
671
676
The intent is the same across tools, but how commands are surfaced can differ by integration.
| Kimi CLI | skill-style, e.g. `/skill:openspec-propose`|
83
-
| Trae |skill-style, e.g. `/openspec-propose`|
83
+
| Trae |`/opsx-propose`, `/opsx-apply`|
84
84
85
85
Most tools use either the colon form (`/opsx:propose`) or the dash form (`/opsx-propose`). A few tools surface OpenSpec as named skills instead of slash commands; for those you invoke the skill by name. The full per-tool list, including exactly which files get written where, lives in [Supported Tools](supported-tools.md).
Copy file name to clipboardExpand all lines: docs/troubleshooting.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -55,7 +55,7 @@ If `/opsx:propose` (or your tool's equivalent) doesn't appear or doesn't do anyt
55
55
56
56
5.**Check you initialized this project.** Skills are written per project. If you cloned a repo or switched folders, run `openspec init` (or `openspec update`) there.
57
57
58
-
6.**Confirm your tool supports command files.** A few tools (Kimi CLI, Trae, ForgeCode, Mistral Vibe) don't get generated `opsx-*` command files; they use skill-based invocations instead. The forms differ per tool: see [Supported Tools](supported-tools.md) and [How Commands Work](how-commands-work.md#slash-command-syntax-by-tool).
58
+
6.**Confirm your tool supports command files.** A few tools (Kimi CLI, ForgeCode, Mistral Vibe) don't get generated `opsx-*` command files; they use skill-based invocations instead. The forms differ per tool: see [Supported Tools](supported-tools.md) and [How Commands Work](how-commands-work.md#slash-command-syntax-by-tool).
Copy file name to clipboardExpand all lines: openspec/changes/add-tool-command-surface-capabilities/proposal.md
+13-9Lines changed: 13 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,13 +2,13 @@
2
2
3
3
OpenSpec currently assumes command delivery maps directly to command adapters. That assumption does not hold for all tools.
4
4
5
-
Trae is a concrete example: it invokes OpenSpec workflows via skill entries (for example `/openspec-new-change`) rather than adapter-generated command files. In this model, skills are the command surface.
5
+
Some tools expose OpenSpec workflows via skill entries rather than adapter-generated command files. Kimi CLI is a concrete example: it invokes skills with forms such as `/skill:openspec-new-change`. In this model, skills are the command surface.
6
6
7
7
Today, this creates a behavior gap:
8
8
9
9
-`delivery=commands` can remove skills
10
10
- tools without adapters skip command generation
11
-
- result: selected tools like Trae can end up with no invocable workflow artifacts
11
+
- result: selected tools like Kimi CLI, ForgeCode, or Mistral Vibe can end up with no invocable workflow artifacts
12
12
13
13
This is more than a prompt UX issue because non-interactive and CI flows bypass interactive guidance. We need a capability-aware model in core generation logic.
14
14
@@ -25,9 +25,13 @@ Add an optional field in tool metadata to describe how a tool exposes commands:
25
25
Field should be optional. Default behavior is inferred from adapter registry presence: tools with a registered adapter resolve to `adapter`; tools with no adapter registration and no explicit annotation resolve to `none`.
26
26
Capability values use kebab-case string tokens for consistency with serialized metadata conventions.
27
27
28
-
Initial explicit override:
28
+
Initial explicit overrides:
29
29
30
-
- Trae -> `skills-invocable`
30
+
- ForgeCode -> `skills-invocable`
31
+
- Kimi CLI -> `skills-invocable`
32
+
- Mistral Vibe -> `skills-invocable`
33
+
34
+
Trae no longer belongs in this override set once its `.trae/commands/opsx-<id>.md` adapter is available; it should resolve to `adapter` like other file-backed command integrations.
31
35
32
36
### 2. Make delivery behavior capability-aware
33
37
@@ -62,12 +66,12 @@ Update summaries to show effective delivery outcomes per tool (for example, when
62
66
63
67
### 4. Update docs and tests
64
68
65
-
- document capability model and Trae behavior under delivery modes
69
+
- document capability model and skills-invocable behavior under delivery modes
66
70
- ensure CLI docs and supported-tools docs reflect effective behavior
67
71
- add test coverage for:
68
-
-`init --tools trae` with `delivery=commands`
69
-
-`update` with Trae configured under `delivery=commands`
70
-
- mixed selections (`claude + trae`) across all delivery modes
72
+
-`init --tools kimi` with `delivery=commands`
73
+
-`update` with Kimi CLI configured under `delivery=commands`
74
+
- mixed selections (`claude + kimi`) across all delivery modes
71
75
- explicit error path for tools with no command surface under `delivery=commands`
72
76
73
77
### 5. Coordinate with install-scope behavior
@@ -94,7 +98,7 @@ Implementation tests should cover mixed-tool matrices to ensure deterministic be
94
98
95
99
## Impact
96
100
97
-
-`src/core/config.ts` - add optional command-surface metadata and Trae override
101
+
-`src/core/config.ts` - add optional command-surface metadata and skills-invocable tool overrides
98
102
-`src/core/command-generation/registry.ts` (or shared helper) - capability inference from adapter presence
0 commit comments