The prompt for the run shown as "Claude Code, given the reviewer's standards" on zeroshot.sh. One session of Claude Code on Opus 5.5, no reviewer. This setup ran more than once; the page shown is from the first run that finished, run 4. Runs 1 to 3 were stopped by a stray kill command before they built a page. The local folder path is shortened; nothing else is changed. The reviewer's standards start after the README, at "--- end of README.md ---". ------------------------------------------------------------------------ Here is the README for Zeroshot, our open source project. Build its landing page in this empty repo: plain HTML, CSS and JS, no build step. It should make an engineer who lands on it understand what Zeroshot is and want to try it, and link to the GitHub repo and the docs. --- README.md ---

[![Release](https://img.shields.io/github/v/release/the-open-engine/zeroshot?style=flat&label=release&labelColor=171411&color=171411)](https://github.com/the-open-engine/zeroshot/releases/latest) [![npm](https://img.shields.io/npm/v/%40the-open-engine-company%2Fzeroshot?style=flat&labelColor=171411&color=171411)](https://www.npmjs.com/package/@the-open-engine-company/zeroshot) [![Build](https://img.shields.io/github/actions/workflow/status/the-open-engine/zeroshot/ci.yml?branch=main&style=flat&label=build&labelColor=171411)](https://github.com/the-open-engine/zeroshot/actions/workflows/ci.yml?query=branch%3Amain) [![Opcore](https://img.shields.io/github/actions/workflow/status/the-open-engine/zeroshot/opcore.yml?branch=main&style=flat&label=opcore&labelColor=171411)](https://github.com/the-open-engine/zeroshot/actions/workflows/opcore.yml?query=branch%3Amain) [![Coverage](https://coveralls.io/repos/github/the-open-engine/zeroshot/badge.svg?branch=main)](https://coveralls.io/github/the-open-engine/zeroshot?branch=main) [![Docs](https://img.shields.io/github/actions/workflow/status/the-open-engine/zeroshot/docs.yml?branch=main&style=flat&label=docs&labelColor=171411)](https://the-open-engine.github.io/zeroshot/) [![License: MIT](https://img.shields.io/badge/license-MIT-171411?style=flat)](LICENSE)

# Zeroshot **The agent that writes the code should not be the one that decides it works.** We built Zeroshot because we were tired of being gaslit by agents telling us broken code was ready. Zeroshot turns a software goal into an explicit multi-agent graph: one agent implements, independent agents review, failures go back to a bounded repair loop, and nothing is delivered until the graph's checks pass. The implementing agent never approves its own work. Zeroshot doesn't replace Claude Code, Codex or Copilot. It runs one of them as the worker and as the reviewers. Use the built-in graph or bring your own topology. Add reviewers, tests, and repair loops, then save the setup as a profile for the next task. The product site, [zeroshot.sh](https://zeroshot.sh/?utm_source=github&utm_medium=readme&utm_campaign=zeroshot), has the FAQ. **[▶ Video: a single agent vs. Zeroshot](https://x.com/eivindmeyer_cv/status/2106898797771288828)** (scripted) Questions, ideas, or a run worth showing? Join the [Zeroshot community on Discord](https://theopenengine.com/discord). ## Install ```bash npm install -g @the-open-engine-company/zeroshot ``` The installer requires Node.js 18 or newer and installs a verified native binary for Linux x64/arm64, macOS x64/arm64, or Windows x64. It also installs one Zeroshot skill for Codex, GitHub Copilot, and Claude Code at user scope. For local execution, install and sign in to Codex, Claude Code, or GitHub Copilot. Local runs can reuse the harness's existing login, including subscription-backed sessions. See the [installation guide](docs/getting-started/install.md) for harness prerequisites. > **Zeroshot v8 is a hard interface cutover.** v8 replaces the Node.js runtime with a native > `zeroshot` binary. ## Run your first task This example uses Codex and keeps delivery local. **The worker edits the current Git worktree**, so start in a clean worktree intended for the task. Create `input.json`, replacing the example task with a change appropriate for your repository: ```json { "task": "Add JSON output to the status command and cover it with focused tests." } ``` Create `runtime.json`. Replace `YOUR_MODEL_ID` with a model identifier supported by your installed Codex CLI: ```json { "harness": "codex", "provider": "openai", "model": "YOUR_MODEL_ID", "effort": "high" } ``` Start the run. Add `--validate-only` to check the graph, runtime configuration, and input first: ```bash zeroshot run \ --title "Add JSON status output" \ --template software-change \ --input input.json \ --uniform-runtime-config runtime.json ``` Open another terminal to inspect the run: ```bash zeroshot ui ``` Visit `http://127.0.0.1:4173/ui/` and open **Runs**. Stopping the UI server leaves active runs running. The CLI also provides `zeroshot list`, `zeroshot status RUN_ID`, and `zeroshot logs RUN_ID`. For other harnesses and providers, see [Runtimes and connections](docs/concepts/runtimes-and-connections.md). ## What the built-in workflow does 1. A worker implements the task. 2. Acceptance and code reviewers check the result independently, in parallel. 3. Rejected work goes to one repair worker with both reviews' feedback, then through both reviews again. 4. With delivery enabled, accepted work proceeds through the configured Git and CI steps. 5. Delivery conflicts return through repair and review. The graph defines the sequence, parallel steps, retry paths, and exit conditions before execution starts. Runs are bounded, and events are recorded in a durable SQLite ledger. A passing run means its configured checks accepted the work; coverage depends on the requirements, reviewers, tests, and environment you provide.

Animated Zeroshot workflow: implementation, parallel acceptance and code review, repair, and optional Git delivery

Both reviews run again after a repair. Git delivery is optional.
Static diagram

## Auto-research The built-in `auto-research` template runs ten iterations by default; set a positive `options.iterations` value in the run input to choose another count. Three scouts propose directions, then a planner chooses an experiment and either the current candidate or a restorable archived candidate as its starting point. Independent judges check the evidence and method, while the progress judge decides whether the result should replace the current candidate under the task charter. A valid result can go into the archive without replacing it. An auditor checks the ledger, archive, and workspace before the next iteration. Inspect the graph with `zeroshot template show auto-research`. ## Bring your own graph topology Choose each agent's model and instructions, which steps run in parallel, and when to retry. Example topology, adding stages after the review loop: ```text Implementation ↓ Code review + acceptance review ↓ Bugfinder: adversarial tests ↓ E2E tests ↓ Delivery ``` The software-change review loop, auto-research graph, and delivery are built in. You define other stages, their tools, services and credentials, and where failures go for repair. Inspect the built-in graph as a starting point: ```bash zeroshot template show software-change ``` See the [graph contract](docs/reference/cluster/graph.md) for custom graph authoring and [Prepare a runtime environment](docs/guides/runtime-environments.md) for dependency and service setup. ## Save and reuse a profile Each step can use its own model. Pass `--runtime-config` with one binding per node in place of `--uniform-runtime-config`: ```json { "harness": "claude", "provider": "anthropic", "size": "medium", "nodes": { "worker": { "kind": "agent", "model": "WORKER_MODEL_ID", "effort": "high" }, "acceptance": { "kind": "agent", "model": "REVIEW_MODEL_ID", "effort": "high" }, "code": { "kind": "agent", "model": "REVIEW_MODEL_ID", "effort": "max" }, "review_repair": { "kind": "agent", "model": "WORKER_MODEL_ID", "effort": "high" } } } ``` Runs with delivery enabled also need a `delivery_repair` binding. Run `zeroshot template show software-change` to list the node names. See the [RuntimePlan reference](docs/reference/runtime-plan.md) for every field. A profile stores a graph and its runtime settings. Use **Profiles** in the browser UI to edit and save your configuration. Keep different profiles for different kinds of work, or reuse one for the next task. Once you've saved a local profile named `my-profile`, run another task with it: ```bash zeroshot run \ --title "My next task" \ --profile local:my-profile \ --input input.json ``` The CLI and UI share the same local profiles. See [UI setup](docs/getting-started/install.md#open-the-workspace-ui). ## Choose delivery and execution Keep the first result local, then enable the delivery mode that fits your process: | Delivery | Behavior | | ---------------- | ------------------------------------------------ | | No delivery flag | Keep the work local | | `--push` | Push the managed branch | | `--pr` | Prepare a mergeable pull request without merging | | `--ship` | Proceed through PR, CI, and merge | PR and ship runs address visible pull request review feedback by default; pass `--no-pr-feedback` to ignore it. Graphs can execute locally or on a self-hosted target. Each environment needs its own tools and authentication setup. ### Self-hosted: run the Docker target Keep execution and durable state on infrastructure you control. The target image includes the native engine plus pinned Codex, Claude, and GitHub Copilot harness CLIs. ```bash docker run --detach --restart unless-stopped --name zeroshot-target \ -p 127.0.0.1:8080:8080 \ -v zeroshot-data:/var/lib/zeroshot \ ghcr.io/the-open-engine/zeroshot-target:latest zeroshot target add local --url http://127.0.0.1:8080 --direct ``` The target also serves its profile editor and run viewer at `http://127.0.0.1:8080/ui/`. See the [target image guide](docker/zeroshot-target/README.md) for persistent storage, network isolation, builds, and HTTPS. A failed run with a recoverable workspace can be [restarted or resumed](docs/guides/observe-and-control.md#restart-or-resume-a-failed-run). ## Research graph Zeroshot also includes an `auto-research` graph for ten bounded iterations of experiments with independent review of evidence, method, and progress. It keeps adopted, record-only, and aborted results under `.zeroshot/research`; add `--push` when each finalized iteration should be published. ```bash zeroshot template list zeroshot template show auto-research ``` See [Execution](docs/concepts/execution.md) for the research workflow's decision and evidence rules. ## Community - [Discord](https://theopenengine.com/discord): ask questions, share runs and graphs, and talk to the team. - [GitHub Issues](https://github.com/the-open-engine/zeroshot/issues): reproducible bugs and feature requests. ## Reference - [Versioned documentation](https://the-open-engine.github.io/zeroshot/) - [Get started](docs/getting-started/first-run.md) - [CLI reference](docs/zeroshot-cli.md) - [Target image guide](docker/zeroshot-target/README.md) - [Python SDK](sdks/python/README.md) - [Cluster API reference](https://the-open-engine.github.io/zeroshot/current/reference/cluster/api/) - [Graph contract](docs/reference/cluster/graph.md) Also check out: [Opcore](https://github.com/the-open-engine/opcore). ## Development ```bash npm ci npm run check cargo test --workspace # Unix; Windows: powershell -NoProfile -File scripts/test-windows.ps1 ``` Node.js builds the static UI and supports repository tooling and npm delivery; Rust serves the UI. See [UI development](ui/README.md), [CONTRIBUTING.md](CONTRIBUTING.md), [PUBLISHING.md](PUBLISHING.md), and [SECURITY.md](SECURITY.md). ## License MIT. See [LICENSE](LICENSE). --- end of README.md --- Build it to the standard a senior product designer would hold it to in a crit. What counts is what people will see and read, not the code. Work out from the task who this is for and what it has to get across. It has to hold up on: - The idea. Is there one clear idea behind it, drawn from what this product actually is? Generic fails here: the fonts, colors, layouts and components every AI-built UI reaches for. So does the opposite: novelty or ornament added only to look different. - Hierarchy. Squint at each screen. The most important thing is seen first and the rest steps down in a clear order; nothing competes with it. - Restraint. Every element and every line earns its place. Fewer, better decisions. Cut what does not serve that reader. - Craft. Type and spacing on a real scale, edges aligned, color used with intent, and every state and the phone layout finished as carefully as the first screen. - The words. Sharp, specific and worth reading for that reader, and the point arrives fast. Nothing claims more than the task and its sources support. Know what generic looks like now, because it is what you reach for first. The old kit: purple-blue gradients, glass and glow, Inter, a centered hero over three feature cards. The current "tasteful" kit: cream or off-white with a serif headline and one italic or colored word, a single terracotta or red accent, pills and chips, small uppercase labels over headings, cards around everything. Under both: evenness. Every section equally loud, the same spacing everywhere, nothing that pulls the eye first, and copy with the same cadence in every line that could describe any product in its category. A strong page is loud in one channel and quiet in the rest. None of these defaults passes unless something about this product earns it. It is done when it would hold up next to the best work in its category. To see the rendered page: serve the repo root with `python3 -m http.server 5746` in the background, then run `node tools/shoot.mjs http://localhost:5746/ ` with a new timestamped folder under artifacts/opus-upfront-4; it shoots desktop and phone widths. Stop the server before you finish and never save screenshots inside the repository.