| name | release-checklist |
| description | Build and execute a release checklist from the actual release surface, required evidence, owners, dependencies, approvals, rollout steps, and recovery conditions rather than a generic template. |
Release Checklist
Use when coordinating a software, product, content, configuration, or operational release with multiple readiness conditions.
Procedure
- Define the release artifact, scope, target environments/audiences, version or revision, timing, and accountable release owner.
- Derive checklist items from the real change: build/artifact integrity, tests, migrations, compatibility, security, accessibility, documentation, support, communications, monitoring, and approvals as relevant.
- Assign each item an owner and evidence that proves completion; avoid checkboxes whose meaning is “someone looked at it.”
- Identify sequencing and dependencies, especially irreversible changes, migrations, external vendors, caches, configuration, and staged rollout requirements.
- Include pre-release health checks and the exact artifact/revision being released.
- Define go/no-go criteria and who has authority to decide when evidence is incomplete or conditions degrade.
- Include rollback or forward-recovery readiness and post-release validation steps.
- Record final release state, skipped items with explicit acceptance, and links to evidence.
Decision rules
- A reusable template is a starting point, not proof the current release is covered.
- Never mark validation complete without revision-specific evidence.
- Release scope changes require checklist review.
- High-risk exceptions need explicit authority, not an unchecked box hidden in the list.
Quality gate
The checklist is release-ready when it covers the actual change surface, every consequential item has an owner and evidence, go/no-go and recovery are explicit, the exact artifact/revision is known, and post-release validation is part of completion.
