# herdr-projects: a work board that runs one coding agent per task

> Herdr Projects puts a list of tasks in front of you, turns what you type into delegated work, gives every task its own agent in its own git worktree, and has a second agent review the result before you approve the merge. It is a plugin for Herdr, it runs on your own machines, and it needs Herdr 0.9.3 or later.

**eliasstravik/herdr-projects** — Mission control for Herdr: run dozens of coding agents from one board. Each works on its own branch, a second agent reviews it, and you see what needs you.

- Repository: https://github.com/eliasstravik/herdr-projects
- Website: https://herdr.dev
- Stars: 889 · Forks: 80
- Language: Rust
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/eliasstravik-herdr-projects

## The board is a coordinator, not the engine

The division of labour is the first thing to understand. Herdr Projects is described as mission control for Herdr: one list of tasks, yours and the ones you delegate. Herdr is the engine, the board is the overview and a remote control. You type what needs doing and the board's own agent, the Coordinator, turns it into tasks. Each delegated task then runs as an ordinary Herdr agent in its own space and worktree, gets checked and reviewed by a second agent when it finishes, and waits for your yes before it merges. The board shows which tasks need you, which are ready to approve, and which are still working. That is a coherent design for a specific problem. Managing several coding agents by hand means keeping track of branches, contexts and check results in your head, and the board is the piece that turns that into a list you can read at a glance.

## Isolation is per worktree, so your checkout stays clean

Each delegated task gets its own agent in its own Herdr space, on its own branch in a git worktree, or in a plain folder when there is no repository. The consequence the README highlights is that your checkout is never touched. This is the mechanism that makes parallelism safe rather than merely convenient. If each agent committed into your working copy, ten agents would collide on the same files and the same index, and the first thing you would lose is the ability to tell which change came from where. Here, every agent has a branch that you can inspect, diff and throw away. The comparison table also lists that the board keeps every branch up to date with main, which addresses a different failure mode. Without that, a task started last week would be building against a stale base, and its finished work would conflict with everything that landed in the meantime. Where there is no repository at all, the fallback to a plain folder means the same board mechanism still works for a task that is not code.

## Five board groups, ordered by what needs you

The board's list holds tasks in five groups, in the order they need you: needs you, ready to approve, working, to do and done. The header counts them with a format like 3 need you, 1 ready, 2 working, and each row says who is on it, where it stands, its review round and pull request, and a percent and time to go. Herdr's own sidebar carries a small copy of each live agent's row, so the same information is visible from any space without opening the board. With the Herdr web UI the board is on your phone as well, and Alt+M shows the tasks of your other machines. That last point matters more than it sounds. The alternative to a shared board is that you find out about a blocked agent by opening a terminal on the machine where it is running, which in practice means finding out hours later. The five-group ordering is the core idea of the product in one line: the board is sorted by the order in which it requires a decision from a human, not by the order tasks were created.

## One keystroke separates planning from full parallel dispatch

The interaction model is worth reading closely, because it is where the design decisions are. You type what needs doing and press Enter, and the Coordinator, described as one long-lived agent chat, makes it into a task or several. Send it with Tab instead and every task it adds gets an agent at once. Each agent starts on Claude Code, Codex, pi or another agent Herdr supports, with the task and the board's rules, in a worktree of its own. The same Coordinator can be asked for a plan first, for several attempts with one kept, for limits on time and tokens, or for automations that add tasks on a schedule. That last one is the feature that turns the board from a one-shot delegation tool into something that keeps a backlog moving without you. The trade-off is that the Coordinator is an agent, so the decomposition of your request into tasks is a model decision, not a deterministic one. The board's rules are passed to each agent, which is how the same rules apply to every task.

## Nothing merges until a second agent has looked at it

The finish line is where this differs most from briefing agents by hand. When an agent finishes, its work is committed, main is merged in, the repository's check runs, a draft pull request opens, and a second agent reviews it. A failed check or a review goes straight back to the agent. Work that passes waits for your Ctrl+L. If the board is closed, a small keeper process does the same job. So there are three layers of review, and only the last one is a human. The repository's own check catches the mechanical failures, the second agent catches the plausible-looking mistakes that a check cannot see, and you catch the ones that need judgement about intent. The README's comparison table credits this second-agent review as something neither briefing agents by hand nor a single long agent session nor a cloud projects product gives you. The obvious cost is latency and token spend, since every finished task now costs a second model run before you even look at it.

