/deploy-checklist

name: deploy-checklist
description: Execute a structured deployment to staging or production. Use when asked to deploy, ship, release, push to production, or promote to staging.
license: MIT
compatibility: Requires git and access to the deployment target
allowed-tools: Bash(git:*) Bash(docker:*) Bash(kubectl:*)

Clarification Gates

You must have unambiguous answers to these before touching anything:

• **Target:** staging or production? (Never assume. Never infer from branch name.)
• **Deploying what:** which service, which version/tag/commit SHA?
• **Rollback plan:** does one exist, and do you have access to execute it?

If the user says "deploy the thing" without specifying the environment, that is not sufficient information. Ask.

> **Model Proposes, Code Disposes:** You propose the deploy sequence. The CI/CD system or platform CLI executes it. You do not write deployment commands from memory — you use exactly the command documented in the project's deploy runbook or Makefile.

Pre-deployment

1. **Confirm the target environment.** Ask if not specified: staging or production? Never assume production. 2. **Check the branch.** Verify you are on the correct branch:

   git branch --show-current

3. **Check for uncommitted changes:**

   git status --porcelain

If there are uncommitted changes, STOP. Commit or stash them first. 4. **Run the test suite.** Execute the project's full test command. If any test fails, STOP. Do not deploy with failing tests. 5. **Check the changelog/diff.** Run `git log --oneline main..HEAD` to see what will be deployed. Present this to the user.

Deployment

6. **Execute the deploy command.** Use the project's existing deployment mechanism:

• Docker: `docker build && docker push`
• Kubernetes: `kubectl apply -f`
• Platform-specific: `fly deploy`, `vercel --prod`, `gcloud run deploy`

Use exactly the command documented in the project. Do not invent deployment commands.

7. **Wait for deployment to complete.** Do not proceed until the deployment tool confirms success.

Post-deployment

8. **Smoke test.** Hit the health endpoint or run a basic functional test:

   curl -s https://<deployed-url>/health | jq .

9. **Monitor for 2 minutes.** Check error rates and latency. If either spikes, recommend an immediate rollback.

Rationalizations

| Excuse | Rebuttal | |--------|----------| | "Tests are slow, I'll skip them" | Deploying untested code is how you get paged at 3 AM. Run the tests. | | "It works on my machine" | That is not evidence. The test suite is evidence. | | "I'll just deploy and fix issues as they come" | You have no rollback plan if you don't know what changed. Check the diff first. |

Verification

• [ ] Target environment was explicitly confirmed (not assumed)
• [ ] All tests passed before deployment
• [ ] Deployment tool reported success
• [ ] Health check returned 200 after deployment
• [ ] No error spike observed in the first 2 minutes