Pullboard puts a verifier agent between a builder agent and the merge

An agent that says the work is done is a sentence, not a check. Pullboard, published this week at 94 stars on GitHub, puts a second agent between the first one and the branch that ships. The build has to pass a test the owner approved, on the exact commit, before any work merges.

The project is a node package called pullboard under the MIT license. The author uses it to build the quantitative systems the project page describes, and the npm package is at version 0.8.7 and installs globally with no account to create.

What the setup files are

Two files sit at the root of the repository. SPEC.md holds one requirement per row: an id, a status, a priority, what has to be true, and the test that proves it. A row stays a draft until the owner marks it approved. DOCTRINE.md holds the rules the repository works to, each with the git hook or review step that enforces it. The owner edits both files; nothing else is a contract.

A third file, pullboard.json, sets the lanes and the gate. A lane is a worktree the agent works in, so two agents never share one file. The gate is the command that must exit zero before an agent is allowed to submit.

How a piece of work moves

The owner adds an item that names the spec rows it serves and the acceptance test it needs to pass. A builder agent in a lane claims the item, which freezes the test. The builder opens the lane as a git worktree, writes code there, runs the gate, and submits the commit it produced. A separate verifier agent that built none of the code checks out that exact commit, runs the test, and accepts with a note on what it saw or rejects with a reason. An accept merges the commit. A reject sends the work back to the lane.

The receipt is written down. The repository's own board shows the reject reason, the fix commit, and the second verdict as one entry, so a reader can see why the item is now in the branch. The project page says "nearly one in three items goes back" through this loop when the author uses it on this codebase.

What the owner sees

Pullboard ships a local web board called Pullboard View that runs on the machine. One column shows the calls the agents cannot make: a draft row to approve, a question an agent sent up the chain, a lane held waiting on another lane. A timeline shows every claim, submit and verdict in order. The board reads the files on disk, so a plain text editor still works, and view --export writes a static copy a reviewer can replay later.

The owner's working style is "one agent to rule the others". A single coordinator agent, in a Claude Code session or similar, reads the spec with the owner, files items into lanes, runs the builders and verifier through pullboard commands, and only passes a decision up when the item needs the owner's judgement. The point of that shape is that the owner never explains the same preference twice: it goes into the doctrine the first time, and the enforcer catches it after that.

Source

pullboard-dev/pullboard on GitHub, pullboard on npm, and the project page.