🎉 New in v5.4: Now supports OpenCode CLI! Use Claude, Codex, Gemini, or OpenCode as your AI provider. Also supports GitHub, GitLab, Jira, and Azure DevOps as issue backends. See Providers and Multi-Platform Issue Support.

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

Demo (100x speed, 90-minute run, 5 iterations to approval)

Zeroshot is an open-source AI coding agent orchestration CLI that runs multi-agent workflows to autonomously implement, review, test, and verify code changes.

It runs a planner, an implementer, and independent validators in isolated environments, looping until changes are verified or rejected with actionable, reproducible failures.

Built for tasks where correctness matters more than speed.

How It Works

• Plan: translate a task into concrete acceptance criteria
• Implement: make changes in an isolated workspace (local, worktree, or Docker)
• Validate: run automated checks with independent validators
• Iterate: repeat until verified, or return actionable failures
• Resume: crash-safe state persisted for recovery

Quick Start

zeroshot run 123                    # GitHub issue number
zeroshot run feature.md             # Markdown file
zeroshot run "Add dark mode"        # Inline text

Or describe a complex task inline:

zeroshot run "Add optimistic locking with automatic retry: when updating a user,
retry with exponential backoff up to 3 times, merge non-conflicting field changes,
and surface conflicts with details. Handle the ABA problem where version goes A->B->A."

Why Not Just Use a Single AI Agent?

Use Cases

• Autonomous AI code refactoring
• AI-powered pull request automation
• Automated bug fixing with validation
• Multi-agent code generation for software engineering
• Agentic coding workflows with blind validation

Who Is This For?

• Senior engineers who care about correctness and reproducibility
• Teams automating PR workflows and code review gates
• Infra/platform teams standardizing agentic workflows
• Open-source maintainers working through issue backlogs
• AI power users who want verification, not vibes

Install and Requirements

Platforms: Linux, macOS. Windows (native/WSL) is deferred while we harden reliability and multi-provider correctness.

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

Requires: Node 18+, at least one provider CLI (Claude Code, Codex, Gemini, Opencode).

# Install one or more providers
npm i -g @anthropic-ai/claude-code
npm i -g @openai/codex
npm i -g @google/gemini-cli
# Opencode: see https://opencode.ai

# Authenticate with the provider CLI
claude login        # Claude
codex login         # Codex
gemini auth login   # Gemini
opencode auth login # Opencode

# GitHub auth (for issue numbers)
gh auth login

Providers

Zeroshot shells out to provider CLIs. Pick a default and override per run:

zeroshot providers
zeroshot providers set-default codex
zeroshot run 123 --provider gemini

See docs/providers.md for setup, model levels, and Docker mounts. See docs/provider-cli-helper.md for the strict TypeScript provider helper, the zeroshot-agent-provider JSON executable contract, and the boundary with Orchestra.

Why Multiple Agents?

Single-agent sessions degrade. Context gets buried under thousands of tokens. The model optimizes for "done" over "correct."

Zeroshot fixes this with isolated agents that check each other's work. Validators can't lie about code they didn't write. Fail the check? Fix and retry until it actually works.

What Makes It Different

• Blind validation - Validators never see the worker's context or code history
• Repeatable workflows - Task complexity determines agent count and model selection
• Accept/reject loop - Rejections include actionable findings, not vague complaints
• Crash recovery - All state persisted to SQLite; resume anytime
• Isolation modes - None, git worktree, or Docker container
• Cost control - Model ceilings prevent runaway API spend

Required Handoff Quality Gates

Zeroshot owns a tool-neutral handoff contract for --pr and --ship flows. It does not know which tool produced a gate. Repos configure required gates, validators publish matching qualityGates evidence, and the git-pusher trigger refuses to wake until every configured gate has fresh passing evidence after IMPLEMENTATION_READY.

Gate config can come from run options or repo settings:

{
  "ship": {
    "requiredQualityGates": [
      {
        "id": "repo-quality",
        "scope": "repo",
        "description": "Repository quality gate",
        "command": "repo-quality --changed --json"
      }
    ]
  }
}

