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