Driving a 5-Year-Old Repo to Zero Open Issues
The Astro maintainers have spent the past several months running an automated triage pipeline directly on their repository. The system reads incoming bug reports, spins up sandboxes to reproduce them, diagnoses root causes, and posts preview releases for reporters to verify. The result: open issues dropped from over 200 to roughly 30, with a path to zero — a first in the project’s 5+ year history.
The underlying engine, now open sourced as Flue, grew out of a need to automate one of the most draining parts of open source maintenance: issue triage. A single issue can take hours to reproduce, let alone fix. The team started by building a local agent skill that mirrors the exact manual workflow: clone and reproduce, instrument and diagnose, verify against tests and documentation, then fix by writing failing tests and deploying a patch.
A State Machine Driven by Labels
Each phase is handled by an isolated subagent that passes findings forward via a report.md file — a deliberate design to prevent the LLM from forcing a fix when a bug isn’t real. After local testing, the team wired the skill into a GitHub Action and quickly realized the entire pipeline reduces to a simple state machine controlled purely by issue labels.
New issues start with a triage needed label; user confirmation moves a ticket to fix verified. No other state is stored. The system reconstructs where an issue stands by reading the comments already on the thread. From there, the flow is fully automated: when agents converge on a patch, the pipeline publishes a preview release via pkg.pr.new, posts a summary with logs and installation instructions back to the issue, and opens a linked pull request once the reporter confirms the fix works.
Early Fears Didn’t Materialize
The team expected the bot to feel impersonal and create distance between maintainers and their community. It didn’t. Maintainers now spend time in Discord, participate in RFC discussions, and work with contributors on feature integration instead of grinding through ticket cleanup.
Where Agent Failures Point
There’s a core philosophy at work: when an agent can’t resolve an issue, it’s usually a signal of a real deficiency in the code itself. The failures come in three categories:
- Opaque abstractions: If an agent can’t see component boundaries, neither can a human.
- Missing documentation: Critical code lacks comments explaining the rationale.
- Insufficient tests: Particularly unit tests around edge-case conditions.
A concrete example came from Hot Module Replacement (HMR) bugs. The bot repeatedly tried to flip a specific if condition, which fixed the reported bug but broke unrelated behavior. After the maintainers added a comment explaining the logic behind the statement, the bot stopped attempting that modification — proof that the fixes compound. Each added comment, test, or clearer interface improves the bot and the next human contributor.
Decoupling Workflow from Repo
The triage logic initially lived inside the Astro monorepo, which made iteration risky. The team extracted it into a standalone, testable repository: triagebot-action. That gave them automated testing and stability before changes ever touched the primary codebase.
Other teams have now picked it up, either using it directly or forking it for their own factory-style pipelines. The action wiring looks like this:
- uses: withastro/triagebot-action@v1
with:
read-token: ${{ secrets.GITHUB_TOKEN }}
write-token: ${{ secrets.BOT_GITHUB_TOKEN }}
cloudflare-api-key: ${{ secrets.CLOUDFLARE_API_KEY }}
cloudflare-account-id: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
triage-model: cloudflare-workers-ai/@cf/moonshotai/kimi-k2.7-code
verification-model: cloudflare-workers-ai/@cf/moonshotai/kimi-k2.6
triage-skill: .agents/skills/triageTeams can also point their own agents at the repo to read through the setup — including the labels the state machine relies on.
Generalizing Beyond GitHub
The team kept noticing the pattern wasn’t GitHub-specific. Reacting to an event, orchestrating isolated subagents, and separating reasoning from permitted actions is a generic workflow — equally at home behind a Slack message, a cron job, or a webhook. That generalization is what birthed Flue, an open, platform-agnostic runtime for durable agents. The triage skill runs locally on maintainer machines, in a GitHub Action, or anywhere else with the same behavior.
Ultimately, the Astro team frames this as a sustainable feedback loop: agents free maintainers from backlog administration, and agent failures expose genuine code health issues that, once fixed, improve both the bot and the codebase. The code is open — fork triagebot-action as a starting point for your own automation, or explore Flue to build something more custom from the ground up.
