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 built on tmux.
open source Β· made with tmux Β· multi-machine
jlong@hub β my-project
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.
jlong@hub β my-project
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.
jlong@hub β nvim instructions.md
βΎ 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
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.
jlong@hub β nvim feature.yaml
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 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
feature.yaml1,1Β Β Β Β All
"feature.yaml" 29L, 961B
Features
- Kanban TUI
- Every task is a card on a board in your terminal, 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 runs tmux and an agent CLI, it's a worker.
- Made with tmux
- Every worker runs in a real tmux pane. Attach to a session to watch an agent work or type to it directly.
- 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.