opsx-bulk-archive

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 EVERY openspec command 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 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

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 and artifacts list
   • Note which artifacts are done vs other states

   b. Task completion - Read openspec/changes/<name>/tasks.md

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

   c. Delta specs - Check openspec/changes/<name>/specs/ directory

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