## Installing it is one plugin command and no toolchain

The setup is three steps, and the first one is deliberately frictionless. The install step runs herdr plugin install eliasstravik/herdr-projects, which downloads the one program for your platform, with no Node and no npm required. Then you open the board, either with the plugin's own action called Open the work board or with herdr plugin action invoke open --plugin herdr-projects in a Herdr pane, and its first screen offers a key that opens it from anywhere in Herdr. Third, you press Enter and the Coordinator makes it a task, or Tab for parallel dispatch, and the question mark shows everything else you can do. The supported platform list is macOS and Linux, requiring Herdr 0.9.3 or later, and the project states it is free and MIT licensed and runs on your own machines with no hosted service. Updating is also a command:

```bash
herdr-projects update           # put the newest release in place of the program
herdr-projects update 1.2.0     # a given version
```

An open board and the keeper see the new program and load it themselves, once nothing is half typed and no agent is held up, which is a small detail that avoids swapping a binary out from under a running process.

## Rust crates stacked so a change rebuilds only what is above it

The program is written in Rust, with a Cargo.toml that marks the package as unpublished and the workspace version at 1.2.9 on edition 2024. The layering is documented in a comment in the manifest itself. There are four crates in the workspace members, sw-core holding the data and the Herdr integration, sw-flow holding the flow of a task, sw-board holding the board's screen, and sw-web holding the board in the Herdr web UI, plus the root crate with the command line and the generated pages, which the tests use under the name sw. The stated reason is that a change builds again only its own crate and the ones on top of it. The user interface is a ratatui terminal interface with crossterm, with ratatui declared without default features, and state is handled with serde and serde_json configured with preserve_order and float_roundtrip, the latter so that a number read back from a saved file is the number written, which matters when a closing note's time is compared exactly. The repository also carries a package.json whose only job, as its own description says, is to give every agent the one command that runs the tests.

## Conclusion

Adopt herdr-projects if you already run coding agents through Herdr, you want parallel tasks each isolated in a worktree, and you would rather review finished work than brief every agent yourself. Do not adopt it if you need the system to run with none of your machines switched on, because the board is local by design, or if you want a cloud-hosted agent product, since that is the one column the comparison table marks against it. Before you commit, confirm you have Herdr 0.9.3 or later on macOS or Linux, read docs/agents.md to see which agent CLIs are supported on your side, and plan for the fact that nothing merges until you answer, because every finished task waits for your approval.

## FAQ

### What is herdr-projects?

It is a plugin for Herdr that acts as mission control for coding agents: you type what needs doing, the Coordinator turns it into tasks, and each task runs as an ordinary Herdr agent in its own space and worktree. It is MIT licensed, runs on your own machines with no hosted service, and supports macOS and Linux with Herdr 0.9.3 or later.

### How do I install and open the herdr-projects board?

Run herdr plugin install eliasstravik/herdr-projects, which downloads the single program for your platform with no Node or npm needed. Then open the board with the plugin's Open the work board action, or with herdr plugin action invoke open --plugin herdr-projects in a Herdr pane.

### Does herdr-projects merge agent work automatically?

No. The work is committed, main is merged in, the repository's check runs, a draft pull request opens and a second agent reviews it. A failed check or review goes back to the agent, and work that passes waits for your Ctrl+L before you approve it.

### Which coding agents can herdr-projects dispatch work to?

Each agent starts on Claude Code, Codex, pi or another agent Herdr supports, with the task and the board's rules. The repository documents the supported agents in docs/agents.md, and you can also request a plan first, several attempts with one kept, or limits on time and tokens.

## Sources

- [eliasstravik/herdr-projects on GitHub](https://github.com/eliasstravik/herdr-projects)
- [License: MIT](https://github.com/eliasstravik/herdr-projects/blob/main/LICENSE)
- [Project website](https://herdr.dev)
- [README](https://github.com/eliasstravik/herdr-projects/blob/main/README.md)
- [Releases](https://github.com/eliasstravik/herdr-projects/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/eliasstravik-herdr-projects