# Agentes e skills para DevOps, CI/CD e infraestrutura

Componentes para empacotar, publicar e manter software a correr em produção.

O código funciona na máquina de quem o escreveu e o problema começa logo a seguir. O Dockerfile cresceu sem ninguém o rever, o ficheiro de workflow foi copiado de outro projeto e já ninguém explica metade das linhas, publicar continua a ser um ritual manual à sexta-feira e, quando alguma coisa falha em produção, os logs estão espalhados por três sítios diferentes. É este trabalho que separa uma aplicação que existe de uma aplicação que se mantém a funcionar.

Os componentes desta página atacam essa parte concreta. Há agentes que leem o repositório e escrevem o pipeline, skills que explicam como reduzir o tamanho de uma imagem ou quando reverter uma publicação, comandos que montam monitorização de uma vez, conetores MCP que ligam o Claude Code ao registo do Terraform e aos painéis do Grafana, e uma automação que vigia o estado dos deployments. O efeito prático é menos configuração escrita de memória e mais decisões verificadas.

Escolha pelo problema que tem hoje e não pela lista toda. Quem ainda publica à mão ganha mais com um gerador de workflows e com regras de deployment seguro. Quem já tem infraestrutura descrita em código ganha mais com revisão antes do apply. Quem já passou uma noite a apagar fogos ganha mais com observabilidade e SLOs. Quatro a seis componentes bem escolhidos chegam para cobrir um projeto inteiro.


## Pipelines de CI/CD e entrega contínua

Tudo o que acontece entre o commit e a versão pronta a publicar: workflows, testes automáticos, ambientes e a decisão de quando avançar.

