Rotinas do Claude Code: rode seu agente de código com agenda na nuvem

As três partes cumprem papéis específicos:

• Prompt. A parte mais importante, porque a rotina roda sem sua aprovação a cada etapa. O prompt precisa carregar a tarefa inteira e a definição do que é "pronto".
• Repositórios. O Claude clona esses repositórios no início de cada execução e trabalha dentro deles.
• Conectores. As integrações do claude.ai na sua conta, como Slack ou Linear, das quais a rotina pode ler e para as quais pode escrever durante a execução. Uma rotina de triagem de suporte, por exemplo, pode ler um canal do Slack e criar issues no Linear.

Os conectores para rotinas são adicionados na plataforma claude.ai, e o mesmo vale para servidores MCP. Suas configs locais não são carregadas.

Uma rotina pode disparar de três formas: por agenda, via chamada de API ou por evento do GitHub. Uma única rotina pode combinar as três.

Rotinas versus /loop

Há diferença entre /loop e /schedule porque resolvem problemas distintos.

Uma tarefa /loop vive na sua sessão atual. Ela dispara apenas enquanto o Claude Code está aberto e ocioso na sua máquina; fechar o terminal interrompe a execução. Ótimo para ficar monitorando um build que você está acompanhando agora.

Para saber mais sobre /loop e outros comandos importantes, recomendo ler nosso tutorial Claude Code Terminal.

Uma rotina roda na nuvem e independe de qualquer sessão:

Também há uma terceira opção, local. Tarefas agendadas no desktop rodam no seu computador, para trabalhos que precisam dos seus arquivos e ferramentas locais. Elas só executam enquanto a máquina está ativa, mas não exigem o app do Claude aberto.

A rotina que vamos construir

O modelo mental está definido. Agora falta algo para a rotina trabalhar. Para este tutorial, criamos o pr-review-demo, um pequeno projeto em Python com um pull request aberto.

Ele tem um pacote cartlib que gerencia o carrinho de compras: armazena preços em centavos inteiros, aplica descontos para membros e por volume e adiciona imposto estadual para chegar ao valor final. O pacote na branch principal está correto.

O pull request aberto adiciona um cupom de frete grátis e traz um bug real que inserimos de propósito. É uma inconsistência de unidade entre arquivos, invisível em um único arquivo e visível apenas quando você acompanha o valor entre dois. Isso dá à rotina algo concreto para fazer no restante do tutorial.

Faça um fork do repositório para acompanhar com sua própria cópia. É um repositório descartável, e os padrões se transferem para qualquer repo que você apontar a rotina.

Pré-requisitos para acompanhar

Você precisa de uma conta no claude.ai em um plano Pro, Max, Team ou Enterprise, com o Claude Code na web habilitado. As rotinas ficam em claude.ai/code/routines.

O comando /schedule autentica com o login da sua assinatura do claude.ai, não com uma chave da Anthropic API nem credenciais do Bedrock, Vertex ou Foundry. Ele também precisa de um CLI recente, então rode claude update se o seu estiver desatualizado.

Há também dois pré-requisitos separados no GitHub. Primeiro, /web-setup concede acesso para clone, que a rotina agendada precisa. Segundo, o App do Claude para GitHub, instalado separadamente, habilita o gatilho do GitHub que veremos adiante.

Construindo rotinas do Claude Code com /schedule

Com um repo definido, crie a rotina pelo CLI. Rode /schedule em qualquer sessão. Você pode passar uma descrição diretamente:

/schedule daily PR review at 9 am

O Claude então percorre os mesmos campos do formulário web: nome, prompt, repositório, ambiente, conectores e agenda. Ele confirma o horário no seu fuso e converte para você, então 9h vira a expressão cron correta sem você precisar escrever uma.

Se sua conta ainda não tem conexão com o GitHub, o Claude pede para você rodar /web-setup. Rode, e depois execute /schedule novamente para retomar de onde parou.

