Menu
Start a new OpenSpec change using the experimental artifact workflow. Use when the user wants to create a new feature, fix, or modification with a structured step-by-step approach.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | opsx-new |
| description | Start a new OpenSpec change using the experimental artifact workflow. Use when the user wants to create a new feature, fix, or modification with a structured step-by-step approach. |
| license | MIT |
| compatibility | Requires openspec CLI. |
| metadata | {"author":"openspec","version":"1.0","generatedBy":"1.1.1"} |
OpenSpec project root. The
openspec/directory lives in the REPO, not the workspace this skill is driven from. The repo root is${SPECRAILS_REPO_DIR:-.}(a default-unset env var: when unset it resolves to., i.e. the current directory, so a classic in-repo run is unchanged). Run EVERYopenspeccommand against that root — wrap each invocation as(cd "${SPECRAILS_REPO_DIR:-.}" && openspec …). Treat${SPECRAILS_REPO_DIR:-.}as the OpenSpec project root for any path the CLI prints or you read/write.
Start a new change using the experimental artifact-driven approach.
Input: The user's request should include a change name (kebab-case) OR a description of what they want to build.
Steps
If no clear input provided, ask what they want to build
Use the AskUserQuestion tool (open-ended, no preset options) to ask:
"What change do you want to work on? Describe what you want to build or fix."
From their description, derive a kebab-case name (e.g., "add user authentication" → add-user-auth).
IMPORTANT: Do NOT proceed without understanding what the user wants to build.
Determine the workflow schema
Use the default schema (omit --schema) unless the user explicitly requests a different workflow.
Use a different schema only if the user mentions:
--schema <name>openspec schemas --json and let them chooseOtherwise: Omit --schema to use the default.
Create the change directory
(cd "${SPECRAILS_REPO_DIR:-.}" && openspec new change "<name>")
Add --schema <name> only if the user requested a specific workflow.
This creates a scaffolded change at openspec/changes/<name>/ with the selected schema.
Show the artifact status
(cd "${SPECRAILS_REPO_DIR:-.}" && openspec status --change "<name>")
This shows which artifacts need to be created and which are ready (dependencies satisfied).
Get instructions for the first artifact
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".
(cd "${SPECRAILS_REPO_DIR:-.}" && openspec instructions <first-artifact-id> --change "<name>")
This outputs the template and context for creating the first artifact.
STOP and wait for user direction
Output
After completing the steps, summarize:
Guardrails
Run the implement pipeline over multiple backlog tickets in one session. Per ticket: spawn architect → spawn developer → spawn reviewer (the same three-phase pipeline $implement runs), then move to the next. Sequential by default; parallel only when the user explicitly opts in AND the tickets are independent. Reports an aggregated verdict at the end. Use when the user invokes `$batch-implement #N #M #K` or `$batch-implement --status todo`.
Implement a single backlog ticket through a multi-phase pipeline: architect plans (OpenSpec proposal+design+tasks+specs), sr-developer codes in TDD order, sr-reviewer validates (correctness, tests, security, performance). A profile may add custom-* rails. Reads .specrails/local-tickets.json, closes the ticket in place, reports concisely. Use when the user invokes `$implement #N` or `$implement <free-form>`.
Architect role for the specrails implement pipeline. Reads a backlog ticket, surveys the repo, produces (a) an OpenSpec change package under openspec/changes/<slug>/ and (b) a plan artefact under .specrails/agent-memory/explanations/. Does NOT write production code. Invoked by the implement orchestrator via $sr-architect after a spawn_agent / send_message handoff.
Developer role for the specrails implement pipeline. Reads the architect's design + tasks.md and implements them in TDD order: for each task, write a failing test first, run it to confirm it fails, then write the minimum production code to make it pass, then re-run. Reports the files changed. Does NOT review its own work beyond the per-task test cycle. Invoked by the implement orchestrator via $sr-developer.
Reviewer role for the specrails implement pipeline. Validates the entire implementation: the OpenSpec change package (proposal/design/tasks/specs) is well-formed, the developer's code matches the design's public API and invariants, every tasks.md box is ticked, the tests cover every spec scenario, and the project's full test/build suite passes. Writes a confidence-score.json artefact. Does NOT modify the developer's code. Invoked via $sr-reviewer.
sr:batch-implement — Batch implementation orchestrator. Accepts multiple feature references, computes dependency-aware execution waves, invokes sr:implement per wave.