buildwork
Your open issues, run as parallel agents
It reads a repository's open issues, puts one agent on each in its own git worktree, opens a pull request per issue, then runs mechanical quality control over the results 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, what conflicts with what - which is the part a human would otherwise reconstruct from a page of pull requests.
Working with or without a specific runner
Two runners ship: one drives Paseo workspaces and labelled agents, the other uses whatever worktree-capable subagent tool the host already has. Neither is required and neither is assumed.
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 may carry 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. 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. There is no watcher, no cron and no dashboard - the last of those is a job something else already does better.
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.