Escrevendo um prompt que roda sem você

O prompt determina se a rotina vai dar certo ou não.

Uma sessão normal é uma conversa: você pode corrigir o Claude enquanto ele trabalha. Uma rotina não tem quem corrija. Ela começa do zero, roda até o fim e não pode fazer perguntas para esclarecer. O prompt precisa nomear a tarefa, o repositório e o que caracteriza uma execução concluída.

Compare estes dois. O primeiro deixa muita coisa subentendida:

Review the open PR.

Ele não cita o repo nem os critérios de review, não define onde comentar e não traz uma definição de pronto. Uma execução fria não consegue preencher essas lacunas. O segundo prompt resolve tudo:

Review the open pull request in pr-review-demo. The cartlib package works entirely in integer cents. Read the checkout flow and the values it pulls from config.py, and check that every amount stays in cents end to end. If any value is mixed in using the wrong unit, leave an inline comment on that line explaining the error and its effect on the customer's total. Then, post a summary comment stating whether the PR is safe to merge.

Esse prompt nomeia o repo e afirma o invariante que o código deve manter: todos os valores em centavos. Ele aponta para os dois arquivos que importam e define o pronto como um comentário inline mais um veredito de merge. Isso dá um alvo que a execução consegue atingir sozinha. Cole-o quando o /schedule perguntar o que o agente deve fazer.

Todos os seus conectores entram por padrão, então uma rotina nova já alcança tudo que sua conta conecta. Por enquanto está ok; mais adiante vamos enxugar.

Ao concluir o fluxo, o Claude salva a rotina e confirma que ela está ativa, com repositório, agenda, modelo e próxima execução.

A rotina também aparece na lista em claude.ai/code/routines. Abra a página de detalhes para ver tudo em um só lugar: status, repositório, agenda, conectores, o prompt completo e um botão Executar agora.

Clique em Executar agora para rodar imediatamente, em vez de esperar até as 9h.

Lendo a execução

A execução começa a partir de um clone fresco do seu repositório, puxado da branch padrão. Tudo o que você comitou está lá. Tudo o que configurou só na sua máquina não está, então a rotina vê o repo do mesmo jeito que seus colegas veriam.

Quando terminar, a lista de execuções mostra status verde. Verde significa que a sessão rodou e saiu sem erro de infraestrutura. Mas não significa que a tarefa do seu prompt teve êxito. Três tipos de falha podem se esconder atrás do check verde e só aparecem na transcrição:

• Uma requisição de rede bloqueada pelo ambiente.
• Um conector que a rotina esperava, mas não conseguiu acessar.
• Falha no nível da tarefa, quando a execução terminou limpamente mas fez a coisa errada.

Então abra a execução para confirmar. Clique em qualquer execução para lê-la como uma sessão completa: você pode ver o que o Claude fez, revisar o diff, abrir um pull request ou continuar a conversa.

No repo de demo, a transcrição mostra o problema. O Claude lê o checkout.py e encontra o cupom com 5 em vez de 500. Ele explica que isso aplica US$ 5 como 5 centavos, cobrando a mais US$ 4,95 por pedido, e sugere o ajuste de uma linha. Depois, posta a revisão no PR via conector do GitHub.

Gerenciando rotinas do Claude Code pelo CLI

Depois que uma rotina existe, você a gerencia pelo mesmo comando. Rode /schedule list para ver todas, /schedule update para alterar uma e /schedule run para disparar imediatamente.

Os presets de agenda são hourly, daily, weekdays e weekly. Para um intervalo customizado, como a cada 2 horas ou no primeiro dia do mês, escolha primeiro o preset mais próximo. Depois, rode /schedule update para definir uma expressão cron diretamente. O intervalo mínimo é de 1 hora; qualquer coisa mais rápida é rejeitada.

