Hermify
Voltar ao Blog
HermesGitHubAI AgentsAutomation

Hermes Agent + GitHub Actions: automatize seus repos

Três receitas concretas para deixar o Hermes Agent cuidar dos seus repos no GitHub: triagem de falhas de CI, digest noturno de PRs e limpeza de issues paradas.

Por Hermify Team||8 min de leitura
Visão escura de um editor de código com o logo do Hermes e o Octocat do GitHub conectados por uma linha verde brilhante, com o texto 'GitHub Automation'

Seus Repos Precisam de um Ajudante, Não Outro Dashboard

Se você mantém pelo menos dois ou três repos no GitHub, provavelmente percebeu o mesmo padrão: a maior parte do trabalho não é escrever código. É fazer triagem de falhas de CI, dar uma olhada nos diffs de PRs que você abriu ontem, fechar issues paradas que ninguém vai mexer e enviar para si mesmo um resumo de segunda-feira sobre o que aconteceu no fim de semana.

Essa é a parte da manutenção de repos em que IA é genuinamente boa. Não a programação criativa, mas o trabalho rotineiro de manutenção. E o Hermes Agent, com seu scheduler de cron, listener de webhooks e acesso nativo ao CLI do GitHub, foi feito exatamente para isso.

Este guia mostra três receitas concretas que você pode copiar para sua configuração do Hermes hoje. Cada uma resolve um problema real que você provavelmente sente toda semana.

  • Um agente de triagem de falhas de CI que posta um diagnóstico no PR poucos minutos depois do vermelho
  • Um digest noturno de PRs que chega no seu Telegram ou Discord às 21h
  • Uma triagem semanal de issues paradas que rascunha um comentário de fechamento para issues que ninguém tocou em 60 dias

No final você deve conseguir configurar qualquer uma delas em uma única sessão. Se ainda não fez, Comece com o Hermify te dá uma instância gerenciada do Hermes com toda a integração do GitHub já conectada.

Por Que Hermes Para Automatizar Repos

Existem várias GitHub Actions e bots do Marketplace prontos que fazem tarefas pontuais: um para revisar código, um para issues paradas, um para release notes. O problema de costurá-los juntos é que nenhum lembra de nada. Cada execução começa do zero. Cada um precisa da própria configuração. Cada um conversa com um serviço externo diferente.

O Hermes é diferente em três aspectos úteis:

  • Um agente, várias skills. Uma única instância do Hermes pode revisar PRs, fazer triagem de issues, rodar cron jobs e responder perguntas pontuais pelo Telegram. Você configura uma vez, ensina uma vez, ele melhora uma vez.
  • Memória persistente. Quando o Hermes marcou um teste instável no PR #312 semana passada, ele lembra quando o mesmo teste falha no PR #340 hoje. Esse tipo de contexto é algo que a maioria das Actions do Marketplace não consegue manter.
  • Cron em português comum. Você não escreve 0 9 * * 1-5. Você escreve "todo dia útil às 9h me manda um digest de PRs" e o Hermes gera a skill e o agendamento para você.

Hermes Agent revisando um pull request do GitHub em um terminal

Para um olhar mais profundo sobre as primitivas por trás, leia nosso post sobre memória e skills no Hermes.

Receita 1: Agente de Triagem de Falhas de CI

Problema. Um teste falha em um PR. Você vê o X vermelho. Clica em Actions, rola o log, descobre qual passo explodiu, decide se foi instabilidade ou regressão real e escreve um comentário. Esse ida e volta leva de 5 a 15 minutos cada vez. Em uma semana corrida com vários repos, são horas.

O que o Hermes faz. Um webhook dispara quando check_run é concluído com conclusion: failure. O Hermes busca o log do job que falhou via CLI do GitHub, identifica o passo que falhou e a causa raiz mais plausível, e posta um comentário no PR associado com um diagnóstico de um parágrafo e um próximo passo sugerido (rodar de novo, corrigir localmente, marcar como flaky conhecido).

Esboço da configuração.

  1. Na config do Hermes, adicione uma assinatura ao webhook check_run.completed para os repos que importam.
  2. Adicione uma skill chamada github-ci-triage com um prompt parecido com: "Busque o log do job que falhou com gh run view --log-failed. Identifique o passo que falhou e a primeira linha de stack trace ou erro. Se o erro bate com um padrão flaky conhecido em memória, rotule o comentário como 'provável flaky'. Caso contrário, resuma a causa raiz em um parágrafo e sugira a menor correção possível."
  3. Aponte o handler do webhook para essa skill e diga para entregar o resultado como um comentário no PR usando gh pr comment.

Na primeira execução, leia o comentário rapidamente e dê um thumbs-up (o Hermes guarda como um diagnóstico bom confirmado) ou corrija. Depois de algumas rodadas os diagnósticos ficam mais afiados porque o Hermes está aprendendo seu codebase, as peculiaridades do seu CI e quais testes são flakies crônicos.

Receita 2: Digest Noturno de PRs

Problema. Você tem entre 3 e 15 PRs abertos a qualquer momento entre projetos pessoais, repos do trabalho e projetos OSS que você mantém. Na sexta à tarde você não tem ideia de quais se mexeram, quais estão bloqueados em você e quais estão bloqueados em outra pessoa.

