agentsclimarketplace

Deploy production

Skill alex-voloshin-dev/ai-skills/.agents/skills/deploy-production

Deploy to production workflow — final checks, approval gate, deploy, verify, rollback plan. Uses the `deployment-procedures` skill. Requires explicit APPROVE before any production mutation.From its SKILL.md

Install
npx -y skills add alex-voloshin-dev/ai-skills --skill deploy-production

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.5 KB, as published. Nobody here has run it

Deploy to Production

Production deployment with mandatory approval gates, verification, and rollback plan. Every step that mutates production requires explicit user APPROVE.

⚠️ SAFETY: No production mutation runs without explicit user APPROVE.

0. Gather Context

Read AGENTS.md at the project root to identify:

  • Cloud platform (GCP, Azure, AWS)
  • Deployment method (Kubernetes, Helm, Docker Compose, serverless)
  • Production environment configuration (namespace, cluster, region)
  • CI/CD pipeline (GitHub Actions, GitLab CI, Jenkins)

This determines which deployment commands and health checks apply.

1. Pre-Deployment Checklist

1a. Staging Verification

Confirm that staging deployment was successful:

  • /deploy-staging completed successfully
  • QA testing passed on staging
  • No critical bugs found in staging
  • Performance acceptable on staging

If staging was not verified — STOP. Run /deploy-staging first.

1b. Release Readiness

  • Version tagged (/release completed)
  • Changelog updated
  • All tests pass on the release branch
  • Database migrations tested (forward and rollback)
  • Feature flags configured (if applicable)
  • Monitoring dashboards ready
  • On-call team notified

1c. Risk Assessment

FactorAssessment
Breaking changesYes/No — migration guide ready?
Database migrationsYes/No — reversible?
Infrastructure changesYes/No — /infra-change completed?
Third-party dependenciesYes/No — API compatibility verified?
Traffic impactLow/Medium/High
Rollback complexitySimple (revert image) / Complex (DB migration)

If Risk = HIGH, apply Agent(sre-engineer) for SLO impact assessment.

2. Prepare Deployment

2a. Identify Deployment Method

Same as /deploy-staging Step 1c — but with production configuration.

2b. Backup Current State

# Record current deployment state for rollback
kubectl get deployment -n production -o yaml > pre-deploy-state.yaml

Or for Helm:

helm get values <release> -n production > pre-deploy-values.yaml
helm history <release> -n production

2c. Deployment Plan

Present the deployment plan:

## Production Deployment Plan
- **Version**: [current] → [new]
- **Method**: [K8s/Helm/Docker/Platform]
- **Migrations**: [list if any]
- **Config changes**: [list if any]
- **Expected downtime**: [none / X minutes]
- **Rollback plan**: [documented in Step 5]
- **Monitoring**: [dashboards to watch]

⚠️ STOP. Request APPROVE before proceeding to Step 3.

3. Deploy — REQUIRES EXPLICIT APPROVE

Only after the user explicitly approves:

3a. Run Migrations (if applicable)

# Database migration
<migration-command>

Verify migration completed successfully before proceeding.

3b. Deploy Application

Kubernetes / Helm:

helm upgrade --install <release> <chart> \
  -n production \
  -f values-production.yaml \
  --set image.tag=<tag>

Rolling update strategy — monitor pod rollout:

kubectl rollout status deployment/<name> -n production --timeout=300s

3c. Canary (if applicable)

If using canary deployment:

  1. Deploy to canary (small % of traffic)
  2. Monitor error rates and latency for 5–10 minutes
  3. If metrics are healthy → proceed to full rollout
  4. If degradation detected → rollback canary immediately

4. Post-Deployment Verification

4a. Health Check

// turbo
kubectl get pods -n production -o wide
curl -s <production-url>/health

4b. Smoke Tests

  • Application responds on production URL
  • Health endpoint returns 200
  • Authentication flow works
  • Core API endpoints respond correctly
  • Key user journeys functional

4c. Monitor (5–10 minutes)

Watch for:

  • Error rate: Should not increase vs pre-deploy baseline
  • Latency: P50, P95, P99 within SLO targets
  • CPU/Memory: No unusual spikes
  • Logs: No new error patterns
// turbo
kubectl logs -n production -l app=<app-name> --tail=100 --since=5m
// turbo
kubectl get events -n production --sort-by='.lastTimestamp' --field-selector type!=Normal

5. Rollback Plan

If issues detected — execute rollback immediately:

Helm:

helm rollback <release> <previous-revision> -n production

Kubernetes:

kubectl rollout undo deployment/<name> -n production

Database migration rollback:

<rollback-migration-command>

After rollback:

  • Verify application is healthy
  • Notify team of rollback
  • Create incident ticket for investigation

6. Summary

## Production Deployment Summary
- **Version**: [old] → [new]
- **Deployed at**: [timestamp]
- **Method**: [K8s/Helm/Docker/Platform]
- **Migrations**: [applied/N/A]
- **Health check**: [pass/fail]
- **Smoke tests**: [pass/fail]
- **Monitoring**: [stable/issues detected]
- **Rollback**: [not needed / executed at timestamp]
- **Production URL**: [url]
- **Next steps**: [monitoring period, team notification, release announcement]

Integration

  • Preceded by: /deploy-staging (staging verification), /release (version tag)
  • Roles: Agent(devops-engineer), Agent(sre-engineer), Agent(devops-architect) (deployment strategy design)
  • Skills: deployment-procedures skill

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.