Astro zera fila de issues com fábrica de agentes no GitHub Actions
O time do Astro implementou um pipeline automatizado de triagem de issues que reduziu o backlog do repositório de mais de 200 issues para cerca de 30, com expectativa de chegar a zero pela primeira vez em mais de cinco anos de história do projeto. O sistema lê relatórios de bugs recebidos, reproduz os problemas em sandboxes, diagnostica a causa raiz e publica releases de preview para que o autor do issue valide a correção antes de um pull request ser aberto.
Como funciona a automação
A triagem segue as mesmas etapas do processo manual: reproduzir o bug, diagnosticar com instrumentação e logs, verificar se o comportamento é realmente um erro ou funcionalidade esperada e, por fim, corrigir. Cada fase é executada por um subagente isolado, para reduzir o viés de modelos de linguagem em forçar soluções quando o bug não existe. As descobertas são passadas sequencialmente entre os agentes por meio de um arquivo report.md.
O pipeline funciona como uma máquina de estados baseada em labels do GitHub: cada issue novo começa com triage needed e, quando o usuário confirma a correção, passa para fix verified. A automação não mantém estado próprio; ela lê os comentários existentes no issue para determinar a próxima etapa. Quando os agentes encontram uma solução, o sistema gera um preview release com pkg.pr.new, publica resumo, logs completos e instruções de instalação no próprio issue e, após confirmação, abre o pull request.
Flue e triagebot-action
Durante o desenvolvimento, o time percebeu que o fluxo não era específico do GitHub: reagir a eventos, executar subagentes isolados e separar raciocínio das ações permitidas é um workflow genérico, que poderia ser acionado por Slack, cron job ou webhook. Essa generalização virou o Flue, um framework aberto e agnóstico de plataforma para construir agentes e workflows duráveis.
Inicialmente, a lógica vivia dentro do monorepo do Astro, o que dificultava iterações. Depois, foi extraída para um repositório independente e testável, o triagebot-action, distribuído como GitHub Action. O artigo mostra um exemplo de configuração com tokens do GitHub e da Cloudflare, além de modelos do Workers AI, como kimi-k2.7-code para triagem e kimi-k2.6 para verificação. Outras equipes já adotaram ou fizeram fork da ação para criar suas próprias fábricas de software.
Efeitos na comunidade e no código
O time temia que respostas automatizadas tornassem o projeto impessoal, mas afirma que isso não aconteceu; os mantenedores passaram a interagir mais em discussões no Discord, RFCs e novas funcionalidades. Quando um agente falha em resolver um issue, o caso é tratado como sinal de problema no próprio código: abstrações pouco claras, documentação ausente ou testes insuficientes. Um exemplo citado envolve bugs de Hot Module Replacement, em que a falta de cobertura de testes e de comentários explicando uma condição fazia o bot propor correções que geravam regressões. Após adicionar a documentação necessária, o agente deixou de sugerir mudanças incorretas.
Segundo o artigo, cada correção estrutural torna o bot e os próprios desenvolvedores humanos mais eficazes naquela parte do código. O objetivo central é criar um ciclo sustentável que libere mantenedores da administração de backlog para focar no desenvolvimento do framework.