How we built a software factory to drive Astro’s GitHub issue count to zero

The unit of work in this pipeline is the issue, and the unit of execution inside it is the isolated subagent, and that nesting is the design choice worth keeping. The reproduce, diagnose, verify, and fix steps are each given a separate agent with its own context, and the only thing that crosses the boundary between them is a report.md file written by the previous agent. The author attributes the design to a specific failure mode of single-agent runs: the model treating 'there must be a bug here' as a constraint it has already accepted. Splitting verify off into its own pass, with no memory of the reproduction effort, gives that pass a chance to return 'intended behavior' and short-circuit the rest of the pipeline. For engineers copying the pattern, the implication is that the failure surface of any agent system is concentrated at the handoff, so the handoff artifact is the thing to invest in.

The pipeline deliberately holds no internal state, and instead reads the issue's existing labels and comment history to decide what to do next. The two labels called out explicitly, 'triage needed' and 'fix verified', are the entire state machine. The practical consequence is that any maintainer, or any curious user, can audit what the agents did by reading the issue, with no separate dashboard, database, or log store to reconcile. This is also why pkg.pr.new fits cleanly: the preview release is a side effect tied to a label transition, and the pull request is opened only after the reporter confirms the patch, which means the human-in-the-loop gate is an issue comment rather than a feature hidden inside the framework.

Adopting this is not free, and the post is candid that the result took iteration. The triage skill began as a local harness the maintainers ran on their own machines and was only later promoted into a GitHub Action, so a team attempting a similar build should plan on a development loop where humans run each phase before it is automated. The reproduce step requires the reporter to have supplied a runnable reproduction repository, which is an input constraint the pipeline does not relax. Preview distribution depends on pkg.pr.new, and the audit guarantee depends on the maintainers keeping the triage labels visible on the public issue, so the cost is concentrated in label discipline and a working preview-publishing path rather than in model access.

It is worth being precise about what this does and does not prove. Only one feed carried the story, so any engineer reading should treat it as a first-party case study from the team that built it, not corroboration. The author explicitly narrows the scope to triage and explicitly notes earlier attempts to generalize were not instant successes, which means the result is strong evidence for the narrow claim (driving an issue queue to zero through automated triage plus reporter confirmation) and weaker evidence for the broader claim that 'software factories' produce working software end-to-end. The fix step still depends on an existing architecture guide and existing test conventions inside the Astro repo, so the pipeline's reach outside that repo is unproven.

The framework name dropped at the end, Flue, is the part of the write-up that points past the case study. The author frames the GitHub integration as one deployment surface of a more general shape: an event arrives, a sequence of isolated agents runs against it, and the reasoning is separated from the side effects. If that abstraction holds, the same pipeline could be triggered from a Slack message, a cron job, or a webhook with no changes to the agent definitions. For a working engineer, the open question is whether Flue is thin enough to be useful out of the box or whether its value is really the reference architecture in this post, and that is something the documentation, not the case study, will have to answer.