| name | acp-release-check |
| description | Use before releasing, deploying, publishing, cutting a tag, or merging into a production-bound branch. Classifies risk level and audits verification evidence, rollback plan, and operational readiness — not just whether the code compiles. |
| version | 1.0.0 |
Release Check Skill
Use this skill before releasing, deploying, publishing, or merging a change into a production-bound branch.
The goal is to reduce release risk, not to create a long ceremony.
Release Review Workflow
1. Identify the Release Scope
Summarize:
- What is being released?
- Which features, fixes, or refactors are included?
- Which platforms, services, or users are affected?
- Is this a full release, gray release, hotfix, rollback, or experiment?
2. Classify Risk
Classify the release as low, medium, or high risk.
High-risk signals:
- Auth or permission logic.
- Payment or billing logic.
- Data migration.
- Database schema changes.
- Security-sensitive code.
- Privacy-sensitive data.
- Public API changes.
- Large refactors.
- Weak test coverage.
- Tight deadline or emergency release.
3. Check Verification Evidence
Look for:
- Unit tests.
- Integration tests.
- E2E tests.
- Type checks.
- Lint.
- Build artifacts.
- Manual verification notes.
- Gray release observations.
- Rollback rehearsal or rollback plan.
If evidence is missing, mark it as a release risk.
4. Check Operational Readiness
Confirm:
- Monitoring exists.
- Logs are available.
- Alerts are configured if needed.
- Rollback path is clear.
- Owners are known.
- Stakeholders are informed.
- User-facing impact is understood.
Output Format
Release scope:
- ...
Risk level:
- Low / Medium / High
Verification evidence:
- ...
Missing evidence:
- ...
Rollback plan:
- ...
Recommendation:
- Go / Go with caution / No-go
Rule
Do not say a release is safe only because the code compiles.
A release is safe when the change scope, verification evidence, runtime observability, and rollback path are all clear.
