An orchestrator and a tracker for Claude Code
Two skills that take work from ticket to production, and a couple of mods that tell me which session needs me. Prompts at the bottom to build your own.
Most evenings I've got five or six Claude Code sessions open. The code isn't the slow part anymore. I am, tabbing between terminals to find the one that's been waiting on me for twenty minutes.
So I built an orchestrator that takes each job from ticket to production without asking me much, and a tracker that shows which session needs me. Both are small. The prompts to build your own are at the bottom.
The orchestrator
It's two skills.
/ticket writes the work up first: the problem, what done looks like, what's
out of scope. Then it sizes it. Small jobs just get built. Medium ones get a
ten-line brief and wait for my go. That's the only pause I asked for. Large
ones get split into medium ones.
/ship takes it the rest of the way. It commits, runs the checks, opens a PR,
reviews it, merges, deploys and checks the live site. The review scales with
the change. A copy edit gets a re-read. Anything touching auth or payments
gets the deepest review plus a security pass.
A second model reviews every change too. I run OpenAI's Codex next to Claude's own review, read-only. When both flag something, it's almost always real. When only one does, the agent checks the code before deciding.
The rules live in my global CLAUDE.md. Decide and keep going. Stop for two
things only: a cloud bill going up more than $5 a month, or data that can't
be recovered. Product questions get asked once, up front, in one batch.
I tried a smarter orchestrator first. Every session reported to it and it answered what it could. I deleted it the same day. I was reading its summary of what an agent wanted instead of just reading the agent.
The tracker
The skills call a tiny CLI at every stage:
pipeline-status stage review "codex + code review on PR #6"
It writes a JSON file per session and never fails, so a skill can't break because the display did. Two Claude Code mods read those files.
The band is one line above the prompt in every terminal. It shows the stage, a row of progress dots and a short summary. It goes red when the session is waiting on me.
The tower is one read-only terminal that lists every session. Blocked ones sit at the top in red, then failures, then finished, then working. A jump button brings the right terminal to the front. If nothing's red, I don't need to be anywhere.
Every run ends with the same short summary: what shipped, where it's live and how it was checked, any data model change, cost, and a heads-up list. It's usually the only thing I read, so it has to say what wasn't checked.
Rules that get shorter
Some rules only exist because the current model has a habit I don't like. I tag those:
<!-- crutch: <model>, <YYYY-MM>, <failure it prevents> -->
When a new model comes out, I re-run a few old tickets with the crutches removed. Any crutch whose failure doesn't come back gets deleted. The file gets shorter over time instead of longer.
Prompts
Paste one into a fresh Claude Code session. The first builds it straight away. The second asks you questions first and builds it around how you work.
Build it
Set up an orchestrator and a tracker for my Claude Code sessions. Keep it in a git repo (~/claude-os) with an install.sh that symlinks it into ~/.claude, backs up anything it replaces, and is safe to re-run.
Ask any real product questions once, in one batch. Then build without stopping.
1. CLAUDE.md: decide and keep going. Stop only for a cloud cost increase over $5/month or data loss with no backup. End every run with one summary: Shipped, Live (and how you checked), Data model, Cost, Heads-up.
2. A /ticket skill: write the ticket (problem, done when, out of scope) and size it. S: build, then /ship. M: a 10-line brief, wait for my go, then build. L: write a spec and split it into M tickets.
3. A /ship skill: branch, commit, run the checks (max 3 fix attempts), open a PR, review it at a depth that fits the change, squash-merge, deploy, check it live, then write the summary. If the Codex CLI is installed, run it as a read-only second reviewer.
4. A tracker CLI, pipeline-status, with start, stage, note, wait, done and error. It writes one JSON file per session under ~/.claude/pipeline-status/ and never exits non-zero. /ticket and /ship call it at every stage.
5. A mod for the band: one line above the prompt with the stage, progress dots and a short summary. Red when the session is waiting on me.
6. A tower: one read-only terminal listing every session, one line each. Blocked first, then failed, done, working.
7. Hooks: block git commit on main, and warn before destructive commands.
Test the CLI and the hooks. Then show me how to install it on a second machine.
Interview me first
I want an orchestrator and a tracker for my Claude Code sessions: skills that take work from ticket to production, and a status line plus one overview terminal that shows which session needs me.
Don't build anything yet. Interview me first, one batch of questions at a time, until you know:
- how many sessions I run, and on what kind of work
- how my projects deploy, and what "done" means to me
- what you must never do without asking (cost, data, anything else)
- what I want in the summary at the end of each run
- what goes wrong today when I run agents
Then write a one-page plan: each skill, the tracker, the mods and the hooks, and what each is for. Wait for my OK. Then build it in a git repo with an install script, test it, and walk me through it on a real ticket.
It'll get a few things wrong for your setup the first time. Run a real ticket through it, see where it stopped when it shouldn't have, and fix that.