Specification Archiving
Archives completed change proposals and merges their spec deltas into the living specification documentation.
Quick Start
Archiving involves two main operations:
- Move change folder to archive with timestamp
- 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:
Step 1: Verify implementation is complete
Before archiving, confirm all work is done:
Ask the user:
Step 2: Review spec deltas to merge
Understand what will be merged:
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
Example:
Step 4: Merge ADDED requirements into living specs
For each ## ADDED Requirements section:
Process:
- Locate the target living spec file
- Append the new requirements to the end of the file
- Maintain proper markdown formatting
Example:
Source (spec/changes/add-user-auth/specs/authentication/spec-delta.md):
Target (spec/specs/authentication/spec.md):
Step 5: Merge MODIFIED requirements into living specs
For each ## MODIFIED Requirements section:
Process:
- Locate the existing requirement in the living spec
- Replace the ENTIRE requirement block (including all scenarios)
- Use the complete updated text from the delta
Example using sed:
Manual approach (recommended for safety):
Step 6: Merge REMOVED requirements into living specs
For each ## REMOVED Requirements section:
Process:
- Locate the requirement in the living spec
- Delete the entire requirement block
- Add a comment documenting the removal
Example:
Pattern:
Step 7: Move change folder to archive
After all deltas are merged:
Verify move succeeded:
Step 8: Validate living spec structure
After merging, validate the living specs are well-formed:
Manual review:
- Open each modified spec file
- Verify markdown formatting is correct
- Check requirements flow logically
- Ensure no duplicate requirements exist
Merge Logic Reference
ADDED Operation
MODIFIED Operation
REMOVED Operation
RENAMED Operation (uncommon)
Best Practices
Pattern 1: Verify Before Moving
Always verify delta merges before moving to archive:
Pattern 2: Atomic Archiving
Archive entire changes, not individual files:
Good:
Bad:
Pattern 3: Archive Preservation
The archive is a historical record. Never modify archived files:
Pattern 4: Git Commit Strategy
Recommended commit workflow:
Advanced Topics
For complex deltas: See reference/MERGE_LOGIC.md [blocked]
Conflict resolution: If multiple changes modified the same requirement, manual merge is required.
Rollback strategy: To rollback an archive, reverse the process (move from archive back to changes, remove merged content from living specs).
Common Patterns
Pattern 1: Simple Addition
Pattern 2: Behavioral Change
Pattern 3: Deprecation
Pattern 4: Feature with Multiple Requirements
Anti-Patterns to Avoid
Don't:
- Archive incomplete implementations
- Merge deltas before deployment
- Modify archived files
- Skip validation after merging
- Forget to git commit merged specs
Do:
- Verify all tasks complete before archiving
- Merge deltas carefully and completely
- Treat archive as immutable history
- Validate merged specs structure
- Commit merged specs before archiving move
Troubleshooting
Issue: Merge conflict (requirement exists in living spec)
Solution:
Issue: Can't find requirement to modify/remove
Solution:
Issue: Living spec has formatting errors after merge
Solution:
Reference Materials
- MERGE_LOGIC.md [blocked] - Detailed merge operation rules
Token budget: This SKILL.md is approximately 480 lines, under the 500-line recommended limit.

