# Agents and skills for DevOps, CI/CD and infrastructure

> Components to package, ship and keep software running in production.

- Source: https://doutorai.pt/en/for/devops-and-deployment
- Site: Doutor AI (https://doutorai.pt/en) - AI tools for small businesses

The code works on the machine of whoever wrote it, and the trouble starts right after that. The Dockerfile grew without anyone reviewing it, the workflow file was copied from another project and nobody can explain half its lines anymore, shipping is still a manual Friday ritual and, when something breaks in production, the logs are scattered across three different places. This is the work that separates an application that exists from an application that keeps running.

The components on this page tackle that specific part. There are agents that read the repository and write the pipeline, skills that explain how to shrink an image or when to roll back a release, commands that set up monitoring in one go, MCP connectors that link Claude Code to the Terraform registry and to Grafana dashboards, and an automation that watches the status of deployments. The practical effect is less configuration written from memory and more verified decisions.

Choose by the problem you have today, not the whole list. If you still deploy by hand, you gain most from a workflow generator and safe deployment rules. If your infrastructure is already described in code, you gain most from a review before the apply. If you have already spent a night fighting fires, you gain most from observability and SLOs. Four to six well-chosen components are enough to cover a whole project.

22 hand-picked components, from 4 different angles.

## CI/CD pipelines and continuous delivery

Everything that happens between the commit and the version ready to ship: workflows, automated tests, environments and the decision about when to go ahead.

- **senior-devops** (Skills): A good starting point when nothing is set up yet, because it covers pipelines, infrastructure automation, containerization and cloud platforms (AWS, GCP, Azure) in a single set of instructions. [page](https://doutorai.pt/en/components/skills__senior-devops)
- **deployment-engineer** (Agents): For teams that already ship releases but with too much friction in the process, this agent designs and optimizes CI/CD pipelines and deployment automation strategies. [page](https://doutorai.pt/en/components/agents__deployment-engineer)
- **github-actions-creator** (Skills): Generates GitHub Actions workflows from a description of what you need: tests, linting, security analysis, Docker builds, release automation and scheduled jobs. [page](https://doutorai.pt/en/components/skills__github-actions-creator)
- **ci-pipeline** (Commands): Useful when the pipeline already exists and what is missing is maintaining it, with multi-environment support, deployment strategies and a readout of the status of recent runs. [page](https://doutorai.pt/en/components/commands__ci-pipeline)
- **se-gitops-ci-specialist** (Agents): Built for GitOps workflows and for debugging failed deployments, with a stated goal that sums up the intent well: make every release boring and reliable. [page](https://doutorai.pt/en/components/agents__se-gitops-ci-specialist)
- **deployment-procedures** (Skills): Teaches decision criteria instead of scripts to copy, including verification and rollback strategies. It helps when everyone on the team ships in a different way. [page](https://doutorai.pt/en/components/skills__deployment-procedures)

## Containers and orchestration

Packaging the application and running it repeatably, from the Dockerfile to the cluster.

- **docker-expert** (Skills): Handles multi-stage builds, image optimization and security, and orchestration with Docker Compose, in other words the usual source of complaints about heavy images and slow builds. [page](https://doutorai.pt/en/components/skills__docker-expert)
- **kubernetes-specialist** (Agents): Makes sense when the project has already moved to Kubernetes and you need to design, configure or troubleshoot clusters and workloads in a production environment. [page](https://doutorai.pt/en/components/agents__kubernetes-specialist)
- **platform-sre-kubernetes** (Agents): The choice for anyone who ships nervously: it prioritizes safe rollouts and rollbacks, secure defaults and operational verification after every change. [page](https://doutorai.pt/en/components/agents__platform-sre-kubernetes)
- **helm-chart-scaffolding** (Skills): When the same application runs in several environments, it guides the creation and organization of Helm charts with reusable templates instead of duplicated manifests. [page](https://doutorai.pt/en/components/skills__helm-chart-scaffolding)

## Infrastructure as code and cloud

Describing servers, networks and managed services in versioned files, and deciding the architecture behind them.

- **terraform-specialist** (Agents): Covers the parts of Terraform where things usually go wrong: modules, state management, provider configuration, workspaces and drift detection. [page](https://doutorai.pt/en/components/agents__terraform-specialist)
- **terraform-iac-reviewer** (Agents): Useful for reviewing changes before the apply, with attention to state security, least privilege and plan/apply discipline. It pairs with the previous agent in a two-step flow. [page](https://doutorai.pt/en/components/agents__terraform-iac-reviewer)
- **terraform** (Connectors): A connector that links the assistant to the Terraform Registry APIs, which saves you writing provider and module names and versions from memory. [page](https://doutorai.pt/en/components/mcps__terraform)
- **cloud-architect** (Agents): For the decisions that sit above the configuration file: multi-cloud strategies, migration planning, disaster recovery and cost optimization. [page](https://doutorai.pt/en/components/agents__cloud-architect)
- **vercel-deployment-specialist** (Agents): If the project lives on Vercel, it covers platform configuration, edge functions, middleware and the deployment strategies specific to that environment. [page](https://doutorai.pt/en/components/agents__vercel-deployment-specialist)

## Production: ship, observe and respond to incidents

What you need after the deploy: releases without downtime, metrics and alerts, and a method for the hours when something breaks.

- **blue-green-deployment** (Commands): Sets up switching between two versions with health checks and automatic rollback, a good fit for services that cannot accept downtime windows. [page](https://doutorai.pt/en/components/commands__blue-green-deployment)
- **monitoring-specialist** (Agents): Treats monitoring as infrastructure: metrics collection, log aggregation, distributed tracing, alerting systems and performance dashboards. [page](https://doutorai.pt/en/components/agents__monitoring-specialist)
- **setup-monitoring-observability** (Commands): A good start for projects with nothing installed, because it detects what already exists in the repository and configures metrics, logs, tracing and alerts in one go. [page](https://doutorai.pt/en/components/commands__setup-monitoring-observability)
- **grafana** (Connectors): Connects Claude Code to Grafana dashboards and monitoring, on your own instance or on Grafana Cloud, so you can check status without switching tools. [page](https://doutorai.pt/en/components/mcps__grafana)
- **devops-troubleshooter** (Agents): Designed for the moment production breaks: log analysis, investigation of deployment failures and root cause analysis. [page](https://doutorai.pt/en/components/agents__devops-troubleshooter)
- **sre-engineer** (Agents): When the problem is no longer an isolated incident but a lack of objectives, it helps define SLIs and SLOs, manage error budgets and reduce repetitive manual work. [page](https://doutorai.pt/en/components/agents__sre-engineer)
- **deployment-health-monitor** (Automations): An automation that reacts to deploy commands and watches the status of releases on Vercel, warning you about build failures or performance degradation. [page](https://doutorai.pt/en/components/hooks__deployment-health-monitor)

## Where to install each type of component

Each category lives in its own place. Agents and skills are markdown files in .claude/agents/ and .claude/skills/, inside the repository or in the personal ~/.claude folder. Commands go in .claude/commands/ and are invoked with a slash and the name, for example /ci-pipeline. MCP connectors, such as the Terraform and Grafana ones, are configuration entries with the command to run and the environment variables, including the URL and access token. Automations are hook blocks in the settings, tied to tool use events. For team work, it is worth installing at project level, so the configuration travels with the repository, and keeping credentials out of versioned files.

## Combining the pieces into a single flow

A sequence that works in practice: the Docker skill prepares the image, the GitHub Actions generator writes the workflow that builds and tests it, the Terraform specialist describes the infrastructure and the IaC reviewer validates the plan before the apply, the blue-green command handles the version switch without downtime and the observability setup installs metrics and alerts. When an alert fires, the troubleshooting agent steps in for log and root cause analysis, and the SRE agent closes the loop, turning the incident into SLOs and less manual work. Start with two or three steps of this chain and add more as real needs arise.

## Limits and precautions before touching production

These components write configuration and suggest commands, but they do not replace human review. Read the generated YAML and HCL before applying them, always run the Terraform plan and confirm what will be destroyed, and do the first test in a staging environment. MCP connectors ask for tokens: create service accounts with minimal permissions and store the values in environment variables, never in the configuration file. Automations run commands on their own, so understand exactly what they trigger before you turn them on. And keep the same simple principle as always: ship early in the day, with someone available to roll back.

## Keep reading

- [Setup CI/CD Pipeline](https://doutorai.pt/en/how-to/slash-commands--setup-ci-cd)
- [Pull Request Preparation Checklist](https://doutorai.pt/en/how-to/slash-commands--pr)

## Frequently asked questions

### Do I need to know Kubernetes to get value from this page?

No. Many of the picks suit projects that run on a single server or on a managed platform: the Docker skill, the GitHub Actions generator, the safe deployment rules and the observability setup do not depend on any cluster. The Kubernetes and Helm components only pay off when the project already uses orchestration; otherwise they add complexity with no return.

### What is the difference between an agent, a skill, a command, a connector and an automation?

An agent is a specialist that takes on a task with its own tools and returns the finished work. A skill is knowledge and method that come into context when the subject comes up. A command is a shortcut you run with a slash and the name. An MCP connector links Claude Code to an external tool, such as Grafana. An automation fires on its own on workflow events.

### Do these components deploy on their own?

They write configuration and propose commands, and they only run what the user authorizes. The deployment monitoring automation is a partial exception, because it reacts to release commands to check the status right afterwards. For destructive operations, keep manual confirmation on and treat any infrastructure apply as a change that must be read first.

### Is it worth it for a small project with a single server?

It is, as long as you choose sparingly. A reasonable combination is the Docker skill for the image, the workflow generator to automate testing and releases, the deployment rules to know when to roll back and the observability command to get basic alerts. Terraform, Helm and Kubernetes can wait until there is more than one environment to manage.

### How do I avoid overlap between similar components?

Install one component per problem. The generalist DevOps skill and the deployment agent cover common ground, so choose one of the two depending on whether you want broad guidance or work focused on pipelines. The Terraform specialist and the IaC reviewer, on the other hand, are complementary: one writes, the other checks before the apply. If two components give contradictory instructions, remove the one you use less.

---
Content by Doutor AI (https://doutorai.pt/en). When quoting, please cite the source: https://doutorai.pt/en/for/devops-and-deployment