openspec-change-closure_skill

Overview

This skill archives completed Level 0-1 OpenSpec changes by packaging outcomes, evidence, and canonical spec updates into the project archive. It ensures closure criteria are met, records final metrics and learnings, and synchronizes approved spec deltas into the canonical specs directory. The skill produces an archive summary and updates project artifacts to reflect completion.

How this skill works

The skill verifies closure conditions against a CHECKLIST and gathers inputs: original proposal, implementation logs, and validation evidence. It generates an archive.md summary using a template, records approvals, metrics, and deviations, and runs a script to merge validated spec deltas into openspec/specs/. If any required evidence or approvals are missing, it halts and requests remediation.

When to use it

• A Level 0-1 OpenSpec change has been implemented and validated.
• You need to finalize and document a change before marking it complete.
• Tests pass, approvals are present, and deployment or rollout is done (or documented).
• You want to capture learnings, metrics, and follow-up tasks before closing the workflow.
• You need to publish approved spec deltas into the canonical specs directory.

Best practices

• Confirm every checklist item in CHECKLIST.md before proceeding.
• Collect and attach validation evidence (tests, reviewer feedback) to the implementation_log.
• Record concrete metrics: time spent, lines changed, tests added, and rollout impact.
• Document deviations from the proposal and rationale in archive.md for future audits.
• Assign owners for any follow-up tasks and surface them in the updated proposal/tasks.

Example use cases

• Developer asks to “Archive this change” after a successful rollout to production.
• Release manager finalizes a small spec update and needs canonical specs synchronized.
• QA provides passing validation evidence and you need to capture metrics and lessons learned.
• Project lead wants an audit-ready archive of approvals, deployment notes, and rollback instructions.
• Team performs post-implementation review and publishes follow-up tasks and owners.