O que o Hermes faz. Todo dia útil às 21h horário de Madrid (ou o fuso que você configurar), o Hermes roda o CLI do GitHub para listar PRs abertos, agrupa por status (aguardando review, aguardando CI, draft, mergeable) e entrega um digest formatado no seu Telegram ou Discord.

Um digest fica assim:

Digest de PRs - 18 maio 2026

AGUARDANDO VOCÊ (3):
- albertoaquinodev/hermes-up #421 "fix: revalidate blog index" - review pedida há 4d
- albertoaquinodev/hermes-up #418 "feat: BYOK provider snapshot" - sua review é o último bloqueio
- nousresearch/hermes-agent #2104 "docs: add cron examples" - PR de docs pequeno

AGUARDANDO OUTROS (2):
- albertoaquinodev/hermes-up #420 - bloqueado no reviewer há 2d
- nousresearch/hermes-agent #2099 - CI vermelho, o owner está corrigindo

MERGEABLES AGORA (1):
- albertoaquinodev/hermes-up #422 - tudo verde, pronto para merge

Esboço da configuração.

  1. Crie um cron job com o prompt: "Todo dia útil às 21:00 liste os PRs abertos em albertoaquinodev/* e nousresearch/* usando gh pr list. Agrupe por status. Mande para meu Telegram."
  2. O Hermes traduz o agendamento em linguagem natural para a expressão cron 0 21 * * 1-5 e registra a skill.
  3. Conecte um destino de entrega de Telegram ou Discord se ainda não fez.

Tudo leva uns 10 minutos. Em funcionamento custa entre $0,02 e $0,05 por execução noturna no Sonnet, dependendo de quantos PRs estiverem abertos.

Para comparar, a configuração equivalente costurada com Actions e apps do Slack leva um fim de semana e quebra toda vez que o GitHub muda algo na API.

Receita 3: Triagem Semanal de Issues Paradas

Problema. As issues se acumulam. Algumas são corrigidas em um PR paralelo e ninguém fecha. Algumas são reportadas, o usuário some e a issue fica aberta para sempre. Algumas são duplicadas. Caminhar o backlog manualmente é o tipo de trabalho que ninguém faz.

O que o Hermes faz. Toda segunda de manhã, o Hermes lista todas as issues sem atividade em 60 dias, lê o corpo e os comentários, decide uma de quatro ações e (dependendo de quanta autonomia você der) rascunha um comentário para você aprovar ou posta o comentário direto.

As quatro ações:

  • Fechar como corrigido. O bug referenciado parece resolvido em um commit ou release recente. O Hermes posta um comentário de fechamento educado com o commit que corrigiu.
  • Fechar como parado. Pediram mais informação ao autor há mais de 30 dias e ele nunca respondeu.
  • Subir prioridade. A issue continua relevante, tem thumbs-ups de outros usuários e merece uma mudança de label.
  • Converter em discussion. A issue é um pedido de feature que pertence a Discussions, não a Issues.

Um terminal mostrando jobs agendados do Hermes Agent rodando contra um repo do GitHub

Esboço da configuração.

  1. Crie um cron job: "Toda segunda às 10h, faça triagem das issues paradas nos meus repos. Rascunhe os comentários mas ainda não poste."
  2. O Hermes gera uma skill que roda gh issue list --state open --search 'updated:<2026-03-18' (a data é calculada na hora da execução), lê cada issue e decide a ação.
  3. Os rascunhos chegam em uma mensagem única no Telegram ou, se preferir, como um resumo no estilo PR que você pode revisar.

Depois de algumas semanas de execuções supervisionadas, você pode ativar o modo auto-post (o Hermes age direto) ou deixar em modo rascunho para sempre. De qualquer forma, seu backlog para de crescer.

Onde o Hermes Para E Onde Você Assume

A versão honesta dessa história é que o Hermes é excelente nos 80% rotineiros da manutenção de repos, e você ainda quer um humano para os 20% que exigem julgamento: decidir se um teste flaky é na verdade um bug real, anunciar uma quebra de API, dizer a um usuário que o pedido de feature está fora de escopo.

O ponto inteiro da configuração acima é tirar os 80% do seu prato para sobrar tempo para os 20%. Para outra versão da mesma ideia, leia nosso post sobre autohospedar um agente de IA com Docker, que cobre a parte de infraestrutura para rodar o Hermes a longo prazo.

Teste Essa Semana

Se você já autohospeda o Hermes, as três receitas acima são mais ou menos uma noite de trabalho para configurar. Se não, o caminho mais rápido é Comece com o Hermify - uma instância gerenciada do Hermes vem com o CLI do GitHub, listener de webhooks e scheduler de cron já configurados. Você adiciona o token do repo e escreve a frase do cron em linguagem natural.

A configuração de cuidador-de-repos é o tipo de coisa que faz você se perguntar por que ninguém construiu antes. Aí você lembra: a maior parte do tooling de "IA para devs" é pensada para os 20% de escrever código, não para os 80% de manutenção. O Hermes vai atrás dos 80%.

Fontes

Lance seu próprio agente Hermes

Traga sua chave de API, conecte o Telegram e tenha um agente de IA que evolui sozinho no ar em 60 segundos.

Começar agora