Hermify
Volver al Blog
HermesGitHubAI AgentsAutomation

Hermes Agent + GitHub Actions: automatizá tus repos

Tres recetas concretas para que Hermes Agent te cuide los repos de GitHub: triage de fallos de CI, digest nocturno de PRs y limpieza de issues estancadas.

Por Hermify Team||8 min de lectura
Vista oscura de un editor de código con el logo de Hermes y el Octocat de GitHub conectados por una línea verde brillante, con el texto 'GitHub Automation'

Tus Repos Necesitan un Asistente, No Otro Dashboard

Si mantenés aunque sea dos o tres repos en GitHub, probablemente notaste el mismo patrón: la mayor parte del trabajo no es escribir código. Es analizar fallos de CI, revisar diffs de PRs que abriste ayer, cerrar issues estancadas que nadie va a tocar y mandarte a vos mismo un resumen del lunes a la mañana sobre lo que pasó durante el fin de semana.

Esta es la parte del mantenimiento de repos donde la IA es genuinamente buena. No la programación creativa, sino el trabajo rutinario de mantenimiento. Y Hermes Agent, con su scheduler de cron, su listener de webhooks y acceso nativo al CLI de GitHub, fue construido exactamente para esto.

Esta guía muestra tres recetas concretas que podés copiar a tu setup de Hermes hoy mismo. Cada una resuelve un problema real que probablemente sentís todas las semanas.

  • Un agente de triage de fallos de CI que postea un diagnóstico en el PR a los pocos minutos de ponerse en rojo
  • Un digest nocturno de PRs que te llega a Telegram o Discord a las 9pm
  • Un triage semanal de issues estancadas que redacta un comentario de cierre para issues que nadie tocó en 60 días

Al final deberías poder configurar cualquiera de estas en una sola sentada. Si todavía no lo hiciste, Empezá con Hermify te da una instancia gestionada de Hermes con toda la conexión a GitHub ya cableada.

Por Qué Hermes para Automatizar Repos

Existen un montón de GitHub Actions y bots del Marketplace prefabricados que hacen tareas únicas: uno para revisar código, uno para issues estancadas, uno para release notes. El problema de coserlos entre sí es que ninguno recuerda nada. Cada ejecución empieza desde cero. Cada uno necesita su propia configuración. Cada uno habla con un servicio externo distinto.

Hermes es diferente en tres formas útiles:

  • Un agente, muchas skills. Una sola instancia de Hermes puede revisar PRs, hacer triage de issues, correr cron jobs y responder preguntas puntuales por Telegram. Lo configurás una vez, le enseñás una vez, mejora una vez.
  • Memoria persistente. Cuando Hermes marcó un test inestable en el PR #312 la semana pasada, lo recuerda cuando el mismo test falla en el PR #340 hoy. Ese tipo de contexto es algo que la mayoría de los Actions del Marketplace no pueden mantener.
  • Cron en español llano. No escribís 0 9 * * 1-5. Escribís "todos los días hábiles a las 9am mandame un digest de PRs" y Hermes te genera la skill y el horario.

Hermes Agent revisando un pull request de GitHub en una terminal

Para una mirada más profunda a los primitivos que están abajo, leé nuestro post sobre memoria y skills en Hermes.

Receta 1: Agente de Triage de Fallos de CI

Problema. Un test falla en un PR. Ves la X roja. Hacés click en Actions, scrolleás el log, descubrís qué paso explotó, decidís si fue inestabilidad o una regresión real, y escribís un comentario. Ese ida y vuelta lleva entre 5 y 15 minutos cada vez. En una semana ajetreada con varios repos, son horas.

Qué hace Hermes. Un webhook se dispara cuando check_run se completa con conclusion: failure. Hermes trae el log del job que falló usando el CLI de GitHub, identifica el paso que falló y la causa raíz más plausible, y postea un comentario en el PR asociado con un diagnóstico de un párrafo y un siguiente paso sugerido (volver a correr, arreglar localmente, marcar como inestable conocido).

Esquema del setup.

  1. En la config de Hermes, agregá una suscripción al webhook check_run.completed para los repos que te importan.
  2. Agregá una skill llamada github-ci-triage con un prompt parecido a: "Traé el log del job fallido con gh run view --log-failed. Identificá el paso que falló y la primera línea de stack trace o error. Si el error matchea un patrón inestable conocido en memoria, etiquetá el comentario como 'probable inestabilidad'. Si no, resumí la causa raíz en un párrafo y sugerí el arreglo más chico."
  3. Apuntá el handler del webhook a esta skill y decile que entregue el resultado como un comentario en el PR usando gh pr comment.

La primera vez que corra, leé el comentario rápido y dale un thumbs-up (Hermes lo guarda en memoria como un buen diagnóstico confirmado) o corregilo. Después de unas vueltas los diagnósticos se afinan porque Hermes está aprendiendo tu codebase, las particularidades de tu CI y qué tests son inestables crónicos.

Receta 2: Digest Nocturno de PRs

Problema. Tenés entre 3 y 15 PRs abiertos en cualquier momento entre proyectos personales, repos del trabajo y los proyectos OSS que mantenés. Para el viernes a la tarde no tenés idea de cuáles se movieron, cuáles están bloqueados por vos y cuáles están bloqueados por otra persona.

