Skip to main content
skill CX Codex

deployment-engineer — Claude Code skill: how to install

Configures CI/CD pipelines, rollout strategies, and release monitoring. Strictly forbids production mutations without explicit user consent.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add zhaono1/agent-playbook --skill deployment-engineer -a claude-code
Open on GitHub

What deployment-engineer does

The skill directs your coding agent through delivery automation. It handles GitHub Actions workflow configuration, environment variables, and /health route generation with checks for Redis or databases. It also provides reference architectures for canary, rolling, and blue-green deployments. Supporting Python scripts like scripts/generate_deploy.py help scaffold environment-specific configs.

Safety boundaries remain strict throughout the workflow. The agent can draft configs and run read-only validation, but it cannot trigger deploys, alter release states, or push code on its own. Before running any mutation, it must state the exact environment, command, expected impact, and rollback plan. If targets or permissions are unclear, the agent stops immediately.

What it helps with

  • generate GitHub Actions workflows for multi-stage pipelines
  • configure canary and blue-green rollout strategies
  • implement structured health check endpoints with dependency status
  • define rollback procedures using Kubernetes or Docker commands

Example prompts for the agent

  • Set up a GitHub Actions workflow that runs tests, builds artifacts, and deploys to staging
  • Draft a canary deployment plan with metric verification steps
  • Write a rollback plan for our Kubernetes service if the new release fails health checks

How to install deployment-engineer

1Skills CLI (Vercel)

npx skills add zhaono1/agent-playbook --skill deployment-engineer -a claude-code

2Manually: put the files in place

~/.claude/skills/deployment-engineer/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/deployment-engineer/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about deployment-engineer

How to install deployment-engineer in Claude Code?

Run npx skills add zhaono1/agent-playbook --skill deployment-engineer -a claude-code. You can also place the file at ~/.claude/skills/deployment-engineer/SKILL.md.

What does deployment-engineer do?

It assists in setting up CI/CD workflows, designing deployment strategies, configuring environment variables, and planning rollbacks.

Can deployment-engineer push changes to production automatically?

No, its permission boundary strictly prevents pushing code or changing remote infrastructure without prior explicit confirmation. It must display the command, environment, and rollback path first.

Source text

SKILL.md · MIT
---
name: deployment-engineer
description: Deployment automation specialist for CI/CD pipelines and infrastructure. Use when setting up deployment, configuring CI/CD, or managing releases.
allowed-tools: Read, Write, Edit, Bash, Grep, Glob
metadata:
  hooks:
    after_complete:
      - trigger: session-logger
        mode: auto
        reason: "Log deployment activity"
---

# Deployment Engineer

Specialist in deployment automation, CI/CD pipelines, and infrastructure management.

## Permission Boundary

Planning, generating configuration, and running read-only validation do not authorize
deployment. Never push, deploy, roll back, change production infrastructure, or alter
remote release state without explicit user approval for that exact action and target.
Before an approved mutation, state the environment, command, expected impact,
verification signal, and rollback path. Stop if the target or authority is ambiguous.

## When This Skill Activates

Activates when you:
- Set up deployment pipeline
- Configure CI/CD
- Manage releases
- Automate infrastructure

## CI/CD Pipeline

### Pipeline Stages

```yaml
stages:
  - lint
  - test
  - build
  - security
  - deploy-dev
  - deploy-staging
  - deploy-production
```

### GitHub Actions Example

```yaml
name: CI/CD

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm run lint

  test:
    runs-on: ubuntu-latest
    needs: lint
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: npm test

  build:
    runs-on: ubuntu-latest
    needs: test
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: build
          path: dist/

  deploy-production:
    runs-on: ubuntu-latest
    needs: build
    if: github.ref == 'refs/heads/main'
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: actions/download-artifact@v4
        with:
          name: build
          path: dist/
      - run: npm run deploy
```

## Deployment Strategies

### 1. Blue-Green Deployment

```
         ┌─────────┐
         │  Load   │
         │ Balancer│
         └────┬────┘
              │
     ┌────────┴────────┐
     │    Switch       │
     ├────────┬────────┤
     ▼        ▼        ▼
  ┌─────┐ ┌─────┐ ┌─────┐
  │Blue │ │Green│ │     │
  └─────┘ └─────┘ └─────┘
```

### 2. Rolling Deployment

```
┌─────────────────────────────────────┐
│ v1  v1  v1  v1  v1  v1  v1  v1  v1 │ → Old
│ v2  v2  v2  v2  v2  v2  v2  v2  v2 │ → New
└─────────────────────────────────────┘
    ▲                       ▲
    │                       │
  Start                  End
```

### 3. Canary Deployment

```
┌──────────────────────────────────────┐
│ v1  v1  v1  v1  v1  v1  v1  v1  v1  v1 │ → Old
│ v2  v2  v2  v2                        │ → Canary (5%)
└──────────────────────────────────────┘

Monitor metrics, then:
│ v1  v1  v1  v1                        │ → Old (50%)
│ v2  v2  v2  v2  v2  v2  v2  v2  v2  v2 │ → New (50%)
```

## Environment Configuration

### Environment Variables

```bash
# Production
NODE_ENV=production
DATABASE_URL=postgresql://...
API_KEY=${API_KEY}
SENTRY_DSN=https://example.com/123

# Development
NODE_ENV=development
DATABASE_URL=postgresql://localhost:5432/dev
```

### Configuration Management

```typescript
// config/production.ts
export default {
  database: {
    url: process.env.DATABASE_URL,
    poolSize: 20,
  },
  redis: {
    url: process.env.REDIS_URL,
  },
};
```

## Health Checks

```typescript
// GET /health
app.get('/health', (req, res) => {
  const health = {
    status: 'ok',
    timestamp: new Date().toISOString(),
    checks: {
      database: 'ok',
      redis: 'ok',
      external_api: 'ok',
    },
  };

  if (Object.values(health.checks).some(v => v !== 'ok')) {
    health.status = 'degraded';
    return res.status(503).json(health);
  }

  res.json(health);
});
```

## Rollback Strategy

```bash
# Kubernetes
kubectl rollout undo deployment/app

# Docker
docker-compose down
docker-compose up -d --scale app=<previous-version>

# Git
git revert HEAD
git push
```

## Monitoring & Logging

### Metrics to Track

- Deployment frequency
- Lead time for changes
- Mean time to recovery (MTTR)
- Change failure rate

### Logging

```typescript
// Structured logging
logger.info('Deployment started', {
  version: process.env.VERSION,
  environment: process.env.NODE_ENV,
  timestamp: new Date().toISOString(),
});
```

## Scripts

Generate deployment config:
```bash
python3 scripts/generate_deploy.py --env <environment> --name <service-name>
```

Validate deployment:
```bash
python3 scripts/validate_deploy.py --input deploy-plan.md
```

## References

- `references/pipelines.md` - CI/CD pipeline examples
- `references/kubernetes.md` - K8s deployment configs
- `references/monitoring.md` - Monitoring setup

© zhaono1 · MIT · zhaono1/agent-playbook

Similar skills

All skills for DevOps and infrastructure →

From the same set24

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor