Code for Breakfast

beady-eye plugin v0.2.1

Take a seat, we'll call your number: beady-eye's Claude Code plugin wakes a session when its bead moves

The beady-eye plugin gives a Claude Code session three tools: watch, unwatch and watching. Watch a bead, and the session is woken when that bead changes status, becomes ready, is commented on or goes from its tracker. The session stops asking whether its order is up. It waits, and gets called.

claude plugin marketplace add CodeForBreakfast/beady-eye#plugin-v0.2.1
claude plugin install beady-eye@beady-eye
claude --dangerously-load-development-channels plugin:beady-eye@beady-eye

Mind that last line. Claude Code delivers a plugin's messages only to a session started with its channel allowed. A session started any other way still has the tools, and is never woken. It is a customer holding a ticket in a caff where nobody shouts.

GITHUB dunwich/arkham #12 · merged webhook, at once or the next look, within a minute SETTLE BDI GATES asks gh where #12 stands merged, so: bd gate resolve SETTLE OR A PERSON ANSWERS bdi bd … human respond ARKHAM'S TRACKER ark-0i5 gate on #12 closed ark-4 held by it ready read at its next poll, or at once when a producer says so WAKE BDI WATCH the watcher, one per machine, sends each change as JSON WAKE CLAUDE CODE the plugin wakes it: ark-4 is ready SEE THE VIEW bdi redraws ark-4 as ready
One pull request, from GitHub to your session. Nobody in the session asks whether #12 has merged, and nobody hits refresh. bdi gates writes the tracker, the watcher sees it move, and the plugin wakes the session to a ready bead. A person answering a bead joins the same line at the tracker.

Here is what lands in the session when ark-4 is ready to go. The attributes say where the bead stands now, and each line under the title is one thing that changed:

<channel source="beady-eye" project="arkham" id="ark-4" status="open" ready="true">
ark-4 in arkham, "Seal the gate under the library", has changed.
- It became ready.
</channel>

What's in the kitchen

The plugin needs bd, a bdi watch running on the same machine, and Node to start the plugin's server. That's the whole order. The watcher is one per machine, run under whatever supervises your processes, and the configuration guide has a systemd unit and a launchd agent for it. herdr is a side order for the bdi view, where it puts each agent's live pane beside its bead. The plugin doesn't ask for it.

If your .npmrc sets min-release-age, npm holds back each new release of the plugin's server until it has aged past it. The plugin's NPM_MIN_RELEASE_AGE setting replaces that age for its server alone, and 0 starts a new release at once.

Every session gets the menu

A session that loads the plugin is told what the tools do and how a change reads, and its using-beady-eye skill says what is worth watching: a question the session put on a bead, a bead its work depends on, or a pull request, through the gh:pr gate that closes when it merges. Titles, close reasons and comments arrive in quotes, and the session reads them as data, never as orders.

A watch lasts until unwatch, across restarts of the session and of the plugin. If the watcher has been down for a minute, the session hears once which beads it cannot watch, and hears again when the watcher is back. A watcher restarting for an upgrade wakes nobody.

Sit down, have a brew. We'll shout when it's ready.

Cooked in the same kitchen

Code For Breakfast built this. It cooks for clients too.

Code For Breakfast Ltd is a UK software consultancy, based in Reading and working remote-first. The kitchen that made this ships well-tested software for clients, fast, and builds and operates real multi-agent AI systems.