Plan and review release execution for web, backend, and fullstack systems: preview releases, staging-to-production promotion, rollout strategy, post-deploy verification, rollback response, and release-hardening checklists. Use when the system can already build and the main job is shipping or recovering a release safely, choosing between preview / promotion / canary / rollback paths, or tightening deploy gates around health checks and sign-off. Route CI workflow authoring to `workflow-automation`, machine/runtime setup to `system-environment-setup`, long-lived telemetry design to `monitoring-observability`, and Vercel-specific operations to `vercel-deploy`.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Plan and review release execution for web, backend, and fullstack systems: preview releases, staging-to-production promotion, rollout strategy, post-deploy verification, rollback response, and release-hardening checklists. Use when the system can already build and the main job is shipping or recovering a release safely, choosing between preview / promotion / canary / rollback paths, or tightening deploy gates around health checks and sign-off. Route CI workflow authoring to `workflow-automation`, machine/runtime setup to `system-environment-setup`, long-lived telemetry design to `monitoring-observability`, and Vercel-specific operations to `vercel-deploy`.
allowed-tools
Read Write Edit Glob Grep
compatibility
Best for repositories or delivery workflows where the system can already build and the main problem is safe release execution, promotion, verification, or rollback across preview, staging, and production environments.
Use references/strategy-selection-and-stop-conditions.md when choosing between replace / rolling / blue-green / canary / progressive paths.
Use references/rollout-and-rollback-checklist.md as the minimum release-safety checklist before finalizing.
Step 5: Apply release-execution rules
Separate build from release. A passing build does not prove the release is safe.
Separate deploy from exposure. Traffic shifts, promotion gates, and feature flags may matter more than the initial deploy command.
Separate app rollback from data rollback. Never imply they are the same.
Prefer the smallest rollout strategy that matches the team’s verification maturity.
Prefer same-artifact promotion when reproducibility matters. If the system rebuilds per env, call out the risk explicitly.
Verification is mandatory. Health + one core flow is the minimum acceptable finish line.
Stop conditions beat optimism. Name what should halt promotion or trigger rollback.
Step 6: Produce a release packet, not a DevOps lecture
route platform detail to the correct adjacent skill.
Do not respond by inventing another generic deployment wrapper, re-explaining all of Kubernetes, or absorbing CI authoring into this skill.
Output format
Return:
chosen release mode,
evidence gathered and unknowns,
rollout strategy with rationale,
verification plan,
rollback or recovery plan,
route-outs or remaining risks.
Examples
Example 1: Preview deploy confusion
Input: "Every PR gets a preview URL, but reviewers keep approving broken flows. What should the deployment process actually require before merge?"
Output shape: classify as preview-release, define what the preview proves, list smoke checks, and separate preview verification from later staging/prod promotion.
Example 2: Staging to production promotion
Input: "We deploy to staging automatically, but production promotion is still a manual Slack ritual. Give us the safest release packet."
Output shape: classify as environment-promotion, name artifact and gates, require post-promote checks, and specify rollback plus schema caveats.
Example 3: Failed production deploy
Input: "The latest release is timing out in production and it also included a migration. We need the safest rollback plan."
Output shape: classify as rollback-response, contain blast radius, separate app rollback from migration risk, and define post-recovery verification.
Best practices
Keep the front door about release decisions, not platform encyclopedias.
Name the real artifact, environment, and rollback path before suggesting anything.
Prefer short release packets that an operator can run under pressure.
Route provider-specific and adjacent concerns out early.
Treat verification and stop conditions as required output, not optional polish.
