Menu
Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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.
| name | opsx-archive |
| description | Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete. |
| 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.
Archive a completed change in the experimental workflow.
Input: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
Steps
If no change name provided, prompt for selection
Run openspec list --json to get available changes. Use the AskUserQuestion tool to let the user select.
Show only active changes (not already archived). Include the schema used for each change if available.
IMPORTANT: Do NOT guess or auto-select a change. Always let the user choose.
Check artifact completion status
Run openspec status --change "<name>" --json to check artifact completion.
Parse the JSON to understand:
schemaName: The workflow being usedartifacts: List of artifacts with their status (done or other)If any artifacts are not done:
Check task completion status
Read the tasks file (typically tasks.md) to check for incomplete tasks.
Count tasks marked with - [ ] (incomplete) vs - [x] (complete).
If incomplete tasks found:
If no tasks file exists: Proceed without task-related warning.
Assess delta spec sync state
Check for delta specs at openspec/changes/<name>/specs/. If none exist, proceed without sync prompt.
If delta specs exist:
openspec/specs/<capability>/spec.mdPrompt options:
If user chooses sync, execute /opsx:sync logic (use the openspec-sync-specs skill). Proceed to archive regardless of choice.
Perform the archive
Create the archive directory if it doesn't exist:
mkdir -p openspec/changes/archive
Generate target name using current date: YYYY-MM-DD-<change-name>
Check if target already exists:
mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
Display summary
Show archive completion summary including:
Output On Success
## Archive Complete
**Change:** <change-name>
**Schema:** <schema-name>
**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
All artifacts complete. All tasks complete.
Guardrails