Zeroshot: independent reviewers, a native binary, and TLS crates pinned by hand

The worker edits the Git worktree you are standing in

The example carries a warning in bold: the worker edits the current Git worktree, so start in a clean worktree intended for the task. There is no sandbox flag in the command that follows it.

The run is two JSON files and a command. input.json holds the task as a single string, and runtime.json holds the harness, the provider, a model identifier and an effort level of high. Then:

zeroshot run \
  --title "Add JSON status output" \
  --template software-change \
  --input input.json \
  --uniform-runtime-config runtime.json \
  --validate-only

The validate-only flag is the one worth remembering: it prints the graph, the runtime configuration and the input without starting anything. Removing that flag is the difference between inspecting a plan and executing it against your working tree.

A local UI is available on 127.0.0.1 at port 4173 under /ui/, and the README notes that stopping the UI server leaves active runs running. The CLI also has zeroshot list, zeroshot status with a run id, and zeroshot logs with a run id.

The install is an npm command that drops a native binary

Installation looks like an ordinary global install:

npm install -g @the-open-engine-company/zeroshot

It is not one. The installer requires Node.js 18 or newer and then puts a verified native binary in place, for Linux on x64 and arm64, macOS on x64 and arm64, or Windows on x64. Native archives and checksums are attached to each canonical vX.Y.Z GitHub Release, which is what the verification step is checked against.

The same installer also writes one Zeroshot skill for Codex, for GitHub Copilot and for Claude Code, at user scope. So a single command changes a globally installed binary and the agent configuration of up to three tools on your machine.

There is a version history behind this. The README calls v8 a hard interface cutover, because v8 replaced the Node.js runtime with the native binary. Anything written against the pre-v8 interface moved at that release, and the current releases are two major versions further on, at v10.10.0. For local execution the README says to install and sign in to Codex, Claude Code or GitHub Copilot, and that a local run can reuse the harness's existing login, including subscription-backed sessions.

The description names four harnesses and the install guide names three

The repository description says Zeroshot supports Claude Code, OpenAI Codex, OpenCode and Gemini CLI with trivial setup.

The install section names Codex, Claude Code and GitHub Copilot. The skill installer list names Codex, GitHub Copilot and Claude Code. So OpenCode and Gemini appear in the description and nowhere in the documentation the README gives you, and GitHub Copilot appears in the install instructions and nowhere in the description.

That gap matters more than a documentation nit, because the harness choice is the first thing a new user has to get right. The install guide is a repository document, not marketing copy, so it is the more reliable of the two, and the general case is handled by a link rather than a list: for other harnesses and providers the README points at a document on runtimes and connections.

The runtime.json shape reflects the same indirection. You name a harness, a provider and a model, and the model identifier is described as one supported by your installed CLI, which means the accepted values are whatever that harness has rather than a fixed list.

The linter is handed a file list rather than a glob

The root package manifest describes itself as repository tooling for the Zeroshot native product, at version 0.0.0-development and marked private. It has one runtime dependency, js-yaml, and a short list of development tools.

The lint script is where this shows:

"lint": "eslint --max-warnings 0 .github/ci-path-classifier.js scripts/*.js scripts/distribution/*.js npm/zeroshot/**/*.js tests/tooling/*.js commitlint.config.js",

The paths are enumerated. Anything added outside those patterns is not linted, and the glob only covers three specific directories. Warnings are promoted to failures with --max-warnings 0, which is the stricter half of the decision.

The check chain is layered by language: lint, then node --test over the tooling tests, then a distribution check that runs node scripts/distribution.js check-repository, then a protocol check that shells into cargo to generate and compare a cluster protocol. The Rust side has its own four-part check, formatting, clippy with warnings denied, the workspace tests, and documentation built with rustdoc warnings denied.

TLS dependencies are pinned with equals signs in a workspace that ships binaries

The Rust workspace is where the product lives, with edition 2024 and a stated minimum rust-version of 1.85. The crates are split into a cluster protocol, a cluster server, a cluster client, a cluster testkit, an external backend fixture inside that testkit, and the zeroshot binary itself.

The dependency list is mostly caret ranges, with a block of exact pins on the TLS stack:

rustls = { version = "=0.23.42", default-features = false, features = ["ring", "std", "tls12"] }
rustls-native-certs = "=0.8.4"
tokio-rustls = { version = "=0.26.4", default-features = false, features = ["ring", "tls12"] }
webpki-roots = "=0.26.8"
rcgen = "=0.13.2"

An equals sign in a manifest is a manual decision, and five of them on the TLS crates means a security update to rustls or its roots bundle arrives as a diff someone has to write rather than as a lockfile refresh. The tls12 feature is kept on in both, so TLS 1.2 stays enabled alongside whatever the current defaults offer.

Two other entries are worth knowing because they change what you need installed. dbus is pulled with the vendored feature and rusqlite with bundled, so both are compiled in rather than linked to system libraries, which is what makes a single static-ish binary plausible on four platforms. self-replace is in the list, which is the usual way a CLI upgrades itself.

A passing run means the configured checks accepted the work

The project states its own limit twice, in the same words. A passing run means the configured checks accepted the work, and coverage depends on the requirements, reviewers, tests and environment you provide. It also says plainly that it is not a replacement for your tests.

The built-in workflow is five steps: a worker implements, acceptance and code reviewers check the result independently and in parallel, rejected work goes to a repair worker and then through both reviews again, accepted work proceeds through the configured Git and CI steps when delivery is enabled, and a delivery conflict returns through repair and review.

The graph is fixed before execution starts, and it defines the sequence, which steps run in parallel, retry paths and exit conditions. Runs are bounded, and events go into a durable SQLite ledger.

The custom topology example is where the real work moves to you. It adds a bugfinder stage running adversarial tests and an E2E stage after the review loop, and the README is explicit that those stages are custom additions whose test tools, services and credentials you provide, along with where their failures route back for repair. `zeroshot template show software-change` prints the built-in graph to start from, and a profile saves a graph with its runtime settings for reuse.

Planning documents and a protocol directory ship beside the binary

The top level explains the shape of the project better than the README does. There is crates/ for the Rust workspace, zeroshot/ for the binary, ui/ for the browser interface, sdks/ for the client libraries, npm/ for the wrapper package that the global install goes through, distribution/ for packaging, docker/ for a container target, protocol/, planning/, docs/ with an mkdocs.yml, scripts/, and tests/.

Two of those names are unusual for a published repository. planning/ is a directory of planning material that ships with the code, and protocol/ sits next to it, with a script that regenerates the cluster protocol and a check mode that fails when the committed output is stale.

There are also two lockfiles for two ecosystems, package-lock.json and Cargo.lock, and toolchain pins for both: a rust-toolchain.toml, a .nvmrc, rustfmt.toml, clippy.toml, and an eslint config alongside a prettier config and a commitlint config using the conventional preset. Husky runs on prepare, so the hooks are installed with the dependencies.

The releases come in two lines. The CLI is at v10.10.0, and the Python SDK carries its own tag, zeroshot-python-v10.10.0_1, for package version 10.10.0.post1. Pin them separately if you consume both.

Editorial conclusion

Use Zeroshot when you want a change checked by something other than the session that wrote it, and when you are prepared to supply the reviewers, the tests and the acceptance criteria yourself, because the tool is explicit that a passing run means its configured checks accepted the work and nothing more. Do not adopt it for a small edit, which the project itself says is quicker in a single session, and do not treat it as a test replacement. Before you run it, read the two facts that matter most: the worker edits the worktree you are standing in, so start clean, and the installation drops a native binary plus a user-scope skill for three coding agents on your machine.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes