pavilio-archive-plan

Archives shipped change specs by folding delta requirements into living OpenSpec specs.

Updated Apr 19, 2026
One-click install
npx skills add https://github.com/gmotyl/pavilio --skill pavilio-archive-plan-gmotyl
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: pavilio-archive-plan
Source: https://github.com/gmotyl/pavilio/tree/main/skills/pavilio-archive-plan
Command: npx skills add https://github.com/gmotyl/pavilio --skill pavilio-archive-plan-gmotyl

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? After a change's PR merges, its delta specs sit unarchived and the project's living specs drift out of sync with shipped behavior. This Skill closes that loop by merging delta requirements into the living specs and moving the change directory into the archive tree. ## Core Features & Use Cases - Delta spec folding: Reads ADDED, MODIFIED, and REMOVED requirement sections from a change's delta specs and merges them into behavior-level living specs under openspec/specs/. - Knowledge distillation: Crystallizes durable terms into CONTEXT.md and offers ADRs for hard-to-reverse decisions with real trade-offs. - Git-history-preserving archive: Moves the change directory into openspec/changes/archive/ with a merge-date prefix using git mv, then commits everything together. - Use Case: After PR #42 for the checkout-tax change merges, run the archive command to fold its requirements into the living checkout-tax spec, record a gotcha in CONTEXT.md, and archive the change directory as 2026-05-01-checkout-tax. ## Quick Start Invoke /pavilio-archive-plan with the project and change-id to archive a merged change and fold its delta specs into the living specs.

Frequently Asked Questions about pavilio-archive-plan

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I archive a shipped OpenSpec change after its PR merges?▼

Invoke /pavilio-archive-plan with the project and change-id. The skill verifies the PR merged, folds the delta specs into living specs under openspec/specs/, moves the change dir into openspec/changes/archive/ with a date prefix, and commits the result.

How are ADDED, MODIFIED, and REMOVED delta requirements folded into living specs?▼

ADDED requirements are appended to the capability spec, MODIFIED requirements are located by exact name then keyword search and rewritten, and REMOVED requirements are deleted. Living specs stay behavior-level with requirement statements and WHEN/THEN scenarios.

Can I archive a change whose pull request is still open?▼

No. The skill stops if the change has not shipped, reporting that the PR is still open. Archiving is only for merged changes, since the fold step records what the project behavior actually became.

What happens if the spec fold or validation fails during archiving?▼

The operation is all-or-nothing: a fold or validation failure leaves both the active change directory and the living specs unchanged. The skill reports the error and stops without moving the change dir.

When should change content go to CONTEXT.md instead of a living spec?▼

One-off actions with no forward-looking behavior contract, such as a completed rename, copy tweak, or migration, become CONTEXT.md gotchas. Anything with a right/wrong behavior to check against becomes a requirement with scenarios in a living spec.