The id and optional scope are generic. A repo may bind repo-quality to any local quality command, a CI status command, or another quality command outside Zeroshot. Validators receive the configured gate list and must publish entries with status, completedAt or timestamp, and evidence.command, evidence.exitCode, and string evidence.output. Failing or unavailable commands mean approved: false with gate status FAIL or UNAVAILABLE.

The pusher fails closed before commit, push, PR creation, or merge when a configured gate is missing, failing, unavailable, stale, older than IMPLEMENTATION_READY, or lacks usable evidence. If no requiredQualityGates are configured, Zeroshot preserves its existing validator consensus behavior.

When to Use Zeroshot

Zeroshot performs best when tasks have clear acceptance criteria.

Rule of thumb: if you cannot describe what "done" means, validators cannot verify it.

Command Overview

# Run
zeroshot run 123                      # GitHub issue
zeroshot run feature.md               # Markdown file
zeroshot run "Add dark mode"          # Inline text

# Isolation
zeroshot run 123 --worktree       # git worktree
zeroshot run 123 --docker         # container

# Automation (--ship implies --pr implies --worktree)
zeroshot run 123 --pr             # worktree + create PR
zeroshot run 123 --ship           # PR + auto-merge on approval

# Background mode
zeroshot run 123 -d
zeroshot run 123 --ship -d

# Control
zeroshot list
zeroshot status <id>
zeroshot logs <id> -f
zeroshot resume <id>
zeroshot stop <id>
zeroshot kill <id>

# Providers
zeroshot providers
zeroshot providers set-default codex

# Agent library
zeroshot agents list
zeroshot agents show <name>

# Maintenance
zeroshot clean
zeroshot purge

Multi-Platform Issue Support

Zeroshot works with GitHub, GitLab, Jira, and Azure DevOps. Just paste the issue URL or key. When working in a git repository, zeroshot automatically detects the issue provider from your git remote URL. No configuration needed!

# GitHub
zeroshot run 123
zeroshot run https://github.com/org/repo/issues/123

# GitLab (cloud and self-hosted)
zeroshot run https://gitlab.com/org/repo/-/issues/456
zeroshot run https://gitlab.mycompany.com/org/repo/-/issues/789

# Jira
zeroshot run PROJ-789
zeroshot run https://company.atlassian.net/browse/PROJ-789

# Azure DevOps
zeroshot run https://dev.azure.com/org/project/_workitems/edit/999

Requires: CLI tools (gh, glab, jira, or az) for the platform you use. See issue-providers README for setup and self-hosted instances.

