
Openspec Archiving
Finalize an OpenSpec change after deployment by archiving the change folder and merging ADDED, MODIFIED, and REMOVED deltas into living specs.
Overview
openspec-archiving is an agent skill most often used in Ship (also Build docs, Operate iterate) that archives completed OpenSpec changes and merges specification deltas into living documentation after deployment.
Install
npx skills add https://github.com/forztf/open-skilled-sdd --skill openspec-archivingWhat is this skill?
- Eight-step archive checklist from implementation verification through living-spec validation
- Merges spec deltas with explicit ADDED, MODIFIED, and REMOVED operations into living specs
- Moves completed change folders into a timestamped archive directory
- Hard gate: requires IMPLEMENTED marker and complete tasks before archive signifies deployment done
- Bash-friendly verification hooks (e.g. test -f spec/changes/{change-id}/IMPLEMENTED)
- 8-step archive progress checklist
- 3 delta merge operations: ADDED, MODIFIED, REMOVED
Adoption & trust: 671 installs on skills.sh; 9 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You finished implementing a spec change but the living specs still lag behind and the active change folder clutters your repo.
Who is it for?
Solo builders running OpenSpec or SDD workflows who need a repeatable close-out ritual once IMPLEMENTED is true and tasks are done.
Skip if: Mid-flight feature work, draft proposals, or repos that do not use OpenSpec-style spec/changes and delta files.
When should I use this skill?
Changes are deployed, ready to archive, or specs need updating after implementation; triggers include openspec archive, archive change, merge specs, complete proposal, update documentation, finalize spec, mark as done.
What do I get? / Deliverables
Completed changes land in a timestamped archive and ADDED, MODIFIED, and REMOVED requirements are merged into authoritative specs so agents and humans share one source of truth.
- Timestamped archive of the change folder
- Updated living specification with merged deltas
- Validated living spec structure post-merge
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Archiving is the canonical last step of the spec-driven change lifecycle, immediately after deploy when launch-ready work must be reflected in durable documentation. Launch subphase covers shipping artifacts and closing the loop on what actually went out—merging deltas and moving changes to a timestamped archive matches that closure.
Where it fits
After coding finishes, merge MODIFIED requirements so API docs in spec/ match the branch you are about to tag.
Right after deploy, archive the change ID and validate living spec structure before announcing the release.
During housekeeping sprints, archive stale completed changes so agents only see active proposals.
How it compares
Use as the structured close-out step instead of manually editing specs and dragging folders without delta semantics.
Common Questions / FAQ
Who is openspec-archiving for?
Indie and solo developers who manage product specs as code alongside AI agents and want deployed work reflected in living documentation automatically.
When should I use openspec-archiving?
At Ship launch when a change is deployed; also in Build docs when consolidating spec truth, and in Operate iterate when retiring completed change IDs—especially on triggers like openspec archive, merge specs, or complete proposal.
Is openspec-archiving safe to install?
Review the Security Audits panel on this Prism page and treat filesystem and git mutations as sensitive; the skill moves folders and edits spec files.
SKILL.md
READMESKILL.md - Openspec Archiving
# Specification Archiving Archives completed change proposals and merges their spec deltas into the living specification documentation. ## Quick Start Archiving involves two main operations: 1. **Move change folder** to archive with timestamp 2. **Merge spec deltas** into living specs (ADDED/MODIFIED/REMOVED operations) **Critical rule**: Verify all tasks are complete before archiving. Archiving signifies deployment and completion. ## Workflow Copy this checklist and track progress: ``` Archive Progress: - [ ] Step 1: Verify implementation is complete - [ ] Step 2: Review spec deltas to merge - [ ] Step 3: Create timestamped archive directory - [ ] Step 4: Merge ADDED requirements into living specs - [ ] Step 5: Merge MODIFIED requirements into living specs - [ ] Step 6: Merge REMOVED requirements into living specs - [ ] Step 7: Move change folder to archive - [ ] Step 8: Validate living spec structure ``` ### Step 1: Verify implementation is complete Before archiving, confirm all work is done: ```bash # Check for IMPLEMENTED marker test -f spec/changes/{change-id}/IMPLEMENTED && echo "✓ Implemented" || echo "✗ Not implemented" # Review tasks cat spec/changes/{change-id}/tasks.md # Check git status for uncommitted work git status ``` **Ask the user**: ```markdown Are all tasks complete and tested? Has this change been deployed to production? Should I proceed with archiving? ``` ### Step 2: Review spec deltas to merge Understand what will be merged: ```bash # List all spec delta files find spec/changes/{change-id}/specs -name "*.md" -type f # Read each delta for file in spec/changes/{change-id}/specs/**/*.md; do echo "=== $file ===" cat "$file" done ``` **Identify**: - Which capabilities are affected - How many requirements are ADDED/MODIFIED/REMOVED - Where in living specs these changes belong ### Step 3: Create timestamped archive directory ```bash # Create archive with today's date TIMESTAMP=$(date +%Y-%m-%d) mkdir -p spec/archive/${TIMESTAMP}-{change-id} ``` **Example**: ```bash # For change "add-user-auth" archived on Oct 26, 2025 mkdir -p spec/archive/2025-10-26-add-user-auth ``` ### Step 4: Merge ADDED requirements into living specs For each `## ADDED Requirements` section: **Process**: 1. Locate the target living spec file 2. Append the new requirements to the end of the file 3. Maintain proper markdown formatting **Example**: **Source** (`spec/changes/add-user-auth/specs/authentication/spec-delta.md`): ```markdown ## ADDED Requirements ### Requirement: User Login WHEN a user submits valid credentials, the system SHALL authenticate the user and create a session. #### Scenario: Successful Login GIVEN valid credentials WHEN user submits login form THEN system creates session ``` **Target** (`spec/specs/authentication/spec.md`): ```bash # Append to living spec cat >> spec/specs/authentication/spec.md << 'EOF' ### Requirement: User Login WHEN a user submits valid credentials, the system SHALL authenticate the user and create a session. #### Scenario: Successful Login GIVEN valid credentials WHEN user submits login form THEN system creates session EOF ``` ### Step 5: Merge MODIFIED requirements into living specs For each `## MODIFIED Requirements` section: **Process**: 1. Locate the existing requirement in the living spec 2. Replace the ENTIRE requirement block (including all scenarios) 3. Use the complete updated text from the delta **Example using sed**: ```bash # Find and replace requirement block # This is conceptual - actual implementation depends on structure # First, identify the line range of the old requ