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 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/ 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.
source & further reading
shelbi.dev β original article