studio/calendars
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

🔧(tools) update OpenSpec skills and commands

Browse Source 
Update all OpenSpec OPSX skills and commands definitions
to their latest versions.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
Nathan Panchout
2026-01-29 11:12:43 +01:00
parent 3fbd87145e
commit 79f352b738
15 changed files with 23 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
.claude/commands/opsx/apply.md
View File

@@ -25,7 +25,7 @@ Implement tasks from an OpenSpec change.
openspec status --change "<name>" --json
```
Parse the JSON to understand:
- `schemaName`: The workflow being used (e.g., "spec-driven", "tdd")
- `schemaName`: The workflow being used (e.g., "spec-driven")
- Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
3. **Get apply instructions**
@@ -50,7 +50,6 @@ Implement tasks from an OpenSpec change.
Read the files listed in `contextFiles` from the apply instructions output.
The files depend on the schema being used:
- **spec-driven**: proposal, specs, design, tasks
- **tdd**: spec, tests, implementation, docs
- Other schemas: follow the contextFiles from CLI output
5. **Show current progress**

10
.claude/commands/opsx/continue.md
View File

@@ -30,7 +30,7 @@ Continue working on a change by creating the next artifact.
openspec status --change "<name>" --json
```
Parse the JSON to understand current state. The response includes:
- `schemaName`: The workflow schema being used (e.g., "spec-driven", "tdd")
- `schemaName`: The workflow schema being used (e.g., "spec-driven")
- `artifacts`: Array of artifacts with their status ("done", "ready", "blocked")
- `isComplete`: Boolean indicating if all artifacts are complete
@@ -96,16 +96,10 @@ Common artifact patterns:
**spec-driven schema** (proposal → specs → design → tasks):
- **proposal.md**: Ask user about the change if not clear. Fill in Why, What Changes, Capabilities, Impact.
- The Capabilities section is critical - each capability listed will need a spec file.
- **specs/*.md**: Create one spec per capability listed in the proposal.
- **specs/<capability>/spec.md**: Create one spec per capability listed in the proposal's Capabilities section (use the capability name, not the change name).
- **design.md**: Document technical decisions, architecture, and implementation approach.
- **tasks.md**: Break down implementation into checkboxed tasks.
**tdd schema** (spec → tests → implementation → docs):
- **spec.md**: Feature specification defining what to build.
- **tests/*.test.ts**: Write tests BEFORE implementation (TDD red phase).
- **src/*.ts**: Implement to make tests pass (TDD green phase).
- **docs/*.md**: Document the implemented feature.
For other schemas, follow the `instruction` field from the CLI output.
**Guardrails**

1
.claude/commands/opsx/new.md
View File

@@ -25,7 +25,6 @@ Start a new change using the experimental artifact-driven approach.
Use the default schema (omit `--schema`) unless the user explicitly requests a different workflow.
**Use a different schema only if the user mentions:**
- "tdd" or "test-driven" → use `--schema tdd`
- A specific schema name → use `--schema <name>`
- "show workflows" or "what workflows" → run `openspec schemas --json` and let them choose

4
.claude/commands/opsx/onboard.md
View File

@@ -412,7 +412,7 @@ The change is implemented! One more step—let's archive it.
```
## Archiving
When a change is complete, we archive it. This moves it from `openspec/changes/` to `openspec/archive/YYYY-MM-DD--<name>/`.
When a change is complete, we archive it. This moves it from `openspec/changes/` to `openspec/changes/archive/YYYY-MM-DD-<name>/`.
Archived changes become your project's decision history—you can always find them later to understand why something was built a certain way.
```
@@ -424,7 +424,7 @@ openspec archive "<name>"
**SHOW:**
```
Archived to: `openspec/archive/YYYY-MM-DD--<name>/`
Archived to: `openspec/changes/archive/YYYY-MM-DD-<name>/`
The change is now part of your project's history. The code is in your codebase, the decision record is preserved.
```

2
.claude/commands/opsx/verify.md
View File

@@ -26,7 +26,7 @@ Verify that an implementation matches the change artifacts (specs, tasks, design
openspec status --change "<name>" --json
```
Parse the JSON to understand:
- `schemaName`: The workflow being used (e.g., "spec-driven", "tdd")
- `schemaName`: The workflow being used (e.g., "spec-driven")
- Which artifacts exist for this change
3. **Get the change directory and load artifacts**

5
.claude/skills/openspec-apply-change/SKILL.md
View File

@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
metadata:
author: openspec
version: "1.0"
generatedBy: "1.0.0"
generatedBy: "1.0.2"
---
Implement tasks from an OpenSpec change.
@@ -29,7 +29,7 @@ Implement tasks from an OpenSpec change.
openspec status --change "<name>" --json
```
Parse the JSON to understand:
- `schemaName`: The workflow being used (e.g., "spec-driven", "tdd")
- `schemaName`: The workflow being used (e.g., "spec-driven")
- Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
3. **Get apply instructions**
@@ -54,7 +54,6 @@ Implement tasks from an OpenSpec change.
Read the files listed in `contextFiles` from the apply instructions output.
The files depend on the schema being used:
- **spec-driven**: proposal, specs, design, tasks
- **tdd**: spec, tests, implementation, docs
- Other schemas: follow the contextFiles from CLI output
5. **Show current progress**

2
.claude/skills/openspec-archive-change/SKILL.md
View File

@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
metadata:
author: openspec
version: "1.0"
generatedBy: "1.0.0"
generatedBy: "1.0.2"
---
Archive a completed change in the experimental workflow.

2
.claude/skills/openspec-bulk-archive-change/SKILL.md
View File

@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
metadata:
author: openspec
version: "1.0"
generatedBy: "1.0.0"
generatedBy: "1.0.2"
---
Archive multiple completed changes in a single operation.

12
.claude/skills/openspec-continue-change/SKILL.md
View File

@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
metadata:
author: openspec
version: "1.0"
generatedBy: "1.0.0"
generatedBy: "1.0.2"
---
Continue working on a change by creating the next artifact.
@@ -34,7 +34,7 @@ Continue working on a change by creating the next artifact.
openspec status --change "<name>" --json
```
Parse the JSON to understand current state. The response includes:
- `schemaName`: The workflow schema being used (e.g., "spec-driven", "tdd")
- `schemaName`: The workflow schema being used (e.g., "spec-driven")
- `artifacts`: Array of artifacts with their status ("done", "ready", "blocked")
- `isComplete`: Boolean indicating if all artifacts are complete
@@ -100,16 +100,10 @@ Common artifact patterns:
**spec-driven schema** (proposal → specs → design → tasks):
- **proposal.md**: Ask user about the change if not clear. Fill in Why, What Changes, Capabilities, Impact.
- The Capabilities section is critical - each capability listed will need a spec file.
- **specs/*.md**: Create one spec per capability listed in the proposal.
- **specs/<capability>/spec.md**: Create one spec per capability listed in the proposal's Capabilities section (use the capability name, not the change name).
- **design.md**: Document technical decisions, architecture, and implementation approach.
- **tasks.md**: Break down implementation into checkboxed tasks.
**tdd schema** (spec → tests → implementation → docs):
- **spec.md**: Feature specification defining what to build.
- **tests/*.test.ts**: Write tests BEFORE implementation (TDD red phase).
- **src/*.ts**: Implement to make tests pass (TDD green phase).
- **docs/*.md**: Document the implemented feature.
For other schemas, follow the `instruction` field from the CLI output.
**Guardrails**

2
.claude/skills/openspec-explore/SKILL.md
View File

@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
metadata:
author: openspec
version: "1.0"
generatedBy: "1.0.0"
generatedBy: "1.0.2"
---
Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.

2
.claude/skills/openspec-ff-change/SKILL.md
View File

@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
metadata:
author: openspec
version: "1.0"
generatedBy: "1.0.0"
generatedBy: "1.0.2"
---
Fast-forward through artifact creation - generate everything needed to start implementation in one go.

5
.claude/skills/openspec-new-change/SKILL.md
View File

@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
metadata:
author: openspec
version: "1.0"
generatedBy: "1.0.0"
generatedBy: "1.0.2"
---
Start a new change using the experimental artifact-driven approach.
@@ -29,7 +29,6 @@ Start a new change using the experimental artifact-driven approach.
Use the default schema (omit `--schema`) unless the user explicitly requests a different workflow.
**Use a different schema only if the user mentions:**
- "tdd" or "test-driven" → use `--schema tdd`
- A specific schema name → use `--schema <name>`
- "show workflows" or "what workflows" → run `openspec schemas --json` and let them choose
@@ -49,7 +48,7 @@ Start a new change using the experimental artifact-driven approach.
This shows which artifacts need to be created and which are ready (dependencies satisfied).
5. **Get instructions for the first artifact**
The first artifact depends on the schema (e.g., `proposal` for spec-driven, `spec` for tdd).
The first artifact depends on the schema (e.g., `proposal` for spec-driven).
Check the status output to find the first artifact with status "ready".
```bash
openspec instructions <first-artifact-id> --change "<name>"

6
.claude/skills/openspec-onboard/SKILL.md
View File

@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
metadata:
author: openspec
version: "1.0"
generatedBy: "1.0.0"
generatedBy: "1.0.2"
---
Guide the user through their first complete OpenSpec workflow cycle. This is a teaching experience—you'll do real work in their codebase while explaining each step.
@@ -416,7 +416,7 @@ The change is implemented! One more step—let's archive it.
```
## Archiving
When a change is complete, we archive it. This moves it from `openspec/changes/` to `openspec/archive/YYYY-MM-DD--<name>/`.
When a change is complete, we archive it. This moves it from `openspec/changes/` to `openspec/changes/archive/YYYY-MM-DD-<name>/`.
Archived changes become your project's decision history—you can always find them later to understand why something was built a certain way.
```
@@ -428,7 +428,7 @@ openspec archive "<name>"
**SHOW:**
```
Archived to: `openspec/archive/YYYY-MM-DD--<name>/`
Archived to: `openspec/changes/archive/YYYY-MM-DD-<name>/`
The change is now part of your project's history. The code is in your codebase, the decision record is preserved.
```

2
.claude/skills/openspec-sync-specs/SKILL.md
View File

@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
metadata:
author: openspec
version: "1.0"
generatedBy: "1.0.0"
generatedBy: "1.0.2"
---
Sync delta specs from a change to main specs.

4
.claude/skills/openspec-verify-change/SKILL.md
View File

@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
metadata:
author: openspec
version: "1.0"
generatedBy: "1.0.0"
generatedBy: "1.0.2"
---
Verify that an implementation matches the change artifacts (specs, tasks, design).
@@ -30,7 +30,7 @@ Verify that an implementation matches the change artifacts (specs, tasks, design
openspec status --change "<name>" --json
```
Parse the JSON to understand:
- `schemaName`: The workflow being used (e.g., "spec-driven", "tdd")
- `schemaName`: The workflow being used (e.g., "spec-driven")
- Which artifacts exist for this change
3. **Get the change directory and load artifacts**