I built an alternative to Conductor for Claude and Codex

TUIDesktop

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

Read the docs

jlong@hub — my-project

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)

my-project

Orchestrator⌘O

Issues⌘I

Changelog⌘L

Workspaces

hub

alphaIdle

bravoIdle

charlieDeveloper⌘1

deltaIdle

devbox

echoIdle

foxtrotIdle

golfDeveloper⌘2

Zen mode off

❯ Morning. Where did the API cleanup land yesterday?

Both tasks cleared review overnight — the rate-limit and the search pagination work merged to main. The board's clear.

❯ 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

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

my-project

Orchestrator⌘O

Issues⌘I

Changelog⌘L

Workspaces

hub

alphaIdle

bravoIdle

charlieDeveloper⌘1

deltaDeveloper⌘2

devbox

echoDeveloper⌘3

foxtrotDeveloper⌘4

golfIdle

Zen mode off

Filter:WorkflowsWorkspacesboard 2sSearchNew issue

BACKLOG12

TO DO6

Cache user sessions

Keep session lookups in Redis instead of hitting the database per request.

app

Wire webhook retries

Retry failed webhook deliveries with backoff and a dead-letter queue.

app

Split OTel spans

Separate spans for queueing and handling so slow jobs are easy to find.

app

Sync i18n strings

Pull the latest translations and flag any keys missing a locale.

app

Add health probes

Liveness and readiness endpoints for the API and the worker pool.

app

Debounce autosave

Save drafts once typing pauses instead of on every keystroke.

app

IN PROGRESS4

Paginate search API

Cursor pagination for /search so large result sets stream in pages.

appjlong/t-038

Trim vendor bundle

Split the vendor chunk and drop unused locales to cut the first load.

appjlong/t-022

Backfill order index

Backfill the new orders index in batches without locking the table.

appjlong/t-017

Migrate CI to arm64

Move the CI runners to arm64 and keep an x86 job for the release build.

appjlong/t-014

REVIEW1

Fix mobile nav

The menu sheet traps scroll on iOS. Close it on navigation.

appjlong/t-008

DONE3

Add API ratelimit

Per-key rate limits on the public API, with clear 429 responses.

app

Dedupe error reports

Group identical errors by fingerprint so one bug is one report.

app

Prune stale flags

Remove feature flags that have been fully rolled out for a month.

app

h/l column k/j card ↵ open ⇧h/⇧l move ⇧k/⇧j reorder drag to move or reorder s start a assign e edit E editor n new

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.

agents

▾ adversarialM

instructions.mdM

settings.json

▸ skills

▾ developer

instructions.md

settings.json

▸ skills

▾ orchestrator

instructions.md

settings.json

▸ skills

▾ qa

instructions.md

settings.json

▸ skills

▾ review

instructions.md

settings.json

▸ skills

▾ security

instructions.md

settings.json

▸ skills

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.

instructions.md1,1    All

"instructions.md" 62L, 2231B

adversarialDefaultSave changes

Nameadversarial

DescriptionAdversarial code review before a human sees the branch

InstructionsMarkdown

Define how this agent approaches a task and when its work is complete.# Adversarial Review

You are an adversarial code reviewer. A developer agent has finished a task and believes its branch is ready. Your job is not to confirm that belief — it is to try to prove the change is wrong before a human spends attention on it. Assume there is a bug until you have looked hard enough to say otherwise.

What to review

Review the diff on the current task's branch against the base branch — only what this task changed, plus the code that change touches. You are looking for defects the developer and the tests missed, not for style nits the preamble's checks already cover.

How to review

Work through every changed hunk and actively try to falsify it:

• Correctness — Does it do what the task asked? Trace the non-obvious paths by hand. Off-by-one, wrong operator, inverted condition, a branch that silently does nothing.
• Security — Untrusted input reaching a query, a shell, a path, or a template. Missing authz checks. Secrets in logs or errors. Unsafe defaults.
• Error handling — What happens when the call fails, the input is empty, the list is huge, the value is null, two requests race?
• Edge cases — Boundaries, empty and maximal inputs, concurrency, encoding, time zones — whatever this code plausibly meets in production.
• Test coverage — Do the tests actually exercise the new behavior, or do they assert around it? Find a real input the change gets wrong that n