production-deployment
Skill216 starsChanged 6 months agoMITView on GitHub
Zero-downtime deployments with pre-flight checks, staged rollouts, and rollback plans. Never ship to production without a verified rollback strategy.
We split this skill into the rules it gives an agent
14 rules. About 0 are common, 14 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈14
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 17
Before any deployment to a production or production-equivalent environment
- Distinctive: line 18
When reviewing deployment scripts or CI/CD pipelines
- Distinctive: line 19
When adding new services or infrastructure changes
- Distinctive: line 32
Verify: All 6 checklist items confirmed.
- Distinctive: line 36
Never deploy to 100% of traffic immediately.
- Distinctive: line 51
Keep communication channel open with on-call engineer.
- Distinctive: line 52
Do not perform any other changes during a deployment (no "quick fixes").
- Distinctive: line 61
No unexpected alerts triggered.
- Distinctive: line 62
Run post-deploy integration tests if available.
- Distinctive: line 64
Verify: All post-deploy checks confirmed green.
- Distinctive: line 68
If any abort threshold is hit: rollback immediately, without debate.
- Distinctive: line 70
Verify rollback complete: service restored, error rate normalized.
- Distinctive: line 71
Write an incident report — even for near-misses.
- Distinctive: line 88
No rollback plan documented before deployment
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Overview
Production is not a test environment. Every deployment is a live operation with real consequences — user impact, data integrity risks, and potential outages. This skill encodes the discipline senior engineers apply before, during, and after every production deployment.
The core rule: never deploy without a rollback plan you've verified can execute in under 5 minutes.
When to Use
- Before any deployment to a production or production-equivalent environment
- When reviewing deployment scripts or CI/CD pipelines
- When adding new services or infrastructure changes
Process
Step 1: Pre-Deployment Checklist
- All tests pass — CI is green on the exact commit being deployed. Not "mostly green."
- Migrations are backward-compatible — The old code must work with the new schema (for zero-downtime). New columns are nullable; columns aren't dropped until after full rollout.
- Feature flags configured — New features are behind flags, off by default.
- Rollback plan written — Document exactly how to rollback: which commands, which configs, estimated time.
- Deployment window confirmed — Low-traffic period? On-call engineer available?
- Stakeholders notified — Anyone affected by downtime or behavior change knows.
Verify: All 6 checklist items confirmed. Do not proceed if any is blocked.
Step 2: Staged Rollout
- Never deploy to 100% of traffic immediately. Use a staged rollout:
- Canary: 1–5% of traffic
- Staged: 10% → 25% → 50% → 100%
- Monitor key metrics at each stage for at least 15 minutes before expanding:
- Error rate (baseline vs. current)
- Latency p50, p95, p99
- Business metrics (conversion, orders, etc.)
- Define your abort threshold before starting: "If error rate exceeds X% or latency p99 exceeds Y ms, rollback immediately."
Verify: Rollout stages and abort thresholds are documented before deployment begins.
Step 3: Deploy
- Execute the deployment using your CI/CD pipeline (not manual commands).
- Monitor dashboards in real-time during the rollout.
- Keep communication channel open with on-call engineer.
- Do not perform any other changes during a deployment (no "quick fixes").
Verify: Deployment running via CI/CD, dashboards being monitored actively.
Step 4: Post-Deployment Verification
- Smoke tests pass on production.
- Key user journeys manually verified.
- Error rate within normal range (15 minutes post-deploy).
- No unexpected alerts triggered.
- Run post-deploy integration tests if available.
Verify: All post-deploy checks confirmed green. Deployment marked successful.
Step 5: Rollback (if needed)
- If any abort threshold is hit: rollback immediately, without debate.
- Execute the pre-written rollback plan.
- Verify rollback complete: service restored, error rate normalized.
- Write an incident report — even for near-misses.
Verify: Rollback completes in under 5 minutes. Service restored.
Common Rationalizations (and Rebuttals)
| Excuse | Rebuttal |
| "It works in staging" | Staging is not production. Different data, traffic, and configuration. |
| "It's just a small change" | Small changes cause the majority of outages. |
| "We don't have time for staged rollout" | You have even less time for an incident. |
| "I'll watch it for a few minutes" | 15 minutes minimum. Most production failures take time to materialize under load. |
| "We can rollback if needed" | Do you have a written, tested rollback plan? No? Then you can't. |
Red Flags
- Deploying directly to 100% without a staged rollout
- No rollback plan documented before deployment
- Deploying breaking schema changes without backward compatibility
- Running deployment from a local machine, not CI/CD
- Deploying during high-traffic periods without approval
- "I'll fix any issues after we deploy"
Verification
- All tests passing on exact commit being deployed
- Migrations are backward-compatible
- Rollback plan written and executable in <5 minutes
- Staged rollout plan with abort thresholds defined
- Post-deploy smoke tests passed
- Dashboards clean for 15 minutes post-deploy
References
- ci-cd-pipelines skill
- observability skill
- git-workflow skill
- references/deployment-checklist.md
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- jscraik/Agent-Skills★ 9same name
- Yog-Sotho/claude-skills★ 4same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository34 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- agent-qa-run-reviewSkill
- ai-output-validationSkill
- api-designSkill
- ci-cd-pipelinesSkill
- citruscoastaiSkill
- code-explanationSkill
- code-reviewSkill
- context-loadingSkill
- debugging-methodologySkill
- documentationSkill
- error-handlingSkill
- frontend-engineeringSkill
- git-workflowSkill
- goal-driven-executionSkill
- hallucination-preventionSkill
- idea-to-specSkill
- incremental-codingSkill
- integration-testingSkill
- meeting-notes-to-tasksSkill
- multi-agent-orchestrationSkill
- observabilitySkill
- performance-optimizationSkill
- prompt-injection-defenseSkill
- rag-and-memorySkill
- refactoringSkill
- research-and-summarizeSkill
- security-hardeningSkill
- simplicity-firstSkill
- surgical-changesSkill
- task-decompositionSkill
- test-driven-developmentSkill
- think-before-codingSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

