I built an alternative to Conductor for Claude and Codex

An open-source developer tool called Shelbi has been released as a single-binary, multi-machine agent orchestrator for the terminal, positioned as an alternative to Conductor for managing Claude and Codex coding agents. Shelbi groups agents into workspaces such as "hub" and "devbox" and shows each agent's status — idle or Developer — in one interface, with a search command (⌃P), an orchestrator view, an issues list and a changelog, aiming to replace juggling agents across terminal tabs.

Stop babysitting agents. Tired of managing agents in terminal tabs? Struggling to keep track of which one needs attention and which one's stalled? Try Shelbi, an open source, personal agent orchestrator for your terminal. open source · one binary · multi-machine my-project 🔍 Search ⌃P 💬 Orchestrator 📋 Issues 🚀 Changelog — Workspaces — ▾ hub · alpha idle · bravo idle ⏵ charlie Developer · delta idle ▾ devbox · echo idle · foxtrot idle ⏵ golf Developer ⚙ 📣 ❯ Good. Let's design the analytics dashboard we sketched last week. Sure. Starting from the mock: a metrics overview across the top, charts beneath, and a date-range filter driving the whole page. What's the headline metric? ❯ Signups, active users, and revenue — as big number tiles with week-over-week deltas. Got it. I'll have the tiles read from one /api/metrics endpoint so a single request backs the whole header row. ❯ And the charts underneath? A line chart for the trend and a bar chart for the plan breakdown. Both share the date range, so changing it re-queries once and both redraw. ❯ Add a way to pull the raw numbers out too — finance keeps asking. A CSV export scoped to the current filter, then. I'll also handle the empty and loading states so it never paints blank on first load. ❯ Perfect. Write it up so we don't lose the thread. On it. I'll draft dashboard.md — metrics API, charts, date-range filter, CSV export, empty/loading states, and tests. ⏺ Write dashboard.md ⎿ 48 lines written Done. dashboard.md covers all six. Want me to break it into tasks? ─────────────────────────────────────────────────────────────────────────────────────────────────────────────── ❯ ▊ ─────────────────────────────────────────────────────────────────────────────────────────────────────────────── Model: Opus 4.8 · Ctx 4% · Cost $0.36 · Session 3m 𖠰 hub ⏵⏵ auto mode on shift+tab to cycle Meet Shelbi This is Inbox Zero for agent work. Have an idea? Spot a bug? Simply talk to the Shelbi orchestrator agent the moment it occurs to you. The orchestrator doesn't do the work itself so it won't get derailed. Each item is written up in a standard format. Nothing small or big gets dropped. Let the agent write it up for you Tasks keep work focused. Every item becomes a scoped task before a worker agent touches it. Agents do their best work in focused chunks. The orchestrator breaks big features down into smaller tasks. Small changes flow through quickly. my-project 🔍 Search ⌃P 💬 Orchestrator 📋 Issues 🚀 Changelog — Workspaces — ▾ hub · alpha idle · bravo idle ⏵ charlie Developer ⏵ delta Developer ▾ devbox ⏵ echo Developer ⏵ foxtrot Developer · golf idle ⚙ 📣 Issues · my-project 26 total Workflow: All ▾ Workspace: All ▾ B TO DO 6 IN PROGRESS 4 REVIEW 1 DONE 3 A Cache user sessions Paginate search API Fix mobile nav Add API ratelimit C app app ⎇ jlong/t-038 app ⎇ jlong/t-008 app K L Wire webhook retries Trim vendor bundle Dedupe error reports O app app ⎇ jlong/t-022 app G Split OTel spans Backfill order index Prune stale flags 12 app app ⎇ jlong/t-017 app Sync i18n strings Migrate CI to arm64 app app ⎇ jlong/t-014 Add health probes app Debounce autosave app h/l col j/k row ⏎ open ⇧h/⇧l move col ⇧k/⇧j reorder ⇥ workflow f filter Agents provide specialization. Workers build the code. Reviewers scrutinize it: QA, Security, and Adversarial Review ship in the box, each doing one job well. Tailor any of them with custom instructions and skills, or author your own. 1 Adversarial Review 2 3 You are an adversarial code reviewer. A developer 4 agent has finished a task and believes its branch is 5 ready. Your job is not to confirm that belief — it is 6 to try to prove the change is wrong before a human 7 spends attention on it. Assume there is a bug until 8 you have looked hard enough to say otherwise. 9 10 What to review 11 12 Review the diff on the current task's branch against 13 the base branch — only what this task changed, plus 14 the code that change touches. You are looking for 15 defects the developer and the tests missed, not for 16 style nits the preamble's checks already cover. 17 18 How to review 19 20 Work through every changed hunk and actively try to 21 falsify it: 22 23 - Correctness — Does it do what the task asked? Trace 24 the non-obvious paths by hand. Off-by-one, wrong 25 operator, inverted condition, a branch that silently 26 does nothing. 27 - Security — Untrusted input reaching a query, a 28 shell, a path, or a template. Missing authz checks. 29 Secrets in logs or errors. Unsafe defaults. 30 - Error handling — What happens when the call fails, 31 the input is empty, the list is huge, the value is 32 null, two requests race? 33 - Edge cases — Boundaries, empty and maximal inputs, 34 concurrency, encoding, time zones — whatever this 35 code plausibly meets in production. 36 - Test coverage — Do the tests actually exercise the 37 new behavior, or do they assert around it? Find a 38 real input the change gets wrong that no test would 39 catch, and treat that as a finding. 40 41 How to report 42 43 Write your findings as a structured review on the 44 branch — a markdown Adversarial Review section, per 45 this project's convention. For each finding: 46 47 - Severity — blocker, major, or minor. 48 - Location — path/to/file.rs:120 or a range . 49 - The problem — what breaks, and the concrete input or 50 sequence that triggers it. A finding with a repro 51 beats a vague worry. 52 - Suggested fix — one line, when the fix is obvious. 53 54 Order findings by severity, blockers first. 55 56 Signing off or bouncing 57 58 Every review ends one of two ways. Decide from the 59 highest-severity finding. If nothing rises to a 60 blocker, sign off and hand off forward. If any finding 61 is a blocker, write up the findings and bounce the 62 task back to the developer. Workflows provide boundaries. Every task moves through stages you define before it reaches you. Boundaries are what make autonomy safe. When your gates catch what you would, flip shelbi zen on and the orchestrator merges green work itself, then reports what landed and what needs you. 1 name: feature 2 description: 3 A full app feature, from idea to merged. A 4 developer builds it on a branch off main; then 5 adversarial review, QA, and security each gate 6 it before a human signs off and it merges. 7 8 initial status: backlog 9 10 statuses: 11 - { id: backlog, owner: user } 12 - { id: in-progress, owner: agent, agent: developer } 13 - { id: agent-review, owner: agent, agent: adversarial } 14 - { id: qa, owner: agent, agent: qa } 15 - { id: security, owner: agent, agent: security } 16 - { id: review, owner: user } 17 - { id: done, owner: user } 18 19 transitions: 20 - { from: backlog, to: in-progress } 21 - { from: in-progress, to: agent-review, actions: push branch, open pr } 22 - { from: agent-review, to: qa } 23 - { from: qa, to: security } 24 - { from: security, to: review } 25 - { from: review, to: done, actions: merge, delete branch } 26 27 git: 28 base branch: main 29 merge strategy: squash ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Features - Kanban TUIKanban board - Every task is a card on a board in your terminal, so status is on screen instead of in your head.Every task is a card on a board, so status is on screen instead of in your head. - Workers on any machine - Any box you can SSH into can take tasks. If it has git and an agent CLI, it's a worker. - Attach from anywhere - Every worker runs in its own Shelbi session. Attach from any terminal to watch an agent work or type to it directly. No terminal multiplexer required. - Review flow - Finished tasks land in the review column and wait for you. Assign a review agent to any column to hold every task to the same bar. - Plain-file state - Tasks are markdown and workflows are YAML, stored in your repo. No database, no cloud, just files you can read, grep, and commit. - Open source - The whole system is MIT licensed on GitHub. You can read every line that runs on your machines.