Claude-skill-registry deploy-production
Deploy to production environments with safety checks. Use when releasing code to production. Not for staging deploys or local builds unless specifically requested.
git clone https://github.com/majiayu000/claude-skill-registry
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/deploy-production" ~/.claude/skills/majiayu000-claude-skill-registry-deploy-production && rm -rf "$T"
skills/data/deploy-production/SKILL.mdDeploy to Production
<mission_control> <objective>Deploy application to production with comprehensive safety checks and emergency rollback capability</objective> <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"> <purpose>Prevent deployment if ANY check fails. These are non-negotiable requirements.</purpose>
<checks> - <check id="tests_pass"> <command>npm test</command> <expected>Exit code 0, all tests pass</expected> <failure_mode>BLOCK deployment</failure_mode> </check>- <check id="code_review"> <requirement>Recent commits reviewed and approved</requirement> <verification>Check PR approval status in git log</verification> <failure_mode>BLOCK deployment</failure_mode> </check>
- <check id="migrations_tested"> <requirement>Database migrations tested in staging</requirement> <verification>Run migrations on staging database</verification> <failure_mode>BLOCK deployment</failure_mode> </check>
- <check id="backups_current"> <requirement>Backups current and tested (within 24h)</requirement> <verification>Check backup timestamp and restore test log</verification> <failure_mode>BLOCK deployment</failure_mode> </check>
- <check id="deployment_plan"> <requirement>Deployment plan documented in runbook</requirement> <verification>Review docs/deployments/YYYY-MM-DD-plan.md</verification> <failure_mode>BLOCK deployment</failure_mode> </check>
- <check id="rollback_ready"> <requirement>Rollback procedure prepared and tested</requirement> <verification>Confirm rollback script exists and was tested</verification> <failure_mode>BLOCK deployment</failure_mode> </check>
- <check id="monitoring_configured"> <requirement>Monitoring and alerting configured for new deployment</requirement> <verification>Verify alerts exist in monitoring system</verification> <failure_mode>BLOCK deployment</failure_mode> </check>
- <check id="team_notified"> <requirement>Team notified of deployment window</requirement> <verification>Check deployment calendar or Slack announcement</verification> <failure_mode>BLOCK deployment</failure_mode> </check> </checks>
<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> <purpose>Emergency rollback when deployment fails or health checks fail</purpose> <trigger_conditions>
- <condition>Health checks fail after 5 minutes</condition>
- <condition>Error rate exceeds 5% for 2 minutes</condition>
- <condition>Manual abort triggered</condition>
- <condition>Database migration failures</condition> </trigger_conditions>
Integration
This skill integrates with:
- CI/CD pipeline integrationci-pipeline-manager
- Deployment best practicesbackend-patterns
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