Skip to content
Back to skills

Deploy Production Majiayu000

ASecurity

Deploy to production environments with safety checks. Use when releasing code to production. Not for staging deploys or local builds unless specifically requested.

  • 57 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added October 17, 2026
devopsgobashnodedockerkubernetesgitdatabasebackendci/cddocumentation

Security analysis

A100/100

Scanned October 17, 2026

npx -y skills add diegosouzapw/awesome-omni-skill --skill deploy-production-majiayu000 --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Deploy Production Majiayu000?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Deploy Production Majiayu000
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/diegosouzapw-deploy-production-majiayu000/badge)](https://www.skillsdirectory.com/skills/diegosouzapw-deploy-production-majiayu000)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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>
<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

```bash
npm run build
npm test
```

### 3. Build Docker Image

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

### 4. Push to Registry

```bash
docker push myapp:$VERSION
docker push myapp:latest
```

### 5. Deploy to Kubernetes

```bash
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>

<steps sequential="true">
<step id="1" action="immediate_rollback">
<command>kubectl rollout undo deployment/myapp</command>
<timeout>30 seconds</timeout>
<expected>Rollback initiated, previous version restored</expected>
</step>

<step id="2" action="verify_rollback">
<command>kubectl rollout status deployment/myapp</command>
<timeout>120 seconds</timeout>
<expected>Rollback complete, deployment healthy</expected>
</step>

<step id="3" action="investigate_root_cause">
<investigation>
- 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
</investigation>
</step>

<step id="4" action="prepare_fix">
<actions>
- Fix the issue in code
- Test in staging environment
- Update deployment plan with lessons learned
- Get approval for re-deployment
</actions>
</step>

<step id="5" action="redeploy">
<actions>
- Follow full deployment process again
- All safety gates MUST pass
- Enhanced monitoring for first hour
</actions>
</step>
</steps>
</rollback_procedure>

## 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

---

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.