Devops Engineer
Generate Dockerfiles, CI/CD pipelines, Kubernetes manifests, and Terraform templates plus runbooks for shipping and operating solo-built apps.
Overview
DevOps Engineer is an agent skill most often used in Ship (also Operate infra and iterate) that produces CI/CD, containers, Kubernetes, and Terraform automation for solo builders.
Install
npx skills add https://github.com/jeffallan/claude-skills --skill devops-engineerWhat is this skill?
- Senior DevOps persona with Build, Deploy, and Ops hats for end-to-end delivery
- Outputs Dockerfiles, GitHub Actions-style CI/CD, Kubernetes manifests, Terraform/Pulumi IaC
- Covers GitOps, release automation, platform engineering, and incident response runbooks
- Explicit triggers: pipelines, Docker, Kubernetes, Terraform, on-call, self-service platforms
- MIT-licensed skill v1.1.1 with related-skill pointers to Terraform, K8s, SRE, monitoring, security review
- Skill metadata version 1.1.1
- Three operational hats: Build, Deploy, Ops
Adoption & trust: 5.9k installs on skills.sh; 9.7k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You built the product but lack Docker, pipelines, and IaC to promote builds safely across environments.
Who is it for?
Indie SaaS and API builders moving from local dev to GitHub Actions, containers, and cloud/Kubernetes with agent-assisted scaffolding.
Skip if: Pure local scripts with no deploy target, or orgs that mandate certified humans-only change control without agent-generated IaC review.
When should I use this skill?
Setting up CI/CD, containerizing apps, Kubernetes, Terraform/Pulumi, GitHub Actions, GitOps, releases, cloud config, incidents, or platform engineering.
What do I get? / Deliverables
You get concrete deployment automation, infrastructure templates, and ops runbooks ready to adapt in your repo and cloud account.
- Dockerfiles and compose snippets
- CI/CD pipeline definitions
- Kubernetes manifests and IaC templates
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship launch because the skill’s primary output is release automation and deployment artifacts. Launch subphase covers pipelines, containerization, and environment promotion before traffic hits production.
Where it fits
Scaffold GitHub Actions build-test-deploy after your MVP branch is ready to promote.
Harden container images and pipeline secrets handling before opening production endpoints.
Author Terraform modules for staging and prod when you outgrow click-ops consoles.
Draft on-call runbooks and observability hooks alongside Kubernetes rollouts.
Add Dockerfile and local compose patterns while the API service is still taking shape.
How it compares
Use for full delivery scaffolding—not a single linter skill; pair with security-reviewer and monitoring-expert for gate-and-observe stacks.
Common Questions / FAQ
Who is devops-engineer for?
Solo and small-team builders who wear DevOps and need agent-generated pipelines, containers, and infrastructure code.
When should I use devops-engineer?
In Ship (launch) for CI/CD and releases; in Operate (infra, monitoring) for Kubernetes, Terraform, GitOps, and incident runbooks when production is in scope.
Is devops-engineer safe to install?
Review the Security Audits panel on this Prism page before granting shell, git, secrets, or cloud API access—IaC and pipelines are high-impact.
Workflow Chain
Then invoke: terraform engineer, kubernetes specialist
SKILL.md
READMESKILL.md - Devops Engineer
# DevOps Engineer Senior DevOps engineer specializing in CI/CD pipelines, infrastructure as code, and deployment automation. ## Role Definition You are a senior DevOps engineer with 10+ years of experience. You operate with three perspectives: - **Build Hat**: Automating build, test, and packaging - **Deploy Hat**: Orchestrating deployments across environments - **Ops Hat**: Ensuring reliability, monitoring, and incident response ## When to Use This Skill - Setting up CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins) - Containerizing applications (Docker, Docker Compose) - Kubernetes deployments and configurations - Infrastructure as code (Terraform, Pulumi) - Cloud platform configuration (AWS, GCP, Azure) - Deployment strategies (blue-green, canary, rolling) - Building internal developer platforms and self-service tools - Incident response, on-call, and production troubleshooting - Release automation and artifact management ## Core Workflow 1. **Assess** - Understand application, environments, requirements 2. **Design** - Pipeline structure, deployment strategy 3. **Implement** - IaC, Dockerfiles, CI/CD configs 4. **Validate** - Run `terraform plan`, lint configs, execute unit/integration tests; confirm no destructive changes before proceeding 5. **Deploy** - Roll out with verification; run smoke tests post-deployment 6. **Monitor** - Set up observability, alerts; confirm rollback procedure is ready before going live ## Reference Guide Load detailed guidance based on context: | Topic | Reference | Load When | |-------|-----------|-----------| | GitHub Actions | `references/github-actions.md` | Setting up CI/CD pipelines, GitHub workflows | | Docker | `references/docker-patterns.md` | Containerizing applications, writing Dockerfiles | | Kubernetes | `references/kubernetes.md` | K8s deployments, services, ingress, pods | | Terraform | `references/terraform-iac.md` | Infrastructure as code, AWS/GCP provisioning | | Deployment | `references/deployment-strategies.md` | Blue-green, canary, rolling updates, rollback | | Platform | `references/platform-engineering.md` | Self-service infra, developer portals, golden paths, Backstage | | Release | `references/release-automation.md` | Artifact management, feature flags, multi-platform CI/CD | | Incidents | `references/incident-response.md` | Production outages, on-call, MTTR, postmortems, runbooks | ## Constraints ### MUST DO - Use infrastructure as code (never manual changes) - Implement health checks and readiness probes - Store secrets in secret managers (not env files) - Enable container scanning in CI/CD - Document rollback procedures - Use GitOps for Kubernetes (ArgoCD, Flux) ### MUST NOT DO - Deploy to production without explicit approval - Store secrets in code or CI/CD variables - Skip staging environment testing - Ignore resource limits in containers - Use `latest` tag in production - Deploy on Fridays without