buildwork
Your open issues, run as parallel agents
It asks what you are trying to get done, picks the open issues that goal is about and shows you the list, then puts one agent on each, a few at a time, in its own git worktree with its own pull request. It runs mechanical quality control over the results, checks them for conflicts with trial merges that merge nothing, and proposes an order to merge them in. It never merges, and it refuses to fan out when the issues are really one piece of work.
Install buildwork
Add the DBHQ marketplace, once
/plugin marketplace add dbhq-uk/marketplaceInstall the skill
/plugin install buildwork@dbhq
Both commands work in Claude Code and in Codex. The marketplace is a public repository you can read first: dbhq-uk/marketplace (external site)
What it is good at
Giving every issue its own worktree
Agents working the same checkout overwrite each other, and the damage is invisible until a diff makes no sense. One worktree and one branch per issue means a failed run costs exactly that run, and the work can be read as a pull request like anyone else's.
Refusing to fan out when fanning out is wrong
One issue, or several issues that are the same piece of work, gets a refusal and a reason rather than three agents and three conflicting branches. Declining is a correct result, not a failure to try.
Proposing a merge order rather than a list
The output is an order with a reason per position - what has to land first - and a note naming any branches that conflict, and in which files, found by trial merges that merge nothing. That is the part a human would otherwise reconstruct from a page of pull requests.
Running through Paseo or the host's own subagents
Two runners ship: one drives Paseo workspaces and labelled agents, the other uses the host's own worktree-capable subagent tool. It needs one of them and never guesses which. Under Codex it needs Paseo, because Codex subagents share one working directory and cannot have a worktree each.
Being opt-in per repository
It acts only where a committed config file in the repository says it may. No file, no action - so pointing an agent at somebody else's checkout does nothing.
What it does not do
It does not merge, and has no merge verb
There is no merge command anywhere in it and no push to a base branch. Where merging to the default branch is the deploy, that absence is the only thing between an agent and production.
It does not close issues
A worker's pull request carries Closes #N, and GitHub closes the issue when a human merges. The skill itself never closes anything.
It does not catch semantic conflict
One agent writes a helper, another changes its signature, neither branch is broken alone and the merge is. Its trial merges show only that git can combine the text. Mechanical quality control is a floor, and the tool says so rather than implying its gate is a review.
It does not run on a schedule
Every pass is on demand and nothing polls. The one timer it may set is an optional watchdog under Paseo, which fires once, 45 minutes after a wave goes out, to catch an agent that died without a word. There is no dashboard - that is a job something else already does better.
It does not sandbox the gate
The gate command runs a worker's branch, its tests and anything they reach, on your machine as you, with your gh login, before anyone has read the diff. On a repository that takes issues from outside, run the gate in a container with no network, or leave it unset.
Read it before you install it
Every line is public and MIT licensed. The README is the long version of this page, including the parts that are still rough.