Vision

Running one coding agent is a conversation. Running six is an operations problem, and terminal
tooling was not built for it. You lose the thread of which agent is waiting on you, which has
been idle for an hour because it finished, and which is quietly burning tokens down a path you
would have stopped.

shefrd treats that as the actual product. Agents are not tabs you remember to check; they have
states, and the interface is built around showing them. Something blocked and something done
look different from across the room, and getting from a status to the pane that explains it is
one movement.

Where it came from

shefrd is a hard fork of herdr, Apache-2.0, maintained as a
thin patch layer on upstream so improvements keep flowing in. Every herdr plugin runs here
unmodified, and that compatibility is a hard requirement rather than a goal: the socket API, the
manifest format, the environment contract and the config directory are all deliberately
untouched.

Where it is going

Two things distinguish it from upstream.

The first is that features are built in and reviewed, not installed. The plugin ecosystem
solved real problems, and it solved them by asking every user to trust a stranger's code with
their terminal, their agents and their repositories. shefrd absorbs those capabilities as
first-class features, each one reviewed by several independent agents before it ships, so
turning one on is a toggle rather than a supply-chain decision. A feature you leave off costs
nothing at all, which is the part that has to be true for this to be the better deal.

The second is the renderer. Every ceiling this fork has hit is the same ceiling: it is a guest
inside somebody else's terminal. Image previews need a graphics protocol the host may not
implement. A real browser view inside a pane needs pixels the multiplexer cannot draw. Owning
the renderer dissolves all of it at once, and that is what the desktop app is for.

shefrd Changelog