Skip to content
jack in the loop
← all writing
3 min read

The orchestrator I deleted after a day

I built a Claude Code mod that routed every question from every terminal through one inbox, plus a relay to my phone. It was worse than a read-only list that tells me which terminal needs me. What the mod does now, and the pieces you can reuse.

claudemodspluginsworkflow

I run five or six Claude Code sessions at once most evenings. The hard part stopped being the code a while ago. It's knowing which session is waiting on me.

The version I threw away

My first answer was ambitious. An orchestrator session, "hq", that every other session reported to: one inbox for every question. Then it learned to hold new work when my plan usage passed 90%. Then I added a relay to my phone, a background session that passed messages between my phone and hq and never decided anything itself.

It lasted about a day. A plain list that points me at the terminal that needs me did the job better than a middleman that tried to answer for me. I deleted hq and the relay, 243 lines, and wrote the rule into my global setup: ask in your own terminal; nothing routes through another session.

What replaced it

A mod for Claude Code with three parts.

A band above the prompt. In a fresh terminal it shows how full the context is, how many other terminals are blocked or working, and a row of buttons. Some start a flow (ticket, ship, a Codex review). Others fill the prompt box with a template I'd otherwise type badly: spec, plan, TDD, debug, catch up. While a pipeline runs, the band shows the stage and a one-line summary, and turns red when it's waiting on me.

A heartbeat per session. Every terminal writes a small file: folder, context use, what it's doing, what it's blocked on. A fast model writes the one-line summary of each terminal after every turn. That costs a little plan usage, and it's worth it.

The tower. One read-only terminal that lists every session: status, project, summary, time, tokens, context. Blocked is red: a question, a permission prompt, a plan to approve. One click focuses that terminal's tab in whichever editor window it lives in. The header shows my plan usage and when it resets.

That's the whole trick. The tower never answers anything. It just points.

Pieces you can reuse

A status protocol any skill can call. Skills report progress through a tiny command-line helper that writes one JSON file per session. It never fails the caller: problems go to stderr with exit code 0, so it's safe to sprinkle anywhere. Even without the mod, anything can read those files: a status line, a dashboard, another agent.

pipeline-status start ship "commit,test,pr,review,merge,deploy,verify" "Ship hub homepage"
pipeline-status stage review "Codex + code review on #47"
pipeline-status wait "need Jack's OK on a $12/mo cost increase"
pipeline-status done "Homepage live" --bullet "PR #47 merged and verified"

Prompt templates with labeled fields. The plan template, for example:

Explore before changing anything. Then give me a short plan: files to touch, approach and the alternative you rejected, risks, and how we will verify it. Wait for my go before writing code.

A status line in six lines of jq: plan usage for the five-hour window, the week, and context, always visible.

Rough edges

  • The mod is built on Claude Code's mod runtime, so it won't install on a build without it.
  • Runs that never report done stay listed as running; they go gray, but nothing cleans them up yet.
  • Focusing a tab depends on a small editor extension in every window. When it says it's switching and nothing happens, reloading the window fixes it.

The orchestrator and tracker post covers the two skills this all serves.


Drafted with Claude from the mod's source, README and git history.

Next post

An orchestrator and a tracker for Claude Code

→