Automated GitHub Actions Agent Pipeline Triggered by “Agent-Fixable” Label

[claycantrell]

I think it makes sense to implement an automated agent pipeline that, once issues are triaged to a dedicated agent-fixable label, investigates them and opens PRs with proposed fixes. I’ve found that agents can almost always resolve small issues independently, without supervision or assistance. This could be a simple, vanilla Claude Code pipeline

[claycantrell]

@julianknutsen what do you think of this idea?

[julianknutsen]

I think one of the challenges is the token cost and model availability in Github actions. Right now, I think we have a few different people that all scan new bugs and have agents fix them with local Opus 4.6 plans. Do you have any experience with how other people are using Github actions for something like this? I'd love to read up on it to see what we can simplify.

[claycantrell]

@julianknutsen I built a similar pipeline at work for RLS alerts (diagnose → open issues). For GitHub Actions, we’d likely need API-backed Claude (or Bedrock/Vertex), so spend depends on token usage. If we pilot this on an “agent-fixable” label, we can cap scope and costs. @steveyegge Worth pursuing with a small grant?

[DreadPirateRobertz]

This maps directly to how Gas Town already works — the architecture for this exists, it just needs a GitHub Actions integration layer.

What Gas Town already does:

• Beads (issue tracker) with labels, priorities, and status workflows
• gt sling dispatches beads to polecats (ephemeral worker agents)
• Polecats pick up work, execute it in isolated worktrees, and submit to the Refinery merge queue
• Witness monitors polecat health and handles failures

What a GH Actions pipeline would need:

1. Trigger: GitHub webhook on label change → agent-fixable label applied
2. Bead creation: bd create from the GitHub issue (title, body, labels)
3. Dispatch: gt sling <bead-id> <rig> to assign to a worker
4. Execution: The polecat (or crew member) picks it up via gt hook and executes
5. Result: Agent pushes branch, creates PR via gh pr create

The gap is the CI/CD trigger. Gas Town currently runs on persistent tmux sessions with a daemon (Deacon) managing lifecycles. A GitHub Actions integration would need to either:

• Option A: Spin up a Gas Town instance per action run (heavy but isolated)
• Option B: Send a webhook to a running Gas Town instance that creates the bead and slings it (lightweight, requires persistent infra)
• Option C: Skip Gas Town entirely and just run Claude Code in the action with the issue context (simplest, loses the multi-agent benefits)

For small issues, Option C is probably sufficient — a single Claude Code session with the issue body as context can handle most bug fixes. Gas Town's value shows up when you need coordination: multiple related fixes, cross-file refactors, or issues that need investigation before fixing.

The agent-fixable label triage is the real insight here. Having humans (or a triage agent) gate what goes to automation prevents the failure mode of agents spinning on issues they can't solve.

[v-good]

For anyone exploring this — Robb Walters' rjwalters/loom (Python, MIT, v0.6.5) is a working implementation of essentially this worldview, with a label state machine (loom:issue → loom:building → loom:review-requested → loom:pr) and a forge-agnostic ForgeClient abstraction unifying GitHub + Gitea behind one interface.

Their stuck-detection, review-gate, and worker role patterns (builder/judge/curator/doctor/auditor) are worth a look as reference, even if the GT-side direction ends up structurally different.

Cross-link for context: I posted a fuller comparison on the Loom side here — rjwalters/loom#3213