Qué hace Hermes. Todos los días hábiles a las 9pm hora de Madrid (o la zona horaria que configures), Hermes corre el CLI de GitHub para listar PRs abiertos, los agrupa por estado (esperando revisión, esperando CI, draft, mergeable) y entrega un digest formateado a tu Telegram o Discord.

Un digest se ve así:

Digest de PRs - 18 mayo 2026

ESPERANDO POR VOS (3):
- albertoaquinodev/hermes-up #421 "fix: revalidate blog index" - revisión pedida hace 4d
- albertoaquinodev/hermes-up #418 "feat: BYOK provider snapshot" - tu revisión es el último bloqueo
- nousresearch/hermes-agent #2104 "docs: add cron examples" - PR de docs corto

ESPERANDO POR OTROS (2):
- albertoaquinodev/hermes-up #420 - bloqueado por reviewer hace 2d
- nousresearch/hermes-agent #2099 - CI rojo, el owner lo está arreglando

MERGEABLES AHORA (1):
- albertoaquinodev/hermes-up #422 - todo verde, listo para mergear

Esquema del setup.

  1. Creá un cron job con el prompt: "Todos los días hábiles a las 21:00 listá los PRs abiertos en albertoaquinodev/* y nousresearch/* usando gh pr list. Agrupalos por estado. Mandalos a mi Telegram."
  2. Hermes parsea el horario en lenguaje natural a la expresión cron 0 21 * * 1-5 y registra la skill.
  3. Conectá un destino de entrega de Telegram o Discord si todavía no lo hiciste.

Todo lleva unos 10 minutos. Una vez en funcionamiento cuesta entre $0.02 y $0.05 por corrida nocturna en Sonnet, dependiendo de cuántos PRs estén abiertos.

Para comparar, el mismo setup armado con Actions encadenados y apps de Slack lleva un fin de semana y se rompe cada vez que GitHub cambia algo en su API.

Receta 3: Triage Semanal de Issues Estancadas

Problema. Las issues se acumulan. Algunas se arreglan en un PR paralelo y nadie las cierra. Algunas se reportan, el usuario desaparece y la issue queda abierta para siempre. Algunas son duplicadas. Caminar el backlog manualmente es el tipo de trabajo que nadie hace.

Qué hace Hermes. Todos los lunes a la mañana, Hermes lista todas las issues sin actividad en 60 días, lee el cuerpo y los comentarios, decide una de cuatro acciones, y (según cuánta autonomía le des) redacta un comentario para que aprobes o postea el comentario directamente.

Las cuatro acciones:

  • Cerrar como arreglado. El bug referenciado parece estar resuelto en un commit o release reciente. Hermes postea un comentario de cierre amable con el commit que lo arregló.
  • Cerrar como estancado. Le pidieron más info al autor hace más de 30 días y nunca respondió.
  • Subir prioridad. La issue sigue siendo relevante, tiene thumbs-ups de otros usuarios y merece un cambio de label.
  • Convertir en discussion. La issue es un feature request que va en Discussions, no en Issues.

Una terminal mostrando jobs programados de Hermes Agent corriendo contra un repo de GitHub

Esquema del setup.

  1. Creá un cron job: "Todos los lunes a las 10am, hacé triage de issues estancadas en mis repos. Redactá los comentarios pero todavía no los postees."
  2. Hermes genera una skill que corre gh issue list --state open --search 'updated:<2026-03-18' (la fecha se calcula en tiempo de ejecución), lee cada issue y decide la acción.
  3. Los borradores llegan en un solo mensaje de Telegram o, si preferís, como un resumen tipo PR que podés revisar.

Después de unas semanas de corridas supervisadas, podés activar el modo auto-post (Hermes actúa directo) o dejarlo en modo borrador para siempre. De cualquier forma, tu backlog deja de crecer.

Dónde Hermes Para Y Dónde Tomás Vos

La versión honesta de esta historia es que Hermes es excelente para el 80% rutinario del mantenimiento de repos, y todavía querés un humano para el 20% que requiere criterio: decidir si un test inestable es en realidad un bug real, anunciar un cambio que rompe en una API, decirle a un usuario que su feature request está fuera de scope.

El punto entero del setup de arriba es sacarte el 80% de encima para que tengas tiempo para el 20%. Para otra variante de la misma idea, leé nuestro post sobre autohospedar un agente de IA con Docker, que cubre la parte de infraestructura para correr Hermes a largo plazo.

Probalo Esta Semana

Si ya autohospedás Hermes, las tres recetas de arriba son más o menos una tarde de trabajo. Si no, el camino más rápido es Empezá con Hermify - una instancia gestionada de Hermes viene con el CLI de GitHub, el listener de webhooks y el scheduler de cron ya configurados. Vos agregás el token del repo y escribís la frase del cron en lenguaje natural.

El setup de cuidador-de-repos es el tipo de cosa que te hace preguntar por qué nadie lo construyó antes. Después te acordás: la mayoría del tooling de "IA para devs" está pensado para el 20% de escribir código, no para el 80% de mantenimiento. Hermes va por el 80%.

Fuentes

Lanza tu propio agente Hermes

Trae tu clave de API, conecta Telegram y ten un agente de IA que evoluciona solo activo en 60 segundos.

Empezar