deploy-production

name	deploy-production
description	Deploy to production environments with safety checks. Use when releasing code to production. Not for staging deploys or local builds unless specifically requested.
disable-model-invocation	true
user-invocable	true
context	fork
agent	Plan
allowed-tools	Read, Bash(docker:*), Bash(kubectl:*)

Deploy to Production

<mission_control> Deploy application to production with comprehensive safety checks and emergency rollback capability <success_criteria>Deployment succeeds with zero downtime, all health checks pass, rollback procedure documented and tested</success_criteria> </mission_control>

<safety_gate type="blocking" phase="pre_deployment"> Prevent deployment if ANY check fails. These are non-negotiable requirements.

- npm test Exit code 0, all tests pass BLOCK deployment

• Recent commits reviewed and approved Check PR approval status in git log BLOCK deployment
• Database migrations tested in staging Run migrations on staging database BLOCK deployment
• Backups current and tested (within 24h) Check backup timestamp and restore test log BLOCK deployment
• Deployment plan documented in runbook Review docs/deployments/YYYY-MM-DD-plan.md BLOCK deployment
• Rollback procedure prepared and tested Confirm rollback script exists and was tested BLOCK deployment
• Monitoring and alerting configured for new deployment Verify alerts exist in monitoring system BLOCK deployment
• Team notified of deployment window Check deployment calendar or Slack announcement BLOCK deployment

<gate_validation> MANDATORY: Run each check sequentially. If ANY check fails, STOP and resolve before continuing. DO NOT PROCEED unless ALL items are verified. </gate_validation> </safety_gate>

Deployment Process

<logic_flow> digraph Deployment { rankdir=TD; node [shape=box]; Verify [label="1. Verify Checklist"]; Build [label="2. Build & Test"]; Docker [label="3. Build Docker"]; Push [label="4. Push Registry"]; Deploy [label="5. Apply K8s"]; Check [label="6. Verify Health"]; Success [label="Deployment Success" style=filled fillcolor=lightgreen]; Rollback [label="Rollback Procedure" style=filled fillcolor=lightpink];

Verify -> Build;
Build -> Docker;
Docker -> Push;
Push -> Deploy;
Deploy -> Check;
Check -> Success [label="Health OK"];
Check -> Rollback [label="Errors"];
Rollback -> Verify [label="Fix & Retry"];

} </logic_flow>

1. Pre-Deployment Verification

Complete the checklist above and verify all systems are ready.

2. Build Application

npm run build
npm test

3. Build Docker Image

docker build -t myapp:$VERSION .
docker tag myapp:$VERSION myapp:latest

4. Push to Registry

docker push myapp:$VERSION
docker push myapp:latest

5. Deploy to Kubernetes

kubectl apply -f manifests/production/
kubectl rollout status deployment/myapp

6. Verify Deployment

• Health checks passing
• Logs show no errors
• Metrics within normal range
• Smoke tests pass

7. Post-Deployment

• Update documentation
• Notify team of successful deployment
• Monitor for 30 minutes
• Update deployment tracker

Safety Features

This skill includes:

• Manual-only invocation - Cannot be auto-triggered
• XML-defined safety gates - Blocking checks with machine-readable validation
• Emergency rollback - Automated rollback procedure in XML
• Verification steps - Ensures deployment success

Rollback Procedure

<rollback_procedure> Emergency rollback when deployment fails or health checks fail <trigger_conditions>

• Health checks fail after 5 minutes
• Error rate exceeds 5% for 2 minutes
• Manual abort triggered
• Database migration failures </trigger_conditions>

kubectl rollout undo deployment/myapp 30 seconds Rollback initiated, previous version restored kubectl rollout status deployment/myapp 120 seconds Rollback complete, deployment healthy - Check logs: `kubectl logs -f deployment/myapp --tail=100` - Review metrics: Error rates, latency, CPU/memory - Identify: What changed, why it failed - Document: Create incident report - Fix the issue in code - Test in staging environment - Update deployment plan with lessons learned - Get approval for re-deployment - Follow full deployment process again - All safety gates MUST pass - Enhanced monitoring for first hour

Integration

This skill integrates with:

• ci-pipeline-manager - CI/CD pipeline integration
• backend-patterns - Deployment best practices

---

Absolute Constraints (Non-Negotiable)

<critical_constraint> MANDATORY: ALL safety gates MUST pass before deployment

• Run each check sequentially
• If ANY check fails, STOP and resolve
• NO exceptions, NO "looks good" rationalization
• Document why gate failed and how it was fixed

MANDATORY: Rollback procedure MUST be tested before deployment

• Verify rollback script exists
• Test rollback in staging
• Confirm previous version is stable
• Document rollback success criteria

MANDATORY: Monitor deployment for 30 minutes after success

• Health checks must remain passing
• Error rates must stay below threshold
• Logs must show no errors
• Team must be available for immediate response

MANDATORY: Document ALL deployments

• Update deployment tracker
• Document any issues or deviations
• Create incident report if rollback occurred
• Share lessons learned with team

DANGER ZONE: Production deployment is irreversible without rollback

• Treat every deployment as potentially breaking
• Assume rollback will be needed (hope for best, prepare for worst)
• Never deploy Friday afternoon or before holidays
• Always have team on standby during deployment window

No exceptions. No short-cuts. Production is not a place for "good enough." </critical_constraint>

---

Genetic Code

This component carries essential Seed System principles for context: fork isolation:

<critical_constraint> MANDATORY: All components MUST be self-contained (zero .claude/rules dependency) MANDATORY: Achieve 80-95% autonomy (0-5 AskUserQuestion rounds per session) MANDATORY: Description MUST use What-When-Not format in third person MANDATORY: No component references another component by name in description MANDATORY: Progressive disclosure - references/ for detailed content MANDATORY: Use XML for control (mission_control, critical_constraint), Markdown for data No exceptions. Portability invariant must be maintained. </critical_constraint>

Delta Standard: Good Component = Expert Knowledge − What Claude Already Knows

Recognition Questions:

• "Would Claude know this without being told?" → Delete (zero delta)
• "Can this work standalone?" → Fix if no (non-self-sufficient)
• "Did I read the actual file, or just see it in grep?" → Verify before claiming

---