shobcoder/shob: an agent workspace whose six features are all about supervision

Six features, and every one is about supervision

Read the feature list as a pair of halves. Three of the six are about running more agents, and three are about controlling them.

The expansion half is parallel sessions, which lets you run multiple agents simultaneously in the same project, working on bug fixes, testing, documentation, refactoring and feature development at once. Subagent delegation breaks a large task into smaller pieces delegated to specialised agents, returning consolidated results into a single workspace. Live task tracking is the third, letting you watch agents create plans, execute tasks and complete objectives step by step.

The control half is where the product's actual opinions are. A permission system is described as keeping every action under your control, with commands, file access and code changes reviewed and approved before they happen. Git integration is framed as understanding your repository, active branch and local changes so agents work safely inside your workflow rather than around it. Terminal and diff preview is the inspection surface, letting you see exactly what an agent did, read its terminal output and inspect code changes before accepting them.

So the pitch is throughput with a review gate, not autonomy. Six features, and the three that constrain the agents carry as much weight as the three that multiply them.

Get Started is a link to the repository and nothing else

The last section of the readme is titled Get Started, and it contains one link plus a request for a star.

That link points at the GitHub repository. There is no install command anywhere in the file, no runtime requirement, no mention of a package manager, and no link to documentation, even though the repository has a docs directory. The readme's own framing, that Shob helps you manage everything in one place instead of juggling conversations, terminals and tools, describes the problem rather than the procedure.

There is also a stated status and a stated vision, and they belong together. The project says it is currently in beta, that it is improving the platform and building new capabilities on the basis of community feedback, and that every suggestion, issue report and contribution helps shape it. The vision section says powerful AI agents should be accessible to everyone rather than only large organisations, and that the mission is to make AI-powered development and automation affordable and practical for developers, students, freelancers, startups and teams.

A beta with an accessibility mission and no documented entry point is an accurate description of where the project sits. Anyone who wants to evaluate it has to read the repository rather than the readme.

The root test target fails on purpose

One script in the workspace manifest is worth quoting because it is the most unusual line in the repository.

The root test target does not run tests. It echoes a message telling you not to run tests from the root, and exits with status 1. As a script it reads `echo 'do not run tests from root' && exit 1`.

The intent is a guard rather than a bug. In a workspace this size, running a test command from the root would either do nothing useful or run the wrong thing, so the root target converts that mistake into an immediate, self-describing failure instead of a confusing result. Every other script in the manifest points somewhere specific: the dev target runs an entry point inside one package with a browser condition set, the desktop target runs inside the desktop package, typecheck is delegated to the task runner, lint is a single linter call, and there is a postinstall step and a prepare hook.

So the failure is one of the few pieces of developer ergonomics the manifest bothers to state, and it is stated as an error message rather than as documentation.

Thirty-one catalog pins, six of them betas

The workspace manifest uses a version catalog, which centralises dependency versions so every package resolves the same one. The catalogue has thirty-one entries, and six of them are not stable releases.

Three Effect packages are pinned to the same beta build: a beta for the platform node bindings, a beta for the SQL layer on top of Bun, and a beta for the OpenTelemetry integration, all at build 83 of a 4.0 line. Two Drizzle packages, the ORM and its kit, are pinned to the first release candidate of 1.0. And the auth package is pinned to a dated pre-release rather than to a version number at all.

The stable entries are the rest: the GitHub REST client, npm's own dependency tree library, validators for a Hono server, a virtual list helper, syntax highlighting, a tailwind Vite plugin, a diff engine with a DOM sanitiser beside it, a unique id generator, workers type definitions, and TypeScript configuration presets.

Two of those inclusions tell you more about direction than the feature list does. Cloudflare workers types in a desktop application suggest intent to run part of this somewhere other than a local process, and the presence of both an ORM and an auth package in beta alongside a node terminal stack suggests the workspace spans several deployment shapes rather than one.

node-pty is patched during install, and that is the terminal

The postinstall hook is the line that explains how a terminal works in this project.

It runs a fix script inside the core package after install, and the name points at the node-pty module, which is the native binding that lets Node drive a real pseudo-terminal. Patching it during install means the checked-in patch set is applied to that binding automatically rather than being a step a contributor remembers.

There is a patches directory at the top of the repository alongside it, which is where those overrides live, and the repository also carries a Bun configuration file, a lock file, a TypeScript configuration, a task-runner configuration and a Husky directory with the prepare hook wired to it.

A few other top-level entries say something about the shape of the project. There is a gitleaks ignore file, so secret scanning is configured. There is a directory named for the application itself, which is where a workspace's own state would live. And there are skills and specs directories, which is the convention for an agent tool that ships its own instructions and its own written specifications.

The script directory is singular while every other convention here is plural, which is the kind of inconsistency a new contributor trips over.

Beta, sixty-two days past the last tag

The dates are the clearest statement of status, more so than the word beta in the readme.

The newest release is v0.0.97, published on 31 July 2026. Before it, v0.0.96 on the same day and v0.0.95 on 19 July 2026. The last push to the default branch main is dated 18 September 2026.

So there are sixty-two days between the newest tag and today, and fourteen days between the newest tag and the most recent commit. Work has continued since the release; it simply has not been tagged.

The version numbers are also informative. All three visible releases sit in the zero-point-zero range at the ninety-fifth through ninety-seventh increment, which is a counter rather than a semver line. There is no 1.0, and the increments of one suggest frequent internal publishing.

The repository is not archived, and the counters read 577 stars, 2 forks and 6 open issues. Two forks against 577 stars is worth noticing: this is a project people look at rather than clone, which is consistent with a desktop application distributed some other way than by forking the source.

A workspace with a CLI entry point, a desktop app and an SDK

The scripts reveal three distinct ways in, which the readme does not mention at all.

The first is a command line style entry point: the dev target runs a TypeScript file inside the main application package with a browser condition flag set, which is how a terminal interface resolves its rendering at startup. The second is the desktop application, which has its own package and its own dev target. The third is not a run mode but a distribution shape: the workspace list includes a path under an sdk directory for JavaScript, so the project intends to be consumed by other JavaScript code as a package.

That third one is the most consequential and the least documented. A workspace that publishes an SDK has a stability obligation that a workspace with only applications does not, and the manifest marks the root package itself private, so nothing is published from the root; what would be published is the sub-package.

It also explains the dependency choices. The SQLite layer on top of Bun, the ORM in a release candidate, and the auth package in a dated pre-release are the stack for an application that persists state and authenticates users, and they are all pre-stable.

So the shape is a monorepo containing a terminal interface, a desktop application and a JavaScript SDK, built with Bun, orchestrated by a task runner, linted by a single fast linter rather than by the ecosystem default, with no entry point written down.

Editorial conclusion

Shob fits a developer who wants several agents working one project at once and who wants to approve each command and read each diff before accepting it, since that review loop is what the product is built around. It is a poor fit if you need a documented install today, because the readme gives none and pins six dependencies to betas or release candidates. Before you commit time to it, check three things: whether the commits since the last release contain the capability you need, since the newest tag is sixty-two days old, how you will run the tests, because the root test target is a deliberate failure telling you not to use it, and whether your authentication and database layers can live with beta and release-candidate versions of their libraries.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. shobcoder/shob on GitHub