| name | release-engineering |
| description | Plan and verify software releases with versioning, changelogs, release branches, feature flags, canaries, migration gates, rollback, deployment checks, and release readiness. Use when preparing a release, shipping a risky PR, coordinating app/backend/database rollout, recovering from a bad deploy, or defining release policy for a repo. |
Release Engineering
Purpose
Use this skill to turn "ready to merge" into a controlled release. It connects code, data, config, deployment, monitoring, and rollback.
Release Classification
Classify the release before choosing gates:
| Type | Extra Gates |
|---|
| Patch fix | focused regression test, rollback proof |
| Feature release | feature flag, docs/changelog, product acceptance |
| API or SDK change | versioning, deprecation, compatibility tests |
| Database migration | data-contract-migrations, backup, backfill, recovery |
| Config or secret change | config-secrets-environments, rotation, drift check |
| Infrastructure change | canary, health checks, capacity and rollback |
Release Plan
For non-trivial releases, require:
- Version or release identifier.
- Changelog entries grouped by user impact.
- Build artifacts and provenance.
- Migration and config gates.
- Canary or staged rollout plan.
- Monitoring dashboard and alert expectations.
- Rollback or roll-forward command.
- Owner, decision time, and abort criteria.
Verification
Use fresh commands from the current session. Typical gates:
git status --short
git log --oneline -n 5
Do not claim a release shipped unless remote git, CI, artifact, and runtime state have each been checked at the required level.
Output Shape
release_scope:
version_or_identifier:
included_changes:
excluded_changes:
pre_release_checks:
rollout_steps:
migration_and_config_gates:
monitoring:
rollback_or_recovery:
go_no_go_status:
