Astro Reduces Open GitHub Issues Toward Zero Using Automated AI Triage Pipeline

Astro Reduces Open GitHub Issues Toward Zero Using Automated AI Triage Pipeline The maintainers of the Astro open source repository have deployed an automated issue triage pipeline that reduced open issues from over 200 to approximately 30, with an expected drop to zero. Driven by isolated AI subagents inside GitHub Actions, the system reproduces bugs, identifies root causes, creates preview releases, and has grown into the open-source automation framework Flue. Astro's automated triage pipeline brought open issues from over 200 down to around 30 without auto-closing cold tickets or ignoring reports. The triage workflow uses isolated AI subagents sequentially passing findings via a markdown report to avoid false bug fixes. The pipeline operates as a label-driven state machine within GitHub Actions, releasing preview builds through pkg.pr.new for reporters to verify before opening pull requests. The underlying agent orchestration has been released as Flue, an open platform-agnostic framework, while the triage workflow is hosted separately as triagebot-action. Automated Triage Architecture and State Machine To address open source maintainer burnout caused by high issue volumes, Astro automated manual triage by mirroring maintainer workflows. Isolated AI subagents execute distinct phases sequentially to prevent model bias toward forcing fixes for non-existent bugs, passing context through a shared report file. The automation functions as a state machine governed entirely by issue labels, transitioning from triage needed to fix verified while reading comment history to track state without internal persistent storage. Verification Loops and Codebase Quality When agents determine a fix, the pipeline deploys a preview release using pkg.pr.new and comments the diagnosis, logs, and installation instructions directly onto the ticket. If the reporter verifies the preview, the workflow opens a pull request. Maintainers view agent failures as signals of missing tests, unclear documentation, or weak boundaries; in one case involving Hot Module Replacement bugs, adding an explanatory comment to a specific conditional statement prevented the agent from introducing regressions elsewhere. Decoupling and Generalization into Flue Maintainers initially ran the triage logic inside the Astro monorepo before decoupling it into triagebot-action to enable independent testing and updates. Recognizing that orchestrating subagents and isolating logic applies beyond GitHub, the underlying engine was generalized into Flue, a platform-agnostic framework designed to handle agent-based workflows triggered by webhooks, cron jobs, or chat messages.

Astro 构建 AI 软件工厂实现 GitHub Issue 趋近清零 面对开源维护者处理海量 Issue 带来的倦怠问题，Astro 团队在 GitHub Actions 中搭建了基于隔离 AI 子智能体的自动化分流与修复流水线，不仅将未决 Issue 从 200 多个压降至约 30 个并有望归零，还衍生出了开源框架 Flue 与独立工作流工具。 Astro 借助多智能体自动化流水线将未决 Issue 从 200 多个压降至约 30 个，预计将在 5 年多历史上首次达成零 Issue。 系统通过沙盒复现、根因诊断及发布预览包交由报告者验证，全流程采用基于 Issue 标签的状态机驱动，无额外外部状态存储。 底层能力被抽象为平台无关的自动化框架 Flue，分流逻辑也独立拆分为开源仓库 triagebot-action 供其他团队复用。 基于状态机与隔离子智能体的流水线 Astro 的分流流水线完全复刻了人工排查问题的步骤。为避免大语言模型在无 Bug 时强行制造修复方案，系统由多个相互隔离的子智能体按顺序执行，并借助 report.md 传递发现。整个工作流本质上是由 Issue 标签（如 triage needed 到 fix verified）驱动的状态机，无需额外存储状态。智能体生成修复后会通过 pkg.pr.new 构建预览包发给提报者测试，用户确认有效后自动化程序才会发起 PR。 失败反馈驱动代码库质量优化 团队将 AI 智能体无法正确修复问题视为代码库架构、测试或文档不足的信号。在一次关于模块热替换（HMR）Bug 的排查中，智能体反复对缺乏测试覆盖的 if 条件进行错误修改并引发回归，在维护者补充解释逻辑的注释后，智能体便不再出错。这种机制促使团队持续补全缺失的测试与注释，使后续的人类与 AI 维护者均能受益。 架构解耦与开源衍生工具 为规避在主代码库中直接迭代工作流的风险，团队将分流逻辑解耦为独立且具备自动化测试的 triagebot-action 仓库，供其他项目复用或派生。此外，团队发现智能体工作流逻辑并非特定于 GitHub，因此将其底层进一步通用化，推出了适用于各类触发事件与模型的开源智能体工作流框架 Flue。

