Archive multiple completed changes in a single operation.
This skill allows you to batch-archive changes, handling spec conflicts intelligently by checking the codebase to determine what's actually implemented.
Input: None required (prompts for selection)
Steps
- Get active changes Run
openspec list --jsonto get all active changes. If no active changes exist, inform user and stop. - Prompt for change selection Use AskUserQuestion tool with multi-select to let user choose changes: IMPORTANT: Do NOT auto-select. Always let the user choose.
- Show each change with its schema - Include an option for "All changes" - Allow any number of selections (1+ works, 2+ is the typical use case)
- Batch validation - gather status for all selected changes For each selected change, collect: a. Artifact status - Run
openspec status --change "<name>" --jsonb. Task completion - Readopenspec/changes/<name>/tasks.mdc. Delta specs - Checkopenspec/changes/<name>/specs/directory
- Parse schemaName and artifacts list - Note which artifacts are done vs other states - Count - [] (incomplete) vs - [x] (complete) - If no tasks file exists, note as "No tasks" - List which capability specs exist - For each, extract requirement names (lines matching ### Requirement: <name>)
- Detect spec conflicts Build a map of
capability -> [changes that touch it]:auth -> [change-a, change-b] <- CONFLICT (2+ changes) api -> [change-c] <- OK (only 1 change)A conflict exists when 2+ selected changes have delta specs for the same capability. - Resolve conflicts agentically For each conflict, investigate the codebase: a. Read the delta specs from each conflicting change to understand what each claims to add/modify b. Search the codebase for implementation evidence: c. Determine resolution: d. Record resolution for each conflict:
- Look for code implementing requirements from each delta spec - Check for related files, functions, or tests - If only one change is actually implemented -> sync that one's specs - If both implemented -> apply in chronological order (older first, newer overwrites) - If neither implemented -> skip spec sync, warn user - Which change's specs to apply - In what order (if both) - Rationale (what was found in codebase)
- Show consolidated status table Display a table summarizing all changes:
| Change | Artifacts | Tasks | Specs | Conflicts | Status | |---------------------|-----------|-------|---------|-----------|--------| | schema-management | Done | 5/5 | 2 delta | None | Ready | | project-config | Done | 3/3 | 1 delta | None | Ready | | add-oauth | Done | 4/4 | 1 delta | auth (!) | Ready* | | add-verify-skill | 1 left | 2/5 | None | None | Warn |For conflicts, show the resolution:* Conflict resolution: - auth spec: Will apply add-oauth then add-jwt (both implemented, chronological order)For incomplete changes, show warnings:Warnings: - add-verify-skill: 1 incomplete artifact, 3 incomplete tasks - Confirm batch operation Use AskUserQuestion tool with a single confirmation: If there are incomplete changes, make clear they'll be archived with warnings.
- "Archive N changes?" with options based on status - Options might include: - "Archive all N changes" - "Archive only N ready changes (skip incomplete)" - "Cancel"
- Execute archive for each confirmed change Process changes in the determined order (respecting conflict resolution): a. Sync specs if delta specs exist: b. Perform the archive:
mkdir -p openspec/changes/archive mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>c. Track outcome for each change:
- Use the openspec-sync-specs approach (agent-driven intelligent merge) - For conflicts, apply in resolved order - Track if sync was done - Success: archived successfully - Failed: error during archive (record error) - Skipped: user chose not to archive (if applicable)
- Display summary Show final results:
## Bulk Archive Complete Archived 3 changes: - schema-management-cli -> archive/2026-01-19-schema-management-cli/ - project-config -> archive/2026-01-19-project-config/ - add-oauth -> archive/2026-01-19-add-oauth/ Skipped 1 change: - add-verify-skill (user chose not to archive incomplete) Spec sync summary: - 4 delta specs synced to main specs - 1 conflict resolved (auth: applied both in chronological order)If any failures:Failed 1 change: - some-change: Archive directory already exists
Conflict Resolution Examples
Example 1: Only one implemented
Conflict: specs/auth/spec.md touched by [add-oauth, add-jwt]
Checking add-oauth:
- Delta adds "OAuth Provider Integration" requirement
- Searching codebase... found src/auth/oauth.ts implementing OAuth flow
Checking add-jwt:
- Delta adds "JWT Token Handling" requirement
- Searching codebase... no JWT implementation found
Resolution: Only add-oauth is implemented. Will sync add-oauth specs only.Example 2: Both implemented
Conflict: specs/api/spec.md touched by [add-rest-api, add-graphql]
Checking add-rest-api (created 2026-01-10):
- Delta adds "REST Endpoints" requirement
- Searching codebase... found src/api/rest.ts
Checking add-graphql (created 2026-01-15):
- Delta adds "GraphQL Schema" requirement
- Searching codebase... found src/api/graphql.ts
Resolution: Both implemented. Will apply add-rest-api specs first,
then add-graphql specs (chronological order, newer takes precedence).Output On Success
## Bulk Archive Complete
Archived N changes:
- <change-1> -> archive/YYYY-MM-DD-<change-1>/
- <change-2> -> archive/YYYY-MM-DD-<change-2>/
Spec sync summary:
- N delta specs synced to main specs
- No conflicts (or: M conflicts resolved)Output On Partial Success
## Bulk Archive Complete (partial)
Archived N changes:
- <change-1> -> archive/YYYY-MM-DD-<change-1>/
Skipped M changes:
- <change-2> (user chose not to archive incomplete)
Failed K changes:
- <change-3>: Archive directory already existsOutput When No Changes
## No Changes to Archive
No active changes found. Use `/opsx:new` to create a new change.Guardrails
- Allow any number of changes (1+ is fine, 2+ is the typical use case)
- Always prompt for selection, never auto-select
- Detect spec conflicts early and resolve by checking codebase
- When both changes are implemented, apply specs in chronological order
- Skip spec sync only when implementation is missing (warn user)
- Show clear per-change status before confirming
- Use single confirmation for entire batch
- Track and report all outcomes (success/skip/fail)
- Preserve.openspec.yaml when moving to archive
- Archive directory target uses current date: YYYY-MM-DD-
- If archive target exists, fail that change but continue with others