{"slug": "i-built-an-alternative-to-conductor-for-claude-and-codex", "title": "I built an alternative to Conductor for Claude and Codex", "summary": "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.", "body_md": "# Stop babysitting agents.\n\n## 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.\n\nopen source · one binary · multi-machine\n\n```\n \n my-project \n \n \n 🔍 Search ⌃P \n \n \n 💬 Orchestrator \n \n 📋 Issues \n \n 🚀 Changelog \n \n \n — Workspaces — \n ▾ hub \n · alpha idle \n · bravo idle \n ⏵ charlie Developer \n · delta idle \n ▾ devbox \n · echo idle \n · foxtrot idle \n ⏵ golf Developer \n \n ⚙ 📣\n❯ Good. Let's design the analytics dashboard we sketched last week. \n \n Sure. Starting from the mock: a metrics overview across the top, charts \n beneath, and a date-range filter driving the whole page. What's the headline \n metric? \n \n ❯ Signups, active users, and revenue — as big number tiles with week-over-week deltas. \n \n Got it. I'll have the tiles read from one /api/metrics endpoint so a single \n request backs the whole header row. \n \n ❯ And the charts underneath? \n \n A line chart for the trend and a bar chart for the plan breakdown. Both \n share the date range, so changing it re-queries once and both redraw. \n \n ❯ Add a way to pull the raw numbers out too — finance keeps asking. \n \n A CSV export scoped to the current filter, then. I'll also handle the empty \n and loading states so it never paints blank on first load. \n \n ❯ Perfect. Write it up so we don't lose the thread. \n \n On it. I'll draft dashboard.md — metrics API, charts, date-range filter, CSV \n export, empty/loading states, and tests. \n \n ⏺ Write(dashboard.md) \n ⎿ 48 lines written \n \n Done. dashboard.md covers all six. Want me to break it into tasks? \n───────────────────────────────────────────────────────────────────────────────────────────────────────────────\n ❯ ▊ \n───────────────────────────────────────────────────────────────────────────────────────────────────────────────\n Model: Opus 4.8 · Ctx 4% · Cost $0.36 · Session 3m 𖠰 hub \n ⏵⏵ auto mode on (shift+tab to cycle)\n```\n\nMeet Shelbi\n\n## This is Inbox Zero for agent work.\n\nHave 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!\n\n### Tasks keep work focused.\n\nEvery 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.\n\n```\n \n my-project \n \n \n 🔍 Search ⌃P \n \n \n 💬 Orchestrator \n \n 📋 Issues \n \n 🚀 Changelog \n \n \n — Workspaces — \n ▾ hub \n · alpha idle \n · bravo idle \n ⏵ charlie Developer \n ⏵ delta Developer \n ▾ devbox \n ⏵ echo Developer \n ⏵ foxtrot Developer \n · golf idle \n \n ⚙ 📣\nIssues · my-project 26 total Workflow: All ▾ Workspace: All ▾ \n \n B TO DO (6) IN PROGRESS (4) REVIEW (1) DONE (3) \n A Cache user sessions Paginate search API Fix mobile nav Add API ratelimit \n C app app ⎇ jlong/t-038 app ⎇ jlong/t-008 app \n K \n L Wire webhook retries Trim vendor bundle Dedupe error reports \n O app app ⎇ jlong/t-022 app \n G \n Split OTel spans Backfill order index Prune stale flags \n (12) app app ⎇ jlong/t-017 app \n \n Sync i18n strings Migrate CI to arm64 \n app app ⎇ jlong/t-014 \n \n Add health probes \n app \n \n Debounce autosave \n app \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n h/l col j/k row ⏎ open ⇧h/⇧l move col ⇧k/⇧j reorder ⇥ workflow f filter\n```\n\n### Agents provide specialization.\n\nWorkers 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.\n\n```\n 1 # Adversarial Review\n 2 \n 3 You are an adversarial code reviewer. A developer\n 4 agent has finished a task and believes its branch is\n 5 ready. Your job is not to confirm that belief — it is\n 6 to try to prove the change is wrong before a human\n 7 spends attention on it. Assume there is a bug until\n 8 you have looked hard enough to say otherwise.\n 9 \n 10 ## What to review\n 11 \n 12 Review the diff on the current task's branch against\n 13 the base branch — only what this task changed, plus\n 14 the code that change touches. You are looking for\n 15 defects the developer and the tests missed, not for\n 16 style nits the preamble's checks already cover.\n 17 \n 18 ## How to review\n 19 \n 20 Work through every changed hunk and actively try to\n 21 falsify it:\n 22 \n 23 - Correctness — Does it do what the task asked? Trace\n 24 the non-obvious paths by hand. Off-by-one, wrong\n 25 operator, inverted condition, a branch that silently\n 26 does nothing.\n 27 - Security — Untrusted input reaching a query, a\n 28 shell, a path, or a template. Missing authz checks.\n 29 Secrets in logs or errors. Unsafe defaults.\n 30 - Error handling — What happens when the call fails,\n 31 the input is empty, the list is huge, the value is\n 32 null, two requests race?\n 33 - Edge cases — Boundaries, empty and maximal inputs,\n 34 concurrency, encoding, time zones — whatever this\n 35 code plausibly meets in production.\n 36 - Test coverage — Do the tests actually exercise the\n 37 new behavior, or do they assert around it? Find a\n 38 real input the change gets wrong that no test would\n 39 catch, and treat that as a finding.\n 40 \n 41 ## How to report\n 42 \n 43 Write your findings as a structured review on the\n 44 branch — a markdown ## Adversarial Review section, per\n 45 this project's convention. For each finding:\n 46 \n 47 - Severity — blocker, major, or minor.\n 48 - Location — path/to/file.rs:120 (or a range).\n 49 - The problem — what breaks, and the concrete input or\n 50 sequence that triggers it. A finding with a repro\n 51 beats a vague worry.\n 52 - Suggested fix — one line, when the fix is obvious.\n 53 \n 54 Order findings by severity, blockers first.\n 55 \n 56 ## Signing off or bouncing\n 57 \n 58 Every review ends one of two ways. Decide from the\n 59 highest-severity finding. If nothing rises to a\n 60 blocker, sign off and hand off forward. If any finding\n 61 is a blocker, write up the findings and bounce the\n 62 task back to the developer.\n```\n\n### Workflows provide boundaries.\n\nEvery 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.\n\n```\n 1 name: feature\n 2 description: >\n 3 A full app feature, from idea to merged. A\n 4 developer builds it on a branch off main; then\n 5 adversarial review, QA, and security each gate\n 6 it before a human signs off and it merges.\n 7 \n 8 initial_status: backlog\n 9 \n 10 statuses:\n 11 - { id: backlog, owner: user }\n 12 - { id: in-progress, owner: agent, agent: developer }\n 13 - { id: agent-review, owner: agent, agent: adversarial }\n 14 - { id: qa, owner: agent, agent: qa }\n 15 - { id: security, owner: agent, agent: security }\n 16 - { id: review, owner: user }\n 17 - { id: done, owner: user }\n 18 \n 19 transitions:\n 20 - { from: backlog, to: in-progress }\n 21 - { from: in-progress, to: agent-review, actions: [push_branch, open_pr] }\n 22 - { from: agent-review, to: qa }\n 23 - { from: qa, to: security }\n 24 - { from: security, to: review }\n 25 - { from: review, to: done, actions: [merge, delete_branch] }\n 26 \n 27 git:\n 28 base_branch: main\n 29 merge_strategy: squash\n~\n~\n~\n~\n~\n~\n~\n~\n~\n~\n~\n```\n\n## Features\n\n- Kanban TUIKanban board\n- 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.\n- Workers on any machine\n- Any box you can SSH into can take tasks. If it has git and an agent CLI, it's a worker.\n- Attach from anywhere\n- 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.\n- Review flow\n- 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.\n- Plain-file state\n- Tasks are markdown and workflows are YAML, stored in your repo. No database, no cloud, just files you can read, grep, and commit.\n- Open source\n- The whole system is MIT licensed on GitHub. You can read every line that runs on your machines.", "url": "https://wpnews.pro/news/i-built-an-alternative-to-conductor-for-claude-and-codex", "canonical_source": "https://shelbi.dev/", "published_at": "2026-11-05 02:11:40+00:00", "updated_at": "2026-11-05 02:21:24.209339+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "ai-products"], "entities": ["Shelbi", "Conductor", "Claude", "Codex"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/i-built-an-alternative-to-conductor-for-claude-and-codex", "markdown": "https://wpnews.pro/news/i-built-an-alternative-to-conductor-for-claude-and-codex.md", "text": "https://wpnews.pro/news/i-built-an-alternative-to-conductor-for-claude-and-codex.txt", "jsonld": "https://wpnews.pro/news/i-built-an-alternative-to-conductor-for-claude-and-codex.jsonld"}}