Autobuildgithub.com/defrex/autobuildGitHub

Tickets in,
Product out.

Autobuild runs coding agents through a fixed pipeline that plans, implements, reviews, and verifies every ticket before it merges.

$ bun add -g @defrex/autobuild
View on GitHub
example/webappoperator ▾
queue 1 · active 4/6 · observations 7/20intake ON auto merge ON harvest ON14:02:31
>AUT-412add-retry-budgetRUNNING
[x] spec(2s)[x] plan(48s)[x] plan-review(1m02s)[>] implement(4m12s)[ ] code-review[ ] verify:*[ ] finalize
AUT-415split-store-migrationsRUNNING
[x] spec(3s)[x] plan(1m10s)[x] plan-review(2m40s)[x] implement(9m03s)[x] code-review(3m11s)[>] verify:test(38s)[ ] finalize
AUT-407export-csv-endpointPR #88RUNNING
[x] verify:*(4m30s)[x] finalize(52s)[>] merge(waiting, 8m47s)
AUT-409cache-invalidation-raceESCALATED
[x] plan(40s)[x] plan-review(55s)[x] implement(6m50s)[>] code-review(round 4)
! review-round ceiling reached: reviewer and implementer disagree on lock order
AUT-418dark-mode-settingsQUEUED
[ ] spec[ ] plan[ ] plan-review[ ] implement[ ] code-review[ ] verify:*[ ] finalize
autobuild · how it works

Every ticket runs the pipeline

Each ticket moves through deterministic phases inside its own build-runner. Every phase is a fresh agent session, with artifacts knitting them together.

inside one build-runner
spec
plan
plan-review
implement
code-review
verify:*
finalize
merged
revise
revise
verify fails → back to implement
autobuild · the map

A dispatcher spawns builds

The dispatcher claims ready tickets and starts a build-runner for each. Runners are isolated, all state is logged.

build-runner
[>] plan-review
ab
build-runner
[>] implement
ab
build-runner
[>] verify:*
ab
ready tickets
ticket
ticket
ticket
dispatcher
one agent session per step
build store
events
artifacts
streams
agents write through the ab CLIrunners write phase events
autobuild · seams

All local, all remote, or anywhere between

Every seam is an adapter you can customize for your project. The build pipeline stays the same.

fully local
tickets
where work comes from
+ plugin
dispatcher
what starts builds
workspace
where a build runs
+ plugin
runtime
who does the thinking
+ plugin
forge
where code lands
+ plugin
store
where state lives
+ HTTP protocol
operators
how you watch
autobuild · throughput

Built for throughput, not latency

One build may take longer than a chat with an agent. The trade is far more changes landing every day, and with much greater reliability.

File it and walk away

Nothing in the pipeline waits on you. You don't approve tool calls, paste errors back, or watch a terminal.

As many builds as you can groom

Builds run side by side, each in its own workspace, up to the limit you set. Your attention stops being the ceiling.

autobuild · intake

Let the queue fill itself

Once tickets are the interface, anything that can write a ticket can put work in front of you.

customer support
meetings
telemetry · errors
build observations
PM agent
persistent memory
any agent harness
autobuild
dispatcher
you
tickets
escalations, answered by the agent
only the real product calls
autobuild · get started

Start with one ticket

$ bun add -g @defrex/autobuildinstall the ab CLI
$ ab initvendor the skills, write autobuild.toml
$ ab dispatchstart the dispatcher and the dashboard
> /ab-spec add a retry budgetgroom a ticket in your coding agent