---
name: deploy-readiness-checklist
description: "Gates a production deploy before it ships — runs the plan through five hard go/no-go checks (schema change staged ahead of the code that needs it, new behavior dark by default, a named reversible way back, a canary with numeric abort criteria plus smoke checks, and a named owner watching with a comms plan) and returns SHIP / FIX FIRST / BLOCK, not a vibe check. Use when someone asks whether a release is ready to push to prod. Do NOT use for reviewing a single migration's SQL in isolation, writing a postmortem, or classifying an incident's severity."
metadata:
  decimalai-skill-id: "91fdb56c-6044-4dbe-9f0e-bd136fb81240"
  decimalai-version-id: "44022412-f7cd-4bc2-b220-3bfda44b5cdf"
  decimalai-version: "1"
  decimalai-body-sha256: "e182fda1f44abe379353ab87f6efae7fb50bfbcd18a11f78168250a9877eea84"
  decimalai-name: "deploy-readiness-checklist"
  decimalai-format: "1"
  decimalai-invocation: "model"
  decimalai-category: "devops"
  decimalai-source: "https://app.decimal.ai/s/deploy-readiness-checklist@1/SKILL.md"
---
# Deploy Readiness Checklist

Gates a production release before it ships. Given a deploy plan — the diff, the migrations, how it rolls out, and who is running it — decide whether it is safe to push now. The output is a go/no-go decision with a named blocker for anything missing, not a general "looks good, ship it."

The base model knows every one of these practices but does not enforce them when asked "is this ready to deploy?" — it tends to summarize the change and approve it, mentioning rollback or a flag only if the plan already did. This skill makes five checks mandatory and refuses to ship on any hard failure.

## When to Activate

Activate when the user asks to:
- Are we ready to deploy this / push this to prod?
- Review the release plan before we ship tonight
- Is this rollout safe / good to go?
- Sign off on this deploy
- Go/no-go on this release

## The Five Gates

Run the plan through all five. Each is PASS or a finding — do not skip a gate because the plan didn't mention it; a gate the plan is silent on is a failing gate, not an absent one.

### Gate 1 — Schema change staged ahead of the code

A schema or data change must land in its own step **before** the code that depends on the new shape, and anything destructive (dropping a column, removing a table) happens **after** the new code is fully rolled out — the expand-then-contract order. Fail if:
- One deploy both changes the shape and ships code that requires it, so a mid-rollout instance sees a shape its code can't handle.
- It drops or renames something the currently-running code still reads.
- The change requires downtime that the plan hasn't called out and accepted.

### Gate 2 — New behavior is dark by default

A meaningful behavior change ships turned off, and turning it on for users is a separate switch flip, not the act of deploying. Fail if:
- The new path is live for everyone the moment the deploy lands (release is welded to deploy — you can't turn it on gradually or turn it off without a redeploy).
- A risky behavior change has no off switch at all.
- The switch exists but defaults on at deploy time.

### Gate 3 — A named, reversible way back

There is one specific, already-decided way to undo this — a named artifact to revert to, a switch to flip off, or a down-migration — and it does not lose data. Fail if:
- "We'll fix forward" is the only plan for a risky change.
- An irreversible data change ships in the same step as the code that could force the rollback.
- The rollback is asserted but not named ("we can roll back" with no artifact, command, or switch).

### Gate 4 — Canary with numeric abort criteria and smoke checks

The change reaches a small slice first, watched against **concrete numbers** (error rate, latency, a business metric) for a stated bake time, and specific post-deploy smoke checks are named. Fail if:
- It goes to 100% at once with no staged exposure for a risky change.
- The canary has no numeric threshold that would abort it ("we'll watch the dashboards" is not a criterion).
- No smoke check is named, so "it deployed" is being treated as "it works."

### Gate 5 — A named owner and a comms plan

A specific person is watching this deploy through its bake window, and the plan says who gets told — and how — if it goes wrong. Fail if:
- No one is named as the owner for the deploy window.
- A customer-visible or risky change has no notify path (status page, stakeholders, support) for a bad outcome.

## Output

A gate table, then a one-line verdict.

| Gate | Status | Finding / what's missing |
|---|---|---|
| 1 Schema staged ahead of code | 🔴 Block | Migration adds a required column in the same deploy as the code that reads it |
| 2 Dark by default | 🟡 Fix | New flow is on for all users at deploy; add an off-by-default switch |
| 3 Reversible way back | ✅ Pass | Revert to previous image tag; down-migration included |
| 4 Canary + smoke | 🔴 Block | Ships to 100% at once, no abort threshold |
| 5 Owner + comms | ✅ Pass | Named on-call owner; status-page path defined |

**Verdict:** SHIP / FIX FIRST / BLOCK — one line naming the single biggest reason. Any 🔴 makes the verdict BLOCK; only 🟡/✅ makes it FIX FIRST or SHIP.

## Examples

### Input
```
Deploy plan: ship the new pricing engine tonight.
- Migration adds a `plan_tier` column and the new code reads it in the same release.
- Pricing switches to the new engine for all accounts as soon as it's live.
- If something breaks we'll patch forward.
- Rolling out to the whole fleet in one go.
- I'll kick it off before I log off.
```

### Expected Output

| Gate | Status | Finding |
|---|---|---|
| 1 Schema staged ahead of code | 🔴 Block | Column and the code that requires it ship together; a half-rolled instance hits a column its peers don't have — split the migration into an earlier deploy |
| 2 Dark by default | 🔴 Block | New engine is on for every account at deploy; put it behind an off-by-default switch so turn-on is a separate, reversible step |
| 3 Reversible way back | 🔴 Block | "Patch forward" is the only plan — name a revert artifact and confirm the migration is reversible without data loss |
| 4 Canary + smoke | 🔴 Block | 100% at once with no staged slice, no abort number, no smoke check |
| 5 Owner + comms | 🟡 Fix | You start it then log off — no one is watching the bake window and no notify path is named |

**Verdict:** BLOCK — nothing here is staged or reversible; a bad pricing calc would hit every account at once with no way back short of a forward patch.

## Edge Cases

- **Pure additive, no behavior change** (a new nullable column nothing reads yet, a dark endpoint): Gates 2 and 4 relax — there's nothing to flag or canary. Say so instead of inventing a flag.
- **Config-only / copy change:** Gate 1 is N/A. Still require a way back (Gate 3) and an owner (Gate 5).
- **Accepted-downtime maintenance window:** if the team has explicitly chosen and announced downtime, Gate 1's "no downtime" softens — but reversibility and an owner still hold.
- **Genuinely low-risk change with all five satisfied:** return SHIP. Do not manufacture blockers to look thorough — over-flagging a clean plan is as wrong as waving through a dangerous one.
- **Internal tool, tiny blast radius:** scale the canary and comms expectations down, but still name a way back.

## Evaluation Criteria

A good execution of this skill should:
- [ ] Run all five gates, treating a gate the plan is silent on as a failure, not as absent
- [ ] Flag a migration that ships in the same deploy as the code that requires it, or a drop that races a rolling deploy
- [ ] Require the new behavior to be off by default and decoupled from the deploy itself
- [ ] Reject "roll forward" as a rollback plan and demand a named, reversible way back
- [ ] Require a numeric abort criterion and a named smoke check, not just "we'll watch it"
- [ ] Require a named owner for the bake window and a notify path for a bad outcome
- [ ] Return SHIP for a genuinely clean plan instead of inventing blockers