Agente de IA para el informe de sprint diario: tu repositorio de GitHub resumido cada mañana en un wiki

Un resumen de sprint útil es breve, está fechado y se puede comparar de un día a otro. También es tedioso de producir: hay que abrir el repositorio, contar las pull requests fusionadas, localizar las que esperan revisión, repasar las issues, comprobar si se acerca una release y escribir dos párrafos que nadie tiene tiempo de pulir. Lo habitual es que el resumen no exista o que se improvise antes de la reunión, con los bloqueos descubiertos demasiado tarde. Es una tarea ideal para un agente de IA autónomo: se repite igual, se apoya en datos ya estructurados y se comprueba de un vistazo.

La inspiración: el resumen de la mañana que nadie compiló

El punto de partida es un uso descrito en testimonios de personas que utilizan agentes autónomos: agentes que leen las herramientas del equipo técnico, cuentan lo ocurrido y dejan cada mañana un informe de sprint. Lo que se repite en estos relatos no es el volumen de datos, sino la regularidad: el resumen existe todos los días, con la misma estructura, lo que permite ver tendencias en lugar de reaccionar a una cifra aislada.

Atako retoma esta idea con un solo agente y un solo resultado. El agente lee GitHub, calcula, redacta y publica. No cambia nada en el repositorio, y el informe es lo único que produce.

Qué hace el agente

El analista de delivery lee el repositorio en GitHub, el que le indiques con el formato propietario/nombre. En cada pasada sigue un método fijo.

Primero cuenta, en siete días móviles desde la fecha de hoy, las pull requests fusionadas, las que siguen abiertas con su antigüedad, las que esperan revisión desde hace más de tres días, las issues abiertas y cerradas y las releases publicadas. Después detecta los bloqueos: pull requests abiertas desde hace más de cinco días, issues que se acumulan sobre un mismo tema, una release con retraso a la vista de los commits. Nombra cada uno con su enlace y su autor. Por último compara con los siete días anteriores y dice qué se ha movido.

Redacta entonces una nueva página «Resumen del sprint - » seguida de la fecha del día en el wiki del proyecto. Si la página del día ya existe, la actualiza en lugar de crear una segunda. La estructura no cambia: las tres o cuatro cifras que importan, el avance respecto al periodo anterior, los bloqueos y las pull requests que se eternizan y las decisiones a considerar. Empieza por la conclusión, se lee en dos minutos y resume lo esencial en el chat.

Qué no hace el agente

El analista lee, nunca escribe en GitHub: ni comentarios, ni etiquetas, ni revisiones, ni fusiones, ni cierres. No sube código. No contacta con nadie: el informe y el chat son sus únicos canales de salida. Nunca inventa una cifra ni un enlace, y un dato ausente se escribe «no disponible».

Cada día tiene su página: el agente nunca sobrescribe un día anterior, lo que deja un historial que el equipo puede releer. Los hechos se separan de la interpretación, y la interpretación se señala como tal. El informe propone prioridades, no las impone: es el principio de un diseño con validación humana.

Cómo ponerlo en marcha en Atako

Desde la página de este caso de uso, el despliegue se hace en cuatro pasos.

1. Conectar GitHub. Da a Atako acceso de lectura al repositorio a seguir cuando lo pida. La conexión se verifica antes de crear nada.
2. Indicar tu contexto. Indica el repositorio, con el formato propietario/nombre, y los lectores del informe, para adaptar el tono.
3. Desplegar. Una sola acción crea el agente y el proyecto «Resumen del sprint». El agente se aprovisiona y recibe solo sus primeras instrucciones.
4. Primer resumen y ritmo diario. El analista produce el primer informe sobre los últimos siete días y luego programa él mismo su pasada de las 8:00, cada mañana.

Si aún no tienes cuenta, crearla inicia tu prueba y el escenario se configura justo después. Si tu administrador no te ha autorizado a crear agentes, el despliegue te lo dice y se detiene.

Dónde ver los resultados

El informe vive en el wiki del proyecto «Resumen del sprint», una página por día, de la más reciente a la más antigua. El resumen del agente llega también a su chat, lo que permite leer lo esencial desde el móvil antes de abrir la página. En el plató de Atako, el analista aparece con su actividad: se ve cuándo lee el repositorio y cuándo redacta, sin preguntar en qué punto está el resumen.

Puedes hablarle en su chat. Pregunta de dónde sale una cifra, pídele que detalle un bloqueo, que siga otro repositorio o que rehaga el resumen con otro enfoque. El agente conserva la memoria de sus pasadas anteriores.

Salvaguardas

El acceso es deliberadamente estrecho y de solo lectura: ocho herramientas de GitHub, para listar repositorios, leer un repositorio, listar y leer pull requests, listar y buscar issues y listar commits y releases. Un agente que ve una lista corta de herramientas las usa con más fiabilidad que uno perdido en un catálogo de cientos. No se concede nada por defecto y cada acceso puede retirarse en cualquier momento desde Atako.

La validación humana se sitúa en la decisión. El informe señala los bloqueos y las pull requests que se eternizan; es el equipo quien decide recordar una revisión, dividir una pull request o aplazar una release. El agente solo ve lo que GitHub le da: una pull request sin descripción o un repositorio con issues sin etiquetar dará un resumen menos preciso, y el informe lo dice en lugar de ocultarlo.

Qué esperar

Espera un primer resumen útil pero todavía genérico, que se vuelve preciso cuando ajustas en el chat los lectores y los umbrales, por ejemplo pidiendo que señale las pull requests que esperan revisión desde hace dos días en lugar de tres. El valor viene de la repetición: tras dos semanas, las páginas sucesivas permiten comparar y ver qué bloqueo dura y qué tendencia se dibuja. Para un equipo técnico pequeño, es la diferencia entre un balance reconstruido de memoria antes de la reunión y un resumen diario que existe solo, con las mismas definiciones cada día.