Everyone is talking about software factories: the idea that AI agents can be assembled into a pipeline that produces working software on their own, the way a factory turns raw materials into finished goods. There’s endless debate over whether that’s actually possible, how far the automation can really go, and whether the “loops” people are demoing count for anything. Some have already written them off as a failure. Running alongside that is a quieter, more worried conversation: open source maintainers are burning out. The AI boom has made it nearly free to generate issues, pull requests, and security reports, and enormously expensive for a maintainer to read through them all. The old ways of keeping a project healthy are buckling under the volume. Everyone has a hot take on both topics. We think we have something rarer to offer: real results. For the past several months we’ve run an automated triage pipeline on the Astro repository. It reads incoming bug reports, reproduces them in sandboxes, diagnoses the root cause, and ships preview releases for the reporter to verify. The engine underneath it grew into [Flue](https://flueframework.com/), an open framework for building this kind of agent automation, and it’s the same tool you could use to build your own. It wasn’t an instant success. But through a lot of iteration, we’ve used it to bring our open issues down from over 200 to about 30, and we expect to hit zero sometime in the next month. That would be the first time this repository has seen zero open issues in its 5+ year history. We didn’t get there by declaring "issue bankruptcy," auto-closing cold tickets, or ignoring reports. We did it by automating issue triage with a team of isolated AI subagents running right inside GitHub Actions. Here’s the story of how we got there, and what you might take back to your own projects. At the start of the year, we focused on automating one specific area of development: issue triage. As an open source project, manual issue triage can be one of the more time-consuming, least-rewarding parts of the job. A single issue can sometimes take hours just to reproduce, let alone fix. It was a natural (yet often overlooked) place for us to start our automation journey. We began by developing an agent skill. This allowed us to develop and test the automation locally as maintainers, running a coding harness on our own machines. We could then run that same harness in a GitHub Action on our repo, and get total reuse of that exact same triage workflow skill. The triage skill mirrors the exact steps we take during manual issue resolution: To prevent the frequent LLM bias toward forcing a solution when a bug might not actually exist, each phase is executed by an isolated subagent. These subagents pass information forward sequentially by compiling their discoveries into a **report.md** file. Following initial internal testing of the triage skill, our focus shifted toward building a fully automated pipeline. We specifically wanted to integrate this logic directly into a GitHub workflow, ensuring complete transparency so that anyone could easily audit the agent's sequential reasoning and operational steps. As we wired it up, we realized the whole pipeline was really just a state machine ***driven by issue labels***. Every new submission starts with the label triage needed, and once a user confirms a fix it moves to fix verified. Beyond those label transitions the pipeline holds no state of its own; it simply reads back through the issue’s existing comments to work out where a given issue is and what should happen next. From there the flow runs on its own. When the agents land on a fix, the pipeline spins up a preview release with [pkg.pr.new](http://pkg.pr.new) and posts everything back to the issue: a summary of what it found, the full logs, and instructions for installing the preview. The original reporter can then try the patch against their own project, and if they confirm it works, the automation opens a pull request linked to the issue. As we built this out, we kept noticing that nothing about it was really specific to GitHub. Reacting to an event, running a sequence of isolated subagents, and separating their reasoning from the actions they’re allowed to take — it’s all just a workflow. One that could run just as well from a Slack message, a cron job, or a webhook as from a GitHub issue. Generalizing that realization into a runtime that works the same way regardless of where it’s deployed, or which model it’s driving, is what became [Flue](https://flueframework.com/): an open, platform-agnostic framework for building durable agents and workflows. When we first launched this automated system, we had shared concerns about its efficacy and the potential negative impacts it might have on our developer community. There was a valid fear that relying on automated bot responses might feel impersonal and create just one more disconnect between us as maintainers and our user base. That did not happen. If anything, we talk to users more now, just in more useful places: Regarding the quality of automated patches, our core philosophy is that our AI agents should successfully resolve the vast majority of incoming issues. When an agent fails to identify a correct solution, we interpret that failure as an indicator of an underlying architectural or documentation issue within the codebase, pointing to one of three areas: A clear example occurred with a series of related Hot Module Replacement (HMR) bugs. The triage bot repeatedly attempted to modify a specific if condition to resolve the issue. While this change fixed the targeted bug, it introduced regressions elsewhere due to a lack of test coverage for that specific condition. Once we added a descriptive comment explaining the exact logic governing that statement, the bot adapted and stopped attempting incorrect modifications in that area. Every time we chase down one of these failures and add the missing comment, test, or clearer boundary, the bot gets noticeably better at that part of the codebase, and so does the next human who works on it. Initially, our triage logic lived directly within the Astro monorepo. This coupling made iteration difficult; upgrading Flue or modifying the workflow felt like performing surgery on live infrastructure without a safety net. To solve this, we decoupled the logic into a standalone, testable repository: [triagebot-action](https://github.com/withastro/triagebot-action). This isolation allowed us to introduce automated testing and ensure stability before ever touching our primary codebase. Today, this action powers issue management in Astro, and it has spread from there. Several other teams have picked it up, some using it directly, and others forking it to build their own automated "factories" tailored to their projects. That second path is really the point: triagebot-action is young and still actively evolving, so we’re sharing it less as a finished product and more as a working reference you can read, learn from, and adapt. The wiring for the action itself looks like this: Or point your own agent at the repository and have it read through the setup, including adding the labels the state machine relies on. Whichever route you take, the underlying idea matters more than our specific implementation: a sustainable feedback loop that frees maintainers to focus on the framework itself instead of administering a backlog. The code is open. Fork it, strip it down, or just borrow the parts that fit your project. **Want to build something like this? Dig into the code of the** [triagebot-action](https://github.com/withastro/triagebot-action) to see how it works, or fork it as a starting point for your own repository’s automation. And if you’re building agent-based infrastructure more seriously, that’s exactly what Flue is for: dive into the [Flue framework](https://flueframework.com/) to build your own. We’d love to see what you build. Come share your "factory" stories in the [Astro Discord](https://discord.cloudflare.com/).