the-open-engine/zeroshot

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

Do you still look at the code? We don't. We built zeroshot so we wouldn't have to.

One agent gets sloppy and biases itself as its context fills up. It forgets requirements, stops questioning its own assumptions, and calls it done. The agent that wrote the code shouldn't be the one that says it works.

So you draw your team's process as a graph (who writes, who reviews with fresh context, what must pass, where failures go back), pick the agent and model for each step, and the engine runs every task through it. Agents can't skip a step, and what happens after a review is up to the graph, not the agent.

An example graph: independent reviews, end-to-end testing, and CI must pass before merge.

                           ┌─────────────────┐
                           │       Goal      │
                           └────────┬────────┘
                                    ▼
┌───────────────┐          ┌─────────────────┐
│     Repair    ├─────────▶┤      Worker     │
└───────┬───────┘          └────────┬────────┘
        ▲             ┌─────────────┴─────────────┐
        │             ▼                           ▼
        │  ┌─────────────────────┐     ┌─────────────────────┐
        │  │  Acceptance review  │     │     Code review     │
        │  └──────────┬──────────┘     └──────────┬──────────┘
        │             │                           │
        │             └─────────────┬─────────────┘
        ├◀─── either rejects ───────┤
        │                           │  both approve
        │                           ▼
        │                  ┌─────────────────┐
        ├◀───── fail ──────┤ End-to-end test │
        │                  └────────┬────────┘
        │                           ▼  pass
        │                        ┌─────┐     ┌─────┐        ┌───────┐
        │                        │  PR ├────▶┤  CI ├─pass──▶┤ Merge │
        │                        └─────┘     └──┬──┘        └───────┘
        └◀───────────── fail ───────────────────┘

Save your graph as a reusable profile and run the same process across tasks.

See more graph examples on zeroshot.sh.

Why not a skill? A skill asks for a review, and the agent can skip it, whereas a zeroshot graph enforces it in code.

Do loops work? Yes, even a simple one. In our benchmark, a build-and-check loop lifted a small model to a big model's score, at 58% of the cost. Just asking the agent to check its own work didn't help. Read the study.

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

The CLI installer adds skills for Claude Code, Codex, Copilot CLI and Pi. See installation options to skip skill installation.

Use zeroshot in ChatGPT, Codex, or Claude with the plugin and MCP connection; the zeroshot CLI is optional for Platform workflows.

Open your agent in a repo and ask for a change. For example:

use zeroshot to let users export their data as CSV. Keep the changes local.

Run locally with your agent's existing login and subscription. Watch with zeroshot ui. The CLI quick start walks through a run directly in the terminal.

To choose your own agents, models, review gates, and delivery, ask:

design a zeroshot graph for this repo

The skill reads your repo and builds the graph with you. Then plan a task:

plan this with zeroshot: let users export their data as CSV

Run the plan:

zeroshot it

Export a template with Git delivery disabled:

zeroshot template show software-change --delivery none > graph.json

Edit the graph, choose a runtime, and run it. The review loop guide has complete graph, input, and runtime files.

One graph per process your team runs.

• Graphs are JSON: steps, reviewers, branches, parallel work, bounded loops and maps over lists.
• Profiles: save each graph by name and pick one per run with --profile.
• Agent and model per node: Claude Code, Codex, Copilot CLI, Pi and more, through the providers each agent supports: OpenAI, Anthropic, OpenRouter, Bedrock, Foundry or your own endpoint.
• Delivery: a run can end by pushing a branch, opening a PR, or opening and merging one on GitHub, GitHub Enterprise or GitLab, or by leaving the change in your working copy. The built-in template software-change defaults to PR delivery.

Agents do the work. The graph decides what happens next.

• Checked before it runs: type mismatches, unbounded loops and unreachable branches are rejected before any agent starts. --validate-only runs just the checks.
• Reviewers route the run: each reviewer returns an enum verdict, and the graph routes on it.
• Script steps: run a deterministic command as a step in local runs.
• Secrets stay out of the record: credentials are stored once as named connections and kept out of graphs, run history, logs and the UI.

• zeroshot ui: each node's input, output and logs in the browser, on a timeline you can replay.
• CLI: status and list return JSON, watch and logs stream resumable events, attach follows a running agent.
• SQLite: one SQLite file per local run.
• Resume: restart a failed run from a checkpoint without redoing finished steps.

Drive zeroshot from your own code, CI or UI.

• Python SDK: async Python client for submitting, watching and waiting on runs. Each wheel bundles the matching zeroshot binary.
• JSON-RPC API: run zeroshot target serve and connect over WebSocket to submit runs, watch their status and which nodes are running, and stream logs. An OpenRPC spec describes the methods.
• API keys: expiring, revocable CI keys for hosted targets.
• Agent adapters: add support for another coding agent through a documented contract.

Run locally, self-host with Docker, or share graphs and run on zeroshot Platform using your own model API keys.

zeroshot sends no telemetry. The CLI contacts GitHub only to install or update, and otherwise only the model providers, Git hosts and targets you set up. See network access.

The Open Engine · Research blog · Discord · X · LinkedIn · Instagram

Development guide · UI development · Publishing · Security · Issues · Discord

MIT. See LICENSE.