- **senior-devops** (Skills): Bom ponto de partida quando ainda não existe nada montado, porque cobre num só conjunto de instruções pipelines, automação de infraestrutura, contentorização e plataformas cloud (AWS, GCP, Azure). [ficha](https://doutorai.pt/componentes/skills__senior-devops)
- **deployment-engineer** (Agentes): Para equipas que já libertam versões mas com demasiada fricção no processo, este agente desenha e otimiza pipelines de CI/CD e estratégias de automatização do deployment. [ficha](https://doutorai.pt/componentes/agents__deployment-engineer)
- **github-actions-creator** (Skills): Gera workflows do GitHub Actions a partir da descrição do que precisa: testes, linting, análise de segurança, builds de Docker, automação de lançamentos e tarefas agendadas. [ficha](https://doutorai.pt/componentes/skills__github-actions-creator)
- **ci-pipeline** (Comandos): Útil quando o pipeline já existe e o que falta é mantê-lo, com suporte multi-ambiente, estratégias de deployment e leitura do estado das execuções recentes. [ficha](https://doutorai.pt/componentes/commands__ci-pipeline)
- **se-gitops-ci-specialist** (Agentes): Vocacionado para fluxos GitOps e para depurar deployments falhados, com um objetivo declarado que resume bem a intenção: tornar cada publicação aborrecida e fiável. [ficha](https://doutorai.pt/componentes/agents__se-gitops-ci-specialist)
- **deployment-procedures** (Skills): Ensina critérios de decisão em vez de scripts para copiar, incluindo verificação e estratégias de rollback. Ajuda quando cada pessoa da equipa publica de maneira diferente. [ficha](https://doutorai.pt/componentes/skills__deployment-procedures)

## Contentores e orquestração

Empacotar a aplicação e fazê-la correr de forma repetível, do Dockerfile até ao cluster.

- **docker-expert** (Skills): Trata builds multi-stage, otimização e segurança de imagens e orquestração com Docker Compose, ou seja, a origem habitual das queixas sobre imagens pesadas e builds lentos. [ficha](https://doutorai.pt/componentes/skills__docker-expert)
- **kubernetes-specialist** (Agentes): Faz sentido quando o projeto já passou para Kubernetes e é preciso desenhar, configurar ou diagnosticar clusters e workloads em ambiente de produção. [ficha](https://doutorai.pt/componentes/agents__kubernetes-specialist)
- **platform-sre-kubernetes** (Agentes): A escolha para quem publica com receio: prioriza rollouts e rollbacks seguros, predefinições de segurança e verificação operacional depois de cada alteração. [ficha](https://doutorai.pt/componentes/agents__platform-sre-kubernetes)
- **helm-chart-scaffolding** (Skills): Quando a mesma aplicação corre em vários ambientes, orienta a criação e a organização de Helm charts com templates reutilizáveis em vez de manifestos duplicados. [ficha](https://doutorai.pt/componentes/skills__helm-chart-scaffolding)

## Infraestrutura como código e cloud

Descrever servidores, redes e serviços geridos em ficheiros versionados, e decidir a arquitetura que está por trás disso.

- **terraform-specialist** (Agentes): Cobre as partes de Terraform onde as coisas costumam correr mal: módulos, gestão de estado, configuração de providers, workspaces e deteção de drift. [ficha](https://doutorai.pt/componentes/agents__terraform-specialist)
- **terraform-iac-reviewer** (Agentes): Serve para rever alterações antes do apply, com atenção à segurança do estado, privilégio mínimo e disciplina de plan/apply. Combina com o agente anterior num fluxo de dois passos. [ficha](https://doutorai.pt/componentes/agents__terraform-iac-reviewer)
- **terraform** (Conetores): Conetor que liga a assistência às APIs do Terraform Registry, o que evita escrever de memória nomes e versões de providers e módulos. [ficha](https://doutorai.pt/componentes/mcps__terraform)
- **cloud-architect** (Agentes): Para as decisões que ficam acima do ficheiro de configuração: estratégias multi-cloud, planeamento de migrações, recuperação de desastre e otimização de custos. [ficha](https://doutorai.pt/componentes/agents__cloud-architect)
- **vercel-deployment-specialist** (Agentes): Se o projeto vive na Vercel, cobre configuração da plataforma, edge functions, middleware e as estratégias de publicação próprias desse ambiente. [ficha](https://doutorai.pt/componentes/agents__vercel-deployment-specialist)

## Produção: publicar, observar e responder a incidentes

O que precisa depois do deploy: lançamentos sem interrupção, métricas e alertas, e um método para as horas em que alguma coisa falha.

- **blue-green-deployment** (Comandos): Monta a comutação entre duas versões com validação de saúde e rollback automático, indicado para serviços que não podem aceitar janelas de indisponibilidade. [ficha](https://doutorai.pt/componentes/commands__blue-green-deployment)
- **monitoring-specialist** (Agentes): Trata a monitorização como infraestrutura: recolha de métricas, agregação de logs, distributed tracing, sistemas de alerta e painéis de desempenho. [ficha](https://doutorai.pt/componentes/agents__monitoring-specialist)
- **setup-monitoring-observability** (Comandos): Bom arranque para projetos sem nada instalado, porque deteta o que já existe no repositório e configura métricas, logs, tracing e alertas de uma vez. [ficha](https://doutorai.pt/componentes/commands__setup-monitoring-observability)
- **grafana** (Conetores): Liga o Claude Code aos painéis e à monitorização do Grafana, em instância própria ou no Grafana Cloud, para consultar o estado sem trocar de ferramenta. [ficha](https://doutorai.pt/componentes/mcps__grafana)
- **devops-troubleshooter** (Agentes): Pensado para o momento em que produção falha: análise de logs, investigação de falhas de deployment e análise de causa raiz. [ficha](https://doutorai.pt/componentes/agents__devops-troubleshooter)
- **sre-engineer** (Agentes): Quando o problema deixa de ser um incidente isolado e passa a ser falta de objetivos, ajuda a definir SLIs e SLOs, gerir orçamentos de erro e reduzir trabalho manual repetitivo. [ficha](https://doutorai.pt/componentes/agents__sre-engineer)
- **deployment-health-monitor** (Automações): Automação que reage aos comandos de deploy e vigia o estado das publicações na Vercel, avisando em caso de falha de build ou degradação de desempenho. [ficha](https://doutorai.pt/componentes/hooks__deployment-health-monitor)

## Onde instalar cada tipo de componente

Cada categoria vive num sítio próprio. Agentes e skills são ficheiros markdown em .claude/agents/ e .claude/skills/, dentro do repositório ou na pasta pessoal ~/.claude. Comandos ficam em .claude/commands/ e são invocados com uma barra e o nome, por exemplo /ci-pipeline. Conetores MCP, como o do Terraform e o do Grafana, são entradas de configuração com o comando a executar e as variáveis de ambiente, incluindo URL e token de acesso. Automações são blocos de hooks nas definições, ligados a eventos de utilização de ferramentas. Para trabalho de equipa, vale a pena instalar ao nível do projeto, para que a configuração acompanhe o repositório, e manter as credenciais fora dos ficheiros versionados.

## Combinar as peças num fluxo único

Uma sequência que funciona na prática: a skill de Docker prepara a imagem, o gerador de GitHub Actions escreve o workflow que a constrói e testa, o especialista de Terraform descreve a infraestrutura e o revisor de IaC valida o plano antes do apply, o comando de blue-green trata da troca de versão sem indisponibilidade e a configuração de observabilidade instala métricas e alertas. Quando um alerta dispara, o agente de troubleshooting entra para análise de logs e causa raiz, e o agente de SRE fecha o ciclo, transformando o incidente em SLOs e em menos trabalho manual. Comece por dois ou três passos desta cadeia e acrescente conforme a necessidade real.

## Limites e cuidados antes de tocar em produção

Estes componentes escrevem configuração e sugerem comandos, mas não substituem revisão humana. Leia o YAML e o HCL gerados antes de os aplicar, corra sempre o plan do Terraform e confirme o que vai ser destruído, e faça o primeiro teste num ambiente de staging. Os conetores MCP pedem tokens: crie contas de serviço com as permissões mínimas e guarde os valores em variáveis de ambiente, nunca no ficheiro de configuração. As automações executam comandos por si, por isso perceba exatamente o que disparam antes de as ativar. E mantenha o princípio simples de sempre: publique cedo no dia, com alguém disponível para reverter.

## Perguntas frequentes

### Preciso de saber Kubernetes para aproveitar esta página?

Não. Boa parte das escolhas serve projetos que correm num servidor único ou numa plataforma gerida: a skill de Docker, o gerador de GitHub Actions, as regras de deployment seguro e a configuração de observabilidade não dependem de cluster nenhum. Os componentes de Kubernetes e de Helm só compensam quando o projeto já usa orquestração, caso contrário acrescentam complexidade sem retorno.

### Qual é a diferença entre agente, skill, comando, conetor e automação?

Um agente é um especialista que assume uma tarefa com as suas próprias ferramentas e devolve o trabalho feito. Uma skill é conhecimento e método que entram em contexto quando o assunto aparece. Um comando é um atalho que executa com uma barra e o nome. Um conetor MCP liga o Claude Code a uma ferramenta externa, como o Grafana. Uma automação dispara sozinha em eventos do fluxo de trabalho.

### Estes componentes fazem deploy sozinhos?

Escrevem configuração e propõem comandos, e executam apenas o que o utilizador autorizar. A automação de monitorização de deployments é a exceção parcial, porque reage a comandos de publicação para verificar o estado logo a seguir. Para operações destrutivas, mantenha a confirmação manual ativa e trate qualquer apply de infraestrutura como uma alteração que exige leitura prévia.

### Vale a pena para um projeto pequeno, com um só servidor?

Vale, desde que escolha pouco. Uma combinação razoável é a skill de Docker para a imagem, o gerador de workflows para automatizar testes e publicação, as regras de deployment para saber quando reverter e o comando de observabilidade para ter alertas básicos. Terraform, Helm e Kubernetes podem esperar até existir mais do que um ambiente para gerir.

### Como evito sobreposição entre componentes parecidos?

Instale um componente por problema. A skill generalista de DevOps e o agente de deployment cobrem território comum, por isso escolha um dos dois consoante queira orientação ampla ou trabalho focado em pipelines. Já o especialista de Terraform e o revisor de IaC são complementares: um escreve, o outro verifica antes do apply. Se dois componentes derem instruções contraditórias, remova o menos usado.


Fonte: https://doutorai.pt/para/devops-e-deploy - Doutor AI, selecao feita a mao da biblioteca tecnica.