← ClaudeAtlas

staging-to-prod-cutover-campaignlisted

Use when standing up a new deployment environment (first staging deploy, or a greenfield production environment), when infra work has been authored but not yet applied, or when deciding what staging config must never be inherited by production. Covers first-apply traps, ops-script deployment pitfalls, and the do-not-inherit scrub.
HamzaYM/reliable-ai-skills · ★ 0 · AI & Automation · score 67
Install: claude install-skill HamzaYM/reliable-ai-skills
# Staging-to-prod cutover campaign Standing up real infrastructure (a first staging environment, or a greenfield production environment separate from staging) has a small set of traps that recur across almost every stack, plus one discipline that matters more than any individual trap: **probe the actual live state before acting on what a doc says**, because infra docs rot the moment anyone applies something out of band. ## Step 0: probe, don't assume Before touching any infrastructure, determine the real state with live commands, not by trusting a doc's last-updated date: - Has the relevant infra branch/config actually been applied anywhere, or does it only exist as authored-but-unapplied code? - Does a CI/CD pipeline actually exist and run on the branch you think is live, or does automation live only on an unmerged branch? - Can you actually authenticate to the target cloud account right now? (Session tokens expire silently and mid-task. Check this before starting any work that touches live infrastructure, not after you hit an auth error partway through.) - Has the state-backend/bootstrap step (e.g., a Terraform state bucket) actually been created, or does nothing exist yet? Never proceed on "the doc says X" without a live check backing it up. Treat a doc's own staleness disclaimer as a warning that it needs re-verification, not as ambient permission to trust it anyway. ## Hard rule: never apply, push, or activate automation without an explicit go-ahead `plan`/`valida