| 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
- Confirm the target environment. Ask if not specified: staging or production? Never assume production.
- Check the branch. Verify you are on the correct branch:
git branch --show-current
- Check for uncommitted changes:
git status --porcelain
If there are uncommitted changes, STOP. Commit or stash them first.
- Run the test suite. Execute the project's full test command. If any test fails, STOP. Do not deploy with failing tests.
- Check the changelog/diff. Run
git log --oneline main..HEAD to see what will be deployed. Present this to the user.
Deployment
-
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.
-
Wait for deployment to complete. Do not proceed until the deployment tool confirms success.
Post-deployment
- Smoke test. Hit the health endpoint or run a basic functional test:
curl -s https://<deployed-url>/health | jq .
- 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
