deployment-automation · diff
git:20260319.0905165 to v2.0.0
321 added, 470 removed. Audit A to A.
---
name: deployment-automation
- description: Automate application deployment to cloud platforms and servers. Use when setting up CI/CD pipelines, deploying to Docker/Kubernetes, or configuring cloud infrastructure. Handles GitHub Actions, Docker, Kubernetes, AWS, Vercel, and deployment best practices.
+ description: >
+ Plan and execute hosted deployment and rollout automation for web, backend, and
+ fullstack systems: preview/staging/prod promotion, release verification,
+ rollback planning, provider handoff, and deployment runbooks. Use when the main
+ job is shipping a built artifact or service safely to an environment, choosing a
+ rollout strategy, or tightening deploy/release steps around health checks and
+ promotion rules. Triggers on: deployment automation, deploy pipeline, release
+ rollout, staging to prod, preview environment, canary, blue-green, rollback,
+ post-deploy verification, and release promotion. Route CI workflow authoring to
+ `workflow-automation`, machine/runtime setup to `system-environment-setup`,
+ ongoing dashboards/alerts to `monitoring-observability`, and Vercel-specific
+ operations to `vercel-deploy`.
+ allowed-tools: Read Write Edit Glob Grep
+ compatibility: >
+ Best for repositories or delivery workflows where the system can already build
+ and the main problem is safely promoting, deploying, verifying, or rolling back
+ a release across preview, staging, and production environments.
+ license: MIT
metadata:
- tags: deployment, CI/CD, Docker, Kubernetes, AWS, GitHub-Actions, automation
- platforms: Claude, ChatGPT, Gemini
- allowed-tools: Bash Read Write
+ tags: deployment, release-rollout, preview-environments, rollback, progressive-delivery, post-deploy-verification, devops
+ platforms: Claude, ChatGPT, Gemini, Codex
+ version: "2.0.0"
+ modernization: 2026-04-13
+ source: akillness/oh-my-skills
---
-
# Deployment Automation
-
- ## When to use this skill
-
- - **New Projects**: Set up automated deployment from scratch
- - **Manual Deployment Improvement**: Automate repetitive manual tasks
- - **Multi-Environment**: Separate dev, staging, and production environments
- - **Scaling**: Introduce Kubernetes to handle traffic growth
-
- ## Instructions
-
- ### Step 1: Docker Containerization
-
- Package the application as a Docker image.
-
- **Dockerfile** (Node.js app):
- ```dockerfile
- # Multi-stage build for smaller image size
- FROM node:18-alpine AS builder
-
- WORKDIR /app
-
- # Copy package files and install dependencies
- COPY package*.json ./
- RUN npm ci --only=production
-
- # Copy source code
- COPY . .
-
- # Build application (if needed)
- RUN npm run build
-
- # Production stage
- FROM node:18-alpine
-
- WORKDIR /app
-
- # Copy only necessary files from builder
- COPY --from=builder /app/node_modules ./node_modules
- COPY --from=builder /app/dist ./dist
- COPY --from=builder /app/package.json ./
-
- # Create non-root user for security
- RUN addgroup -g 1001 -S nodejs && \
- adduser -S nodejs -u 1001
- USER nodejs
-
- # Expose port
- EXPOSE 3000
+ Use this skill when the main job is **getting an already-buildable system safely into an environment and proving the rollout worked**.
- # Health check
- HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
- CMD node healthcheck.js
+ `deployment-automation` is the infrastructure/dev-workflow anchor for:
+ - preview, staging, and production deployment flows
+ - release promotion and environment gates
+ - rollout strategy choice: replace, rolling, blue-green, canary, progressive
+ - deployment preflight and post-deploy verification
+ - rollback planning and bad-release containment
+ - provider handoff across static hosts, container PaaS, Kubernetes, and generic CI-driven deploy paths
- # Start application
- CMD ["node", "dist/index.js"]
- ```
+ Read these support docs before choosing the mode or boundary:
+ - [references/deployment-modes-and-boundaries.md](references/deployment-modes-and-boundaries.md)
+ - [references/rollout-and-rollback-checklist.md](references/rollout-and-rollback-checklist.md)
+ - [references/platform-routing-notes.md](references/platform-routing-notes.md)
- **.dockerignore**:
- ```
- node_modules
- npm-debug.log
- .git
- .env
- .env.local
- dist
- build
- coverage
- .DS_Store
- ```
+ ## When to use this skill
+ - A team needs a safe deploy/runbook path for preview, staging, or production
+ - A release flow needs preflight checks, promotion gates, smoke checks, and rollback rules
+ - The question is whether to use direct deploy, rolling, blue-green, canary, or progressive delivery
+ - A project already has buildable artifacts, but release execution is still a mix of tribal knowledge and shell history
+ - The deploy path needs clearer separation between preview deploys, staging promotion, and production rollout
+ - A deployment failed and the next job is to verify, stop, or roll back rather than redesign the whole observability stack
+ - The user needs a vendor-neutral release packet before using Vercel, Render, Fly.io, Kubernetes, or a CI-driven provider path
- **Build and Run**:
- ```bash
- # Build image
- docker build -t myapp:latest .
+ ## When not to use this skill
+ - **The main job is authoring or refactoring GitHub Actions / GitLab / Jenkins / Buildkite workflows, task runners, or repo-local release glue** → use `workflow-automation`
+ - **The main job is installing CLIs, Docker, kubectl, cloud SDKs, auth bootstrap, or making the machine runnable** → use `system-environment-setup`
+ - **The main job is long-lived dashboards, alerts, traces, metrics, log pipelines, or incident telemetry architecture** → use `monitoring-observability`
+ - **The main job is Vercel-specific project linking, domains, aliases, or Vercel environment settings** → use `vercel-deploy`
+ - **The main job is secret rotation, IAM policy, supply-chain hardening, or compliance evidence design** → route to the relevant security skill
+ - **The system cannot even build or package successfully yet** → fix build/test/setup problems before reopening deployment automation
- # Run container
- docker run -d -p 3000:3000 --name myapp-container myapp:latest
+ ## Instructions
- # Check logs
- docker logs myapp-container
+ ### Step 1: Classify the deployment job before touching commands
+ Normalize the request into one primary mode.
- # Stop and remove
- docker stop myapp-container
- docker rm myapp-container
+ ```yaml
+ deployment_mode:
+ primary_mode: preview-release | environment-promotion | container-paas | kubernetes-rollout | rollback-response | release-hardening
+ runtime_shape: static-frontend | web-app | api-service | worker-job | multi-service | unknown
+ artifact_shape: platform-build | image | build-output | package | unknown
+ target_environment: preview | staging | production | mixed | unknown
+ promotion_model: direct-deploy | same-artifact-promotion | rebuild-per-env | unknown
+ rollout_strategy: replace | rolling | blue-green | canary | progressive | unknown
+ stateful_risk: low | medium | high | unknown
+ verification_depth: health-only | smoke-tests | release-checklist | automated-analysis | unknown
```
- ### Step 2: GitHub Actions CI/CD
-
- Automatically runs tests and deploys on code push.
+ Choose exactly one primary mode per run:
+ - `preview-release` → branch/PR deploys, preview URLs, and pre-merge verification
+ - `environment-promotion` → staging → production or multi-env promotion with gates
+ - `container-paas` → Render/Fly/railway-style or generic image/container-based releases
+ - `kubernetes-rollout` → deployments driven by Helm/Kustomize/Argo/Kubernetes rollout mechanics
+ - `rollback-response` → contain a bad deploy, restore service, and document the next safe action
+ - `release-hardening` → add missing preflight, approvals, smoke tests, or release packet structure around an existing deploy path
- **.github/workflows/deploy.yml**:
- ```yaml
- name: CI/CD Pipeline
+ ### Step 2: Confirm the real source of truth and boundary skills
+ Before prescribing steps, answer these questions:
+ 1. What artifact is actually being shipped: platform build, image, bundle, or unknown?
+ 2. Which environment is in scope right now: preview, staging, or production?
+ 3. Is the same artifact promoted across environments, or rebuilt per env?
+ 4. What is the rollback method: redeploy prior artifact, traffic switchback, platform rollback, or manual recovery?
+ 5. Which neighboring skill really owns the unsolved part?
- on:
- push:
- branches: [main, develop]
- pull_request:
- branches: [main]
+ Quick route-out table:
- env:
- NODE_VERSION: '18'
- REGISTRY: ghcr.io
- IMAGE_NAME: ${{ github.repository }}
+ | If the request sounds like... | Use |
+ |---|---|
+ | "Set up or rewrite the deploy workflow YAML / task runner / release scripts" | `workflow-automation` |
+ | "Install Docker / kubectl / cloud CLI / authenticate this machine" | `system-environment-setup` |
+ | "Set up dashboards, alerts, traces, or SLOs" | `monitoring-observability` |
+ | "Deploy this site/app specifically to Vercel" | `vercel-deploy` |
+ | "Handle secret rotation, IAM scopes, signing, or compliance controls" | security skill |
+ | "Pick rollout strategy, promotion gates, verification, and rollback plan" | `deployment-automation` |
- jobs:
- test:
- runs-on: ubuntu-latest
+ ### Step 3: Gather the smallest truthful evidence set
+ Do not improvise a production release flow from vibes. Pull the minimum credible facts first:
+ - current deploy target and provider/runtime
+ - current build artifact or packaging output
+ - environment names and promotion order
+ - existing deploy command / platform action / release job
+ - required secrets/config already expected by the release path
+ - health endpoint, smoke checks, or verification commands
+ - rollback capability and its limitations
+ - whether database/schema changes are part of this release
- steps:
- - uses: actions/checkout@v4
+ If these are incomplete, state the gaps and default to the smallest safe interpretation.
- - name: Setup Node.js
- uses: actions/setup-node@v4
- with:
- node-version: ${{ env.NODE_VERSION }}
- cache: 'npm'
+ ### Step 4: Choose the deployment mode packet
+ Use the smallest packet that fits the job.
- - name: Install dependencies
- run: npm ci
+ #### A. Preview release
+ Use when the main need is shareable verification before prod.
- - name: Run linter
- run: npm run lint
+ Recommended skeleton:
+ ```markdown
+ # Preview Release Packet
- - name: Run tests
- run: npm test -- --coverage
+ ## Target
+ - Provider/runtime:
+ - URL/output:
+ - What reviewers should verify:
- - name: Upload coverage
- uses: codecov/codecov-action@v3
- with:
- files: ./coverage/coverage-final.json
+ ## Preconditions
+ - Build/test status:
+ - Required config present:
- build:
- needs: test
- runs-on: ubuntu-latest
- if: github.event_name == 'push' && github.ref == 'refs/heads/main'
+ ## Deploy steps
+ 1. ...
+ 2. ...
+ 3. ...
- steps:
- - uses: actions/checkout@v4
+ ## Verification
+ - Smoke checks:
+ - Visual / flow checks:
+ - Promote or discard decision:
+ ```
- - name: Set up Docker Buildx
- uses: docker/setup-buildx-action@v3
+ #### B. Environment promotion
+ Use when staging → production is the real job.
- - name: Log in to Container Registry
- uses: docker/login-action@v3
- with:
- registry: ${{ env.REGISTRY }}
- username: ${{ github.actor }}
- password: ${{ secrets.GITHUB_TOKEN }}
+ Recommended skeleton:
+ ```markdown
+ # Environment Promotion Packet
- - name: Extract metadata
- id: meta
- uses: docker/metadata-action@v5
- with:
- images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
- tags: |
- type=sha,prefix={{branch}}-
- type=semver,pattern={{version}}
- latest
+ ## Artifact and environments
+ - Artifact:
+ - Promote from:
+ - Promote to:
+ - Promotion model:
- - name: Build and push Docker image
- uses: docker/build-push-action@v5
- with:
- context: .
- push: true
- tags: ${{ steps.meta.outputs.tags }}
- labels: ${{ steps.meta.outputs.labels }}
- cache-from: type=gha
- cache-to: type=gha,mode=max
+ ## Gates
+ - Required approvals:
+ - Freeze/change-window notes:
+ - Blocking risks:
- deploy:
- needs: build
- runs-on: ubuntu-latest
- environment: production
+ ## Verification
+ - Before promote:
+ - After promote:
- steps:
- - name: Deploy to production
- uses: appleboy/ssh-action@v1.0.0
- with:
- host: ${{ secrets.PROD_HOST }}
- username: ${{ secrets.PROD_USER }}
- key: ${{ secrets.PROD_SSH_KEY }}
- script: |
- cd /app
- docker pull ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest
- docker-compose up -d --no-deps --build web
- docker image prune -f
+ ## Rollback
+ - Immediate rollback path:
+ - Data/schema caveats:
```
- ### Step 3: Kubernetes Deployment
+ #### C. Container/PaaS rollout
+ Use for managed app/container platforms.
- Implement scalable container orchestration.
+ Recommended skeleton:
+ ```markdown
+ # Container/PaaS Rollout Packet
- **k8s/deployment.yaml**:
- ```yaml
- apiVersion: apps/v1
- kind: Deployment
- metadata:
- name: myapp
- namespace: production
- labels:
- app: myapp
- spec:
- replicas: 3
- strategy:
- type: RollingUpdate
- rollingUpdate:
- maxSurge: 1
- maxUnavailable: 0
- selector:
- matchLabels:
- app: myapp
- template:
- metadata:
- labels:
- app: myapp
- spec:
- containers:
- - name: myapp
- image: ghcr.io/username/myapp:latest
- imagePullPolicy: Always
- ports:
- - containerPort: 3000
- env:
- - name: NODE_ENV
- value: "production"
- - name: DATABASE_URL
- valueFrom:
- secretKeyRef:
- name: myapp-secrets
- key: database-url
- resources:
- requests:
- memory: "128Mi"
- cpu: "100m"
- limits:
- memory: "256Mi"
- cpu: "200m"
- livenessProbe:
- httpGet:
- path: /health
- port: 3000
- initialDelaySeconds: 30
- periodSeconds: 10
- readinessProbe:
- httpGet:
- path: /ready
- port: 3000
- initialDelaySeconds: 5
- periodSeconds: 5
+ ## Runtime
+ - Image/build source:
+ - Platform:
+ - Release command:
- ---
- apiVersion: v1
- kind: Service
- metadata:
- name: myapp-service
- namespace: production
- spec:
- selector:
- app: myapp
- ports:
- - protocol: TCP
- port: 80
- targetPort: 3000
- type: LoadBalancer
+ ## Release plan
+ - Direct deploy or staged:
+ - Release checks:
+ - Rollback path:
- ---
- apiVersion: autoscaling/v2
- kind: HorizontalPodAutoscaler
- metadata:
- name: myapp-hpa
- namespace: production
- spec:
- scaleTargetRef:
- apiVersion: apps/v1
- kind: Deployment
- name: myapp
- minReplicas: 2
- maxReplicas: 10
- metrics:
- - type: Resource
- resource:
- name: cpu
- target:
- type: Utilization
- averageUtilization: 70
- - type: Resource
- resource:
- name: memory
- target:
- type: Utilization
- averageUtilization: 80
+ ## Handoffs
+ - Provider-specific follow-up:
+ - Adjacent skills if needed:
```
- **Deployment Script** (deploy.sh):
- ```bash
- #!/bin/bash
- set -e
-
- # Variables
- NAMESPACE="production"
- IMAGE_TAG="${1:-latest}"
-
- echo "Deploying myapp:${IMAGE_TAG} to ${NAMESPACE}..."
+ #### D. Kubernetes rollout
+ Use when rollout strategy and cluster behavior are central.
- # Apply Kubernetes manifests
- kubectl apply -f k8s/namespace.yaml
- kubectl apply -f k8s/secrets.yaml
- kubectl apply -f k8s/deployment.yaml
- kubectl apply -f k8s/service.yaml
+ Recommended skeleton:
+ ```markdown
+ # Kubernetes Rollout Packet
- # Update image
- kubectl set image deployment/myapp myapp=ghcr.io/username/myapp:${IMAGE_TAG} -n ${NAMESPACE}
+ ## Delivery surface
+ - Manifest source:
+ - Deployment/controller:
+ - Strategy:
- # Wait for rollout
- kubectl rollout status deployment/myapp -n ${NAMESPACE} --timeout=5m
+ ## Preflight
+ - Image/tag:
+ - Namespace/env:
+ - Migration/secrets assumptions:
- # Verify
- kubectl get pods -n ${NAMESPACE} -l app=myapp
+ ## Rollout
+ - Apply/promote steps:
+ - Health and readiness checks:
+ - Stop conditions:
- echo "Deployment completed successfully!"
+ ## Rollback
+ - Previous ReplicaSet/version:
+ - Traffic/data caveats:
```
- ### Step 4: Vercel/Netlify (Frontend)
-
- Simply deploy static sites and Next.js apps.
-
- **vercel.json**:
- ```json
- {
- "version": 2,
- "builds": [
- {
- "src": "package.json",
- "use": "@vercel/next"
- }
- ],
- "env": {
- "DATABASE_URL": "@database-url",
- "API_KEY": "@api-key"
- },
- "regions": ["sin1", "icn1"],
- "headers": [
- {
- "source": "/(.*)",
- "headers": [
- {
- "key": "X-Frame-Options",
- "value": "DENY"
- },
- {
- "key": "X-Content-Type-Options",
- "value": "nosniff"
- }
- ]
- }
- ],
- "redirects": [
- {
- "source": "/old-path",
- "destination": "/new-path",
- "permanent": true
- }
- ]
- }
- ```
+ #### E. Rollback response
+ Use when something already went wrong.
- **CLI Deployment**:
- ```bash
- # Install Vercel CLI
- npm i -g vercel
+ Recommended skeleton:
+ ```markdown
+ # Rollback Response Packet
- # Login
- vercel login
+ ## Failure signal
+ - What failed:
+ - Blast radius:
+ - Confidence:
- # Deploy to preview
- vercel
+ ## Immediate containment
+ 1. ...
+ 2. ...
+ 3. ...
- # Deploy to production
- vercel --prod
+ ## Recovery path
+ - Redeploy previous artifact / switch traffic / disable flag:
+ - Data/schema caveats:
- # Set environment variable
- vercel env add DATABASE_URL
+ ## Verification after recovery
+ - Health:
+ - Smoke:
+ - Follow-up hardening:
```
- ### Step 5: Zero-Downtime Deployment Strategy
-
- Deploy new versions without service interruption.
-
- **Blue-Green Deployment** (docker-compose):
- ```yaml
- version: '3.8'
-
- services:
- nginx:
- image: nginx:alpine
- ports:
- - "80:80"
- volumes:
- - ./nginx.conf:/etc/nginx/nginx.conf:ro
- depends_on:
- - app-blue
- - app-green
-
- app-blue:
- image: myapp:blue
- environment:
- - NODE_ENV=production
- - COLOR=blue
-
- app-green:
- image: myapp:green
- environment:
- - NODE_ENV=production
- - COLOR=green
- ```
+ ### Step 5: Apply release-execution rules instead of generic DevOps advice
+ Use these rules aggressively:
+ - **Separate build from release.** The job is not done because a build passed.
+ - **Separate deploy from release.** Feature flags, traffic shifts, and staged exposure are often safer than one big launch.
+ - **Separate app rollback from data/schema rollback.** Never imply they are the same.
+ - **Prefer the smallest rollout strategy that matches risk.** Do not prescribe canary/progressive delivery if the team lacks verification maturity.
+ - **Prefer same-artifact promotion when reproducibility matters.** If the system rebuilds per env, call out the risk explicitly.
+ - **Treat verification as mandatory.** A deploy without health/smoke checks is not complete.
+ - **Treat rollback as a real workflow, not a slogan.** Name the exact path and its caveats.
+ - **Prefer existing project commands and platform entrypoints over invented shell theater.**
- **switch.sh** (Blue/Green Switch):
- ```bash
- #!/bin/bash
+ ### Step 6: Choose the right strategy
+ Use this ladder:
- CURRENT_COLOR=$(cat current_color.txt)
- NEW_COLOR=$([[ "$CURRENT_COLOR" == "blue" ]] && echo "green" || echo "blue")
+ #### Use direct replace when
+ - the system is low-risk or non-critical
+ - rollback is easy
+ - downtime or small blast radius is acceptable
- # Deploy new version to inactive environment
- docker-compose up -d app-${NEW_COLOR}
+ #### Use rolling updates when
+ - the runtime supports gradual replacement
+ - health/readiness checks are credible
+ - the goal is zero-downtime replacement without dual-stack complexity
- # Wait for health check
- sleep 10
+ #### Use blue/green when
+ - traffic switching between old/new versions is possible
+ - fast rollback via traffic reversal matters
+ - infra cost and environment duplication are acceptable
- # Health check
- if curl -f http://localhost:8080/health; then
- # Update nginx to point to new environment
- sed -i "s/${CURRENT_COLOR}/${NEW_COLOR}/g" nginx.conf
- docker-compose exec nginx nginx -s reload
+ #### Use canary/progressive delivery when
+ - the release is high-risk
+ - the team has trustworthy metrics or smoke checks
+ - stop conditions and rollback ownership are explicit
- # Update current color
- echo ${NEW_COLOR} > current_color.txt
+ #### Use feature-flag-assisted release when
+ - deployment and user-visible exposure should be decoupled
+ - the code can ship dark before broad release
+ - rollback by flag disable is safer than full app rollback
- # Stop old environment after 5 minutes (rollback window)
- sleep 300
- docker-compose stop app-${CURRENT_COLOR}
+ ### Step 7: Keep deployment honest about adjacent concerns
+ A strong deployment packet says what it does **not** own.
- echo "Deployment successful! Switched to ${NEW_COLOR}"
- else
- echo "Health check failed! Keeping ${CURRENT_COLOR}"
- docker-compose stop app-${NEW_COLOR}
- exit 1
- fi
- ```
+ Examples:
+ - if the pain is creating the GitHub Actions job, route to `workflow-automation`
+ - if the pain is missing CLIs/auth/local Docker setup, route to `system-environment-setup`
+ - if the pain is lacking dashboards or alerts to verify rollout health, route to `monitoring-observability`
+ - if the task is provider-specific Vercel operations, route to `vercel-deploy`
+ - if the task is secrets/IAM/compliance, route to security-specific skills
- ## Output format
+ Mixed requests are common. Split them explicitly instead of letting one skill become “all DevOps.”
- ### Deployment Checklist
+ ### Step 8: Produce the deployment automation packet
+ Always return a packet another engineer or agent can execute or review.
+ Preferred format:
```markdown
- ## Deployment Checklist
-
- ### Pre-Deployment
- - [ ] All tests passing (unit, integration, E2E)
- - [ ] Code review approved
- - [ ] Environment variables configured
- - [ ] Database migrations ready
- - [ ] Rollback plan documented
-
- ### Deployment
- - [ ] Docker image built and tagged
- - [ ] Image pushed to container registry
- - [ ] Kubernetes manifests applied
- - [ ] Rolling update started
- - [ ] Pods healthy and ready
+ # Deployment Automation Packet
- ### Post-Deployment
- - [ ] Health check endpoint responding
- - [ ] Metrics/logs monitoring active
- - [ ] Performance baseline established
- - [ ] Old pods terminated (after grace period)
- - [ ] Deployment documented in changelog
- ```
+ ## Mode
+ - Primary mode:
+ - Why this mode fits:
- ## Constraints
+ ## Target and artifact
+ - Runtime/provider:
+ - Environment(s):
+ - Artifact/build source:
+ - Promotion model:
- ### Required Rules (MUST)
+ ## Preconditions
+ - Build/test status:
+ - Required config/auth already present:
+ - Blocking risks:
- 1. **Health Checks**: Health check endpoint for all services
- ```typescript
- app.get('/health', (req, res) => {
- res.status(200).json({ status: 'ok' });
- });
- ```
+ ## Rollout steps
+ 1. ...
+ 2. ...
+ 3. ...
- 2. **Graceful Shutdown**: Handle SIGTERM signal
- ```javascript
- process.on('SIGTERM', async () => {
- console.log('SIGTERM received, shutting down gracefully');
- await server.close();
- await db.close();
- process.exit(0);
- });
- ```
+ ## Verification
+ - Health checks:
+ - Smoke checks:
+ - Manual sign-off if needed:
- 3. **Environment Variable Separation**: No hardcoding; use .env files
+ ## Rollback
+ - Immediate rollback path:
+ - Data/schema caveats:
- ### Prohibited Rules (MUST NOT)
+ ## Handoffs
+ - Route to neighboring skills:
+ - Remaining risks:
+ ```
- 1. **No Committing Secrets**: Never commit API keys or passwords to Git
- 2. **No Debug Mode in Production**: `NODE_ENV=production` is required
- 3. **Avoid latest tag only**: Use version tags (v1.0.0, sha-abc123)
+ ### Step 9: Prefer hardening over platform sprawl
+ When modernizing an existing deploy flow:
+ - add missing preflight and verification before switching platforms
+ - simplify environment naming and promotion order before adding more tools
+ - make rollback explicit before adding progressive-delivery buzzwords
+ - keep provider-specific steps in support docs or neighboring skills, not the core description
+ - preserve transferable logic that works across frontend, backend, and fullstack release flows
- ## Best practices
+ ## Output format
+ Always return a **deployment automation packet**, **rollout hardening brief**, or **rollback response packet**.
- 1. **Multi-stage Docker builds**: Minimize image size
- 2. **Immutable infrastructure**: Redeploy instead of modifying servers
- 3. **Blue-Green deployment**: Zero-downtime deployment and easy rollback
- 4. **Monitoring required**: Prometheus, Grafana, Datadog
+ Required qualities:
+ - classify the deployment job before prescribing tools
+ - name the runtime/provider and environment model explicitly
+ - separate build, promotion, verification, and rollback
+ - call out route-outs and scope boundaries
+ - identify whether the same artifact is promoted or rebuilt per environment
+ - treat verification and rollback as first-class, not optional notes
- ## References
+ ## Examples
- - [Docker Docs](https://docs.docker.com/)
- - [Kubernetes Docs](https://kubernetes.io/docs/)
- - [GitHub Actions](https://docs.github.com/en/actions)
- - [Vercel](https://vercel.com/docs)
- - [12 Factor App](https://12factor.net/)
+ ### Example 1: Staging to production promotion
+ **Input**
+ > We can already deploy to staging, but production releases are still a manual checklist in Slack. What should we automate first?
- ## Metadata
+ **Good output direction**
+ - mode: `environment-promotion`
+ - keep existing build artifact, add explicit preflight and post-deploy verification
+ - require approval + production health checks
+ - name rollback path and data caveats
+ - route workflow-YAML refactors to `workflow-automation`
- ### Version
- - **Current Version**: 1.0.0
- - **Last Updated**: 2025-01-01
- - **Compatible Platforms**: Claude, ChatGPT, Gemini
+ ### Example 2: Preview env confusion
+ **Input**
+ > Every PR creates a preview site, but no one knows what to verify before merge.
- ### Related Skills
- - [monitoring](../monitoring/SKILL.md): Post-deployment monitoring
- - [security](../security/SKILL.md): Deployment security
+ **Good output direction**
+ - mode: `preview-release`
+ - define what preview proves and what still requires staging/prod verification
+ - add a reviewer checklist and discard/promotion rule
+ - route provider-specific details to `vercel-deploy` or the relevant platform skill
- ### Tags
- `#deployment` `#CI/CD` `#Docker` `#Kubernetes` `#automation` `#infrastructure`
+ ### Example 3: Failed production rollout
+ **Input**
+ > The new release is timing out in production. We need the safest rollback plan.
- ## Examples
+ **Good output direction**
+ - mode: `rollback-response`
+ - identify failure signal and blast radius
+ - contain first, then restore last known good version or traffic path
+ - separate app rollback from data/schema recovery
+ - include post-recovery verification and hardening follow-up
- ### Example 1: Basic usage
- <!-- Add example content here -->
+ ## Best practices
+ 1. Prefer release-execution clarity over giant provider-specific command dumps.
+ 2. Keep deployment, promotion, verification, and rollback as separate named stages.
+ 3. Avoid pretending every team needs canary/progressive delivery; match strategy to verification maturity.
+ 4. Treat stateful changes, migrations, and schema compatibility as explicit risk multipliers.
+ 5. Route setup, CI authoring, monitoring architecture, and security governance outward instead of bloating this skill.
- ### Example 2: Advanced usage
- <!-- Add advanced example content here -->
+ ## References
+ - [references/deployment-modes-and-boundaries.md](references/deployment-modes-and-boundaries.md)
+ - [references/rollout-and-rollback-checklist.md](references/rollout-and-rollback-checklist.md)
+ - [references/platform-routing-notes.md](references/platform-routing-notes.md)