As rotinas também consomem sua cota diária de execuções da conta e, durante o research preview, os eventos do GitHub têm limites por hora. Eventos além do limite são descartados, não entram em fila. Os números atuais variam por plano e aparecem em claude.ai/code/routines.

O CLI cria apenas rotinas agendadas. Para adicionar um gatilho de GitHub ou API, edite a rotina no app web.

Disparando rotinas do Claude Code pelo GitHub e HTTP

A agenda dispara sua rotina no relógio. Dois outros gatilhos permitem que o GitHub ou seus próprios sistemas disparem a mesma rotina. Uma rotina de review de PR pode rodar toda noite, reagir a cada novo PR e iniciar a partir de um script de deploy — tudo ao mesmo tempo.

Você adiciona os dois editando a rotina em claude.ai/code/routines.

Reaja a pull requests com um gatilho do GitHub

O gatilho do GitHub requer o App do Claude para GitHub instalado no repositório ao qual você quer se inscrever. Se o App estiver ausente, a configuração do gatilho pede a instalação. Observe que /web-setup, citado antes, só concede acesso de clone. Ele não instala o App nem entrega webhooks, então rodá-lo não cobre esta etapa.

Com o App instalado, adicione o gatilho e escolha um evento. Os eventos caem em duas categorias, pull requests e releases, e você seleciona uma ação específica dentro de cada. A interface mostra as mais comuns como presets, como PR opened, PR merged e Release published, além de uma opção Custom para o restante.

Depois, refine com filtros. Para pull requests, dá para filtrar por autor, título, corpo, branch base, branch head, labels, is-draft e is-merged. Todas as condições precisam bater para a rotina disparar.

O operador matches regex testa o campo inteiro, não um trecho. Para corresponder a qualquer título que contenha hotfix, escreva .*hotfix.*. Um simples hotfix casa apenas com um título exatamente igual, e nada mais.

O gatilho do GitHub configurado para disparar em um novo pull request, filtrado para a branch main e um autor específico.

No repo de demo, defina o evento como abertura de pull request e deixe os filtros em branco. Agora, todo novo PR dispara a revisão que você escreveu antes, sem ninguém no terminal. A rotina acompanha a unidade do cupom entre os arquivos, deixa um comentário inline no bug e publica um veredito de merge. 

Cada evento que bate nos critérios inicia sua própria sessão, então dois PRs em sequência geram duas execuções independentes.

Dispare uma rotina via HTTP

O gatilho de API permite que suas ferramentas disparem uma rotina. Escolha API no seletor de gatilhos e clique em Generate token. O token aparece uma única vez e não pode ser recuperado depois, então armazene-o imediatamente no cofre de segredos da sua ferramenta de alertas.

Depois, faça um POST no endpoint de disparo da rotina com o token e um corpo text:

curl -X POST https://api.anthropic.com/v1/claude_code/routines/$ROUTINE_ID/fire \
  -H "Authorization: Bearer $ROUTINE_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'

O valor de text é passado como string literal e não é parseado, então escreva texto corrido, não JSON. Entradas estruturadas chegam como texto bruto, e a rotina as lê literalmente. 

O header anthropic-beta é obrigatório, e a API é experimental, então confira a referência da API antes de integrar ao seu CI. A partir daí, uma ferramenta de monitoramento pode chamar esse endpoint em um alerta e fazer a rotina abrir um PR de correção em rascunho sozinha.

Limitando o que as rotinas do Claude Code podem acessar

Uma rotina roda sozinha, então, antes de apontar para um repo real, restrinja o que ela pode alcançar. A documentação descreve quatro controles:

• Quem a rotina representa, via sua identidade do GitHub e conectores.
• Quais branches ela pode fazer push.
• Quais conectores ela pode usar.
• Quais hosts a permitem alcançar pela rede.

Ajuste cada um ao que a rotina realmente precisa.

Identidade da rotina

Identidade vem primeiro porque é o que seus colegas notam em um repo compartilhado. Tudo o que a rotina faz pela sua identidade do GitHub ou por seus conectores aparece como você. 

Commits e pull requests levam seu usuário do GitHub, e mensagens no Slack e tickets no Linear usam suas contas vinculadas. Seus colegas veem seu nome nesses commits e PRs, então nomeie branches e títulos de um jeito que sinalize que uma rotina os criou.

Branches em que a rotina pode fazer push

Branches vêm na sequência. Uma execução é uma sessão completa na nuvem, sem prompts de permissão, então ela nunca para para perguntar antes de editar um arquivo ou abrir um pull request. 

O trilho de segurança é a branch onde ela pode escrever. Por padrão, o Claude faz push apenas em branches com prefixo claude/, mantendo-o longe de branches protegidas ou de longa duração, como main. 

Uma configuração por repositório, Allow unrestricted branch pushes, remove essa restrição. Ative-a de forma deliberada, apenas em repos que precisem disso.

Conectores que a rotina pode usar

Conectores são o ponto mais sensível dos quatro. Todos os seus conectores do claude.ai entram por padrão, e o Claude pode usar todas as ferramentas de um conector incluído, inclusive escritas, sem pedir durante a execução. 

Então reduza a lista ao necessário. Uma rotina de review de PR precisa de GitHub e pouco mais. Um conector perdido de e-mail ou calendário é um acesso sem utilidade para a rotina, e uma injeção de prompt escondida em um PR pode virar esse acesso contra você.

Acesso à rede

Acesso à rede é o último controle. O ambiente Default usa acesso de rede confiável, que alcança uma allowlist interna de registries de pacotes, APIs de provedores de nuvem, registries de containers e domínios comuns de desenvolvimento, e bloqueia o resto. 

Uma requisição bloqueada falha com 403 e x-deny-reason: host_not_allowed. Amplie só quando a rotina precisar alcançar seus próprios serviços. Caso contrário, a falha é discreta, aparecendo na transcrição e não como um erro óbvio.

Ideias de rotinas do Claude Code para criar em seguida

Você já sabe criar, disparar e limitar uma rotina. Estes exemplos da documentação oficial combinam cada trabalho com o gatilho ideal:

• Code review sob medida. Gatilho do GitHub ao abrir PR. Aplica a checklist de review do seu time, deixa comentários inline sobre segurança, performance e estilo, e adiciona um resumo. É a demo, generalizada para seus padrões reais.
• Manutenção de backlog. Gatilho por agenda, toda noite em dias úteis. Lê issues abertas desde a última execução, aplica labels, atribui responsáveis com base na área de código citada e publica um resumo no Slack.
• Verificação de deploy. Gatilho de API pelo seu pipeline de CD após cada deploy em produção. Roda smoke checks no novo build, escaneia logs de erro por regressões e posta um go/no-go no canal de releases.
• Drift na documentação. Gatilho por agenda, semanal. Analisa PRs mesclados desde a última execução, sinaliza docs que referenciam APIs alteradas e abre PRs de atualização no repositório de docs.

Rotinas combinam com trabalhos sem supervisão, repetíveis e com resultado claro. Se você consegue escrever os critérios de sucesso no prompt, como fez no review de PR, a tarefa é candidata. Trabalho que exige julgamento humano em tempo real não é.

Conclusão

As rotinas mudam como você investe tempo em trabalhos recorrentes. Em vez de rodar cada tarefa no terminal, você escreve uma vez e revisa o que já foi executado. A revisão de PR que você criou dispara com seu notebook fechado, e você lê o veredito quando quiser.

Para avançar com o Claude Code, estes tutoriais combinam bem com este aqui:

• Boas práticas do Claude Code para extrair mais de cada sessão.
• Como escrever um arquivo CLAUDE.md para dar contexto compartilhado às suas rotinas e sessões.
• Spec-driven development para tarefas que valem a pena especificar antes de automatizar.
• Auto mode e canais para rodar o Claude Code com menos supervisão.