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.

Store selection: If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run openspec store list --json to discover registered store ids, then pass --store <id> on the commands that read or write specs and changes (new change, status, instructions, list, show, validate, archive, doctor, context). Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local openspec/ root.

Input: None required (prompts for selection)

Steps

1. Get active changes

   Run openspec list --json to get all active changes.

   If no active changes exist, inform user and stop.

2. Prompt for change selection

   Use AskUserQuestion tool with multi-select to let user choose changes:

   • 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)

   IMPORTANT: Do NOT auto-select. Always let the user choose.

3. Batch validation - gather status for all selected changes

   For each selected change, collect:

   a. Artifact status - Run openspec status --change "<name>" --json

   • Parse schemaName, artifacts, planningHome, changeRoot, artifactPaths, and actionContext
   • Note which artifacts are done vs other states

   b. Task completion - Read artifactPaths.tasks.existingOutputPaths from status JSON

   • Count - [ ] (incomplete) vs - [x] (complete)
   • If no tasks file exists, note as "No tasks"

   c. Delta specs - Check artifactPaths.specs.existingOutputPaths from status JSON

   • List which capability specs exist
   • For each, extract requirement names (lines matching ### Requirement: <name>)

4. 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.

5. 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:

   • Look for code implementing requirements from each delta spec
   • Check for related files, functions, or tests

   c. Determine resolution:

   • 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

   d. Record resolution for each conflict:

   • Which change's specs to apply
   • In what order (if both)
   • Rationale (what was found in codebase)

6. 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

7. Confirm batch operation

   Use AskUserQuestion tool with a single confirmation:

   • "Archive N changes?" with options based on status
   • Options might include:
     • "Archive all N changes"
     • "Archive only N ready changes (skip incomplete)"
     • "Cancel"

   If there are incomplete changes, make clear they'll be archived with warnings.

   Route on the answer by intent, not by exact label — you wrote these labels, so match what the user picked rather than the wording above:

   • "Cancel" — stop, do not archive. Report that nothing was archived and skip the remaining steps.
   • The archive-everything option — proceed with every selected change
   • The ready-only option — proceed with only the changes the step 6 table marks Ready or Ready*, and record the rest as Skipped in step 8c. If a Ready* change's conflict partner is skipped, re-derive that conflict's resolution using only the changes being archived.
   • Anything else — ask again rather than archiving

8. Execute archive for each confirmed change

   Process changes in the determined order (respecting conflict resolution):

   a. Sync specs if delta specs exist:

   • Use the openspec-sync-specs approach (agent-driven intelligent merge)
   • For conflicts, apply in resolved order
   • Track if sync was done

   b. Perform the archive:

   Target name: use the change name as-is when it already starts with a YYYY-MM-DD- prefix; otherwise prepend the current date as YYYY-MM-DD-<name> (same rule as openspec archive).

   mkdir -p "<planningHome.changesDir>/archive"
   mv "<changeRoot>" "<planningHome.changesDir>/archive/<target-name>"

   c. Track outcome for each change:

   • Success: archived successfully
   • Failed: error during archive (record error)
   • Skipped: user chose not to archive (if applicable)

9. 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/<target-name-1>/
- <change-2> -> archive/<target-name-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/<target-name-1>/

Skipped M changes:
- <change-2> (user chose not to archive incomplete)

Failed K changes:
- <change-3>: Archive directory already exists

Output When No Changes

## No Changes to Archive

No active changes found. Create a new change to get started.

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
• Never archive after the user cancels the confirmation — a cancelled batch archives nothing
• Track and report all outcomes (success/skip/fail)
• Preserve .openspec.yaml when moving to archive
• Archive directory target uses current date: YYYY-MM-DD-; a name that already starts with a YYYY-MM-DD- prefix is used as-is (never stack a second date)
• If archive target exists, fail that change but continue with others