Zeroshot Verification Loop
An engineering CLI that separates code generation from independent verification until a change passes or fails reproducibly.
Per-dimension scores and reasoning
Evidence shows: README explicitly supports worktree isolation, Docker isolation, --no-isolation escape hatch, and --pr/--ship requiring user confirmation; provider credentials are not stored, managed by CLI; SECURITY.md for vulnerability reporting; dependencies have overrides and CI security audit. Deductions: publisher unverified, source attribution based only on repo metadata; no key management details.
Evidence shows: extensive tests (unit, integration, E2E), CI includes typecheck, lint, security audit; README describes crash-safe SQLite ledger and resume command. Deductions: static review cannot verify tests pass or runtime behavior; dependency availability not fully verified.
Evidence shows: README clearly defines target users (developers), suitable scenarios (tasks with clear acceptance criteria), supports multiple providers and issue sources; options like --no-isolation adapt to different environments. Deductions: Windows not supported, limited environment fit.
Evidence shows: README, LICENSE, SECURITY.md, CONTRIBUTING.md present; install instructions clear; version auto-increments but noted unstable; known limitations (no TUI, Windows not supported). Deductions: version unstable, changelog not provided; maintenance responsibility unclear.
Evidence shows: README claims 100x speed, 90-minute run, 5 iterations, but no benchmark data; provides independent verification value. Deductions: cost-benefit not quantified, static review cannot verify performance claims.
Evidence shows: README describes architecture and process, has architecture diagram; tests verify specific behaviors; CI includes CodeQL and Trivy scans. Deductions: static review cannot verify runtime results; some claims (like speed) lack evidence.
- Publisher unverified, source attribution based only on repo metadata.
- Version auto-increments, unstable, pin version.
- Windows not supported, limited environment fit.
- Performance claims (like 100x speed) lack benchmark data.
- Static review cannot verify tests pass or runtime behavior.
What does this agent do, and when should you use it?
Zeroshot is an open-source multi-agent orchestration CLI for autonomous software engineering. It drives an installed coding CLI—Claude Code, OpenAI Codex, Gemini CLI, or OpenCode—through separate executor and independent verifier roles. A conductor classifies the task and selects a workflow; the executor edits code in place, in a Git worktree, or in Docker, while the verifier returns `APPROVED` or `REJECTED` with reproducible findings. Events and run state are persisted in a crash-safe SQLite ledger, allowing interrupted clusters to continue with `zeroshot resume <id>`. By default it edits files without committing or pushing; `--pr` and `--ship` extend the flow to worktrees, pull requests, and approval-gated auto-merge.
The zeroshot run <input> command accepts a GitHub issue number, issue URL, Jira key, Markdown file, or inline task text; it auto-detects GitHub, GitLab, Jira, and Azure DevOps issue backends from the git remote. Its conductor classifies the task and chooses agents and validators, the executor invokes the selected provider CLI to make the change, and an independent verifier examines the result without the executor's context or history. The verifier emits APPROVED or REJECTED; rejected runs repeat using actionable, reproducible failures, while events are appended to a SQLite ledger. Operators can use zeroshot list, zeroshot status <id>, zeroshot logs <id> -f, zeroshot stop <id>, and zeroshot resume <id>; zeroshot cmdproof check <id> reuses a verified exact command result. In --pr and --ship flows, the git-pusher fails closed until every configured quality gate has fresh passing evidence.
- A repository maintainer implementing a GitHub issue with measurable acceptance criteria who wants an independent agent to judge the completed change.
- A team already using OpenAI Codex that wants an executor-verifier harness around its existing coding CLI rather than a replacement model platform.
- A developer preparing a pull request who uses
--worktree --prto isolate work on a branch and open the PR only through the documented workflow. - A platform engineer running risky experiments or parallel changes who uses
--dockerfor container-based isolation. - A team whose autonomous coding run was interrupted by a reboot and needs to continue the persisted cluster with
zeroshot resume <id>.
What are this agent's strengths and limitations?
- The executor and verifier are intentionally separated, and the verifier does not see the executor's context or history.
- It supports Claude Code, OpenAI Codex, Gemini CLI, and OpenCode, so it can orchestrate an existing coding CLI.
- The SQLite ledger records run state and events durably, enabling resume after a crash or reboot.
- PR and ship handoffs fail closed when configured gates lack fresh passing evidence.
- Adoption requires Node.js 18+ plus installation and authentication of at least one external provider CLI.
- It is best suited to tasks with clear, testable acceptance criteria; the documentation identifies broad exploratory requests as poor fits.
- The default mode changes files without committing or pushing, so teams must review and manage those changes unless they opt into isolation or PR flows.
- Docker runs may mount credential directories such as
gh, git, and ssh, which requires careful mount review; Windows support is explicitly deferred.
How do you install or deploy this agent?
Install Node.js 18 or later and at least one supported provider CLI, then run:
npm install -g @the-open-engine/zeroshotInspect installed providers with:
zeroshot providersFor example, select Codex as the default:
zeroshot providers set-default codexTo retrieve work from an issue backend, install its corresponding CLI: gh for GitHub, glab for GitLab, jira for Jira, or az for Azure DevOps. The documented platforms are Linux and macOS; Windows is deferred.
How do you use this agent?
After authenticating at least one provider through its own CLI, start a task:
zeroshot run 123A local specification or inline request also works:
zeroshot run feature.md
zeroshot run "Add a --json flag"Override the provider for one run:
zeroshot run 123 --provider geminiUse the documented PR flow:
zeroshot run 123 --prFollow a run:
zeroshot logs <id> -fHow does this agent compare with similar options?
Against a single coding agent that decides for itself when it is done, Zeroshot uses an independent verifier to assess the result and return reproducible failures. It remains a harness around Claude Code, Codex, Gemini CLI, or OpenCode rather than replacing those coding providers.
FAQ
Does Zeroshot store provider API keys?
What happens when verification rejects a change?
REJECTED with an actionable, reproducible failure, and the loop repeats until the change is verified or a concrete reason is handed back.Will it automatically commit, push, or merge my code?
--pr uses a worktree and opens a pull request; --ship adds auto-merge on approval.