Independent executor–verifier orchestration for software changes.
翻訳待ち
Loading the full README. The saved excerpt is shown below.
The agent that writes the code should not be the one that decides it works.
Zeroshot turns a software goal into an explicit multi-agent graph. One agent implements. Independent
agents review. Failures route back into bounded repair. Delivery happens only after the graph's checks
pass.
Delivery is explicit: keep work local, push the managed branch, prepare a mergeable PR, or ship it.
PR and ship runs process visible GitHub feedback unless their delivery runtime binding opts out.Read the full README ↗A multi-agent orchestration engine that keeps coding agents from grading their own work.
zeroshot.sh · Docs · Research blog · Discord
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.
--profile.software-change defaults to PR delivery.Agents do the work. The graph decides what happens next.
This is the beginning of the README. Read the rest at the original. Read the full README ↗