Important for --pr mode: Run zeroshot from the target repository directory. PRs are created on the git remote of your current directory. If you run from a different repo, zeroshot will warn you and skip the "Closes #X" reference (the PR is still created, but won't auto-close the issue).

Architecture

Zeroshot is a message-driven coordination layer with smart defaults.

• The conductor classifies tasks by complexity and type.
• A workflow template selects agents and validators.
• Agents publish results to a SQLite ledger.
• Validators approve or reject with specific findings.
• Rejections route back to the worker for fixes.

                                ┌─────────────────┐
                                │      TASK       │
                                └────────┬────────┘
                                         │
                                         ▼
                ┌────────────────────────────────────────────┐
                │                 CONDUCTOR                  │
                │     Complexity × TaskType → Workflow       │
                └────────────────────────┬───────────────────┘
                                         │
           ┌─────────────────────────────┼─────────────────────────────┐
           │                             │                             │
           ▼                             ▼                             ▼
     ┌───────────┐                ┌───────────┐                ┌───────────┐
     │  TRIVIAL  │                │  SIMPLE   │                │ STANDARD+ │
     │  1 agent  │──────────▶     │  worker   │                │ planner   │
     │ (level1)  │  COMPLETE      │ + 1 valid.│                │ + worker  │
     │ no valid. │                └─────┬─────┘                │ + 3-5 val.│
     └───────────┘                      │                      └─────┬─────┘
                                        ▼                            │
                                 ┌─────────────┐                     ▼
                             ┌──▶│   WORKER    │             ┌─────────────┐
                             │   └──────┬──────┘             │   PLANNER   │
                             │          │                    └──────┬──────┘
                             │          ▼                           │
                             │   ┌─────────────────────┐            ▼
                             │   │ ✓ validator         │     ┌─────────────┐
                             │   │   (generic check)   │ ┌──▶│   WORKER    │
                             │   └──────────┬──────────┘ │   └──────┬──────┘
                             │       REJECT │ ALL OK     │          │
                             └──────────────┘     │      │          ▼
                                                  │      │   ┌──────────────────────┐
                                                  │      │   │ ✓ requirements       │
                                                  │      │   │ ✓ code (STANDARD+)   │
                                                  │      │   │ ✓ security (CRIT)    │
                                                  │      │   │ ✓ tester (CRIT)      │
                                                  │      │   │ ✓ adversarial        │
                                                  │      │   │   (real execution)   │
                                                  │      │   └──────────┬───────────┘
                                                  │      │       REJECT │ ALL OK
                                                  │      └──────────────┘     │
                                                  ▼                           ▼
     ┌─────────────────────────────────────────────────────────────────────────────┐
     │                                COMPLETE                                     │
     └─────────────────────────────────────────────────────────────────────────────┘

Complexity Model

Model Selection by Complexity

Levels map to provider-specific models. Configure with zeroshot providers setup <provider> or settings.providerSettings. (Legacy maxModel applies to Claude only.)

Create a zeroshot cluster config for security-critical features:

1. Implementation agent (level2) implements the feature
2. FOUR parallel validators:
   - Security validator: OWASP checks, SQL injection, XSS, CSRF
   - Performance validator: No N+1 queries, proper indexing
   - Privacy validator: GDPR compliance, data minimization
   - Code reviewer: General code quality

3. ALL validators must approve before merge
4. If ANY validator rejects, implementation agent fixes and resubmits
5. Use level3 for security validator (highest stakes)

Look at cluster-templates/base-templates/full-workflow.json
and create a similar cluster. Save to cluster-templates/security-review.json

Crash Recovery

All state is persisted in the SQLite ledger. You can resume at any time:

zeroshot resume cluster-bold-panther

Isolation Modes

Git Worktree (Default for --pr/--ship)

zeroshot run 123 --worktree

Lightweight isolation using git worktree. Creates a separate working directory with its own branch. Auto-enabled with --pr and --ship.

Docker Container

zeroshot run 123 --docker

Full isolation in a fresh container. Your workspace stays untouched. Useful for risky experiments or parallel runs.

When to Use Which

Default behavior: Agents modify files only; they do not commit or push unless using an isolation mode that explicitly allows it.

# Configure via settings (persistent)
zeroshot settings set dockerMounts '["gh", "git", "ssh", "aws", "azure"]'

# View current config
zeroshot settings get dockerMounts

# Per-run override
zeroshot run 123 --docker --mount ~/.aws:/root/.aws:ro

# Provider credentials
zeroshot run 123 --docker --mount ~/.config/codex:/home/node/.config/codex:ro
zeroshot run 123 --docker --mount ~/.config/gemini:/home/node/.config/gemini:ro

# Disable all mounts
zeroshot run 123 --docker --no-mounts

# CI: env var override
ZEROSHOT_DOCKER_MOUNTS='["aws","azure"]' zeroshot run 123 --docker

zeroshot settings set dockerMounts '[
  "gh",
  "git",
  {"host": "~/.myconfig", "container": "$HOME/.myconfig", "readonly": true}
]'

zeroshot settings set dockerContainerHome '/home/node'
# Or per-run:
zeroshot run 123 --docker --container-home /home/node

zeroshot settings set dockerEnvPassthrough '["MY_API_KEY", "TF_VAR_*"]'

Resources

• CLAUDE.md - Architecture, cluster config schema, agent primitives
• docs/providers.md - Provider setup, model levels, and Docker mounts
• docs/context-management.md - Context selection, context packs, and state snapshots
• Discord - Support and community
• zeroshot export <id> - Export conversation to markdown
• sqlite3 ~/.zeroshot/*.db - Direct ledger access for debugging

Contributing

See CONTRIBUTING.md for development setup and guidelines.

Please read CODE_OF_CONDUCT.md before participating.

For security issues, see SECURITY.md.

TUI

The TUI is not included in this release. Use zeroshot logs -f, zeroshot logs -w, zeroshot list, and zeroshot status <id> for monitoring.

MIT - The Open Engine Company

Built on Claude Code by Anthropic.