Maverick

AI coding agents can write code, but they can't run your development process. You still prompt them one at a time, babysit validation, manually re-run after lint failures, coordinate reviews, and stitch it all together into a PR. You've automated the typing but not the workflow.

Maverick fixes this. Point it at a spec and it becomes beads — atomic units of implementation with acceptance criteria, file scope and dependencies wired up. Then step back. Maverick picks up each bead in order and flies it through implementation, validation, parallel code review, accountability-tracked fixes, and a clean commit. When one bead lands, it grabs the next.

This is what development on autopilot looks like — with a flight recorder running.

But autopilot isn't just about speed. It's about letting go of the controls — and being able to check the log afterwards.

Queue up a dozen features before lunch. Come back to find them implemented, reviewed, and committed — each one validated by specialized agents that catch what you'd miss on your fourth cup of coffee. The completeness reviewer checks requirements coverage. The correctness reviewer audits quality, security, and style. Every finding goes back to the agent that wrote the code, which still has the context to fix it properly.

Maverick doesn't just run agents — it choreographs a roster of specialized personas across six workflows. Implementers hand off to validators. Validators trigger fixes on failure. Reviewers run in parallel. The cycle repeats until everything passes or the budget runs out and a human gets asked.

From a spec to a stack of clean commits. From a backlog to a branch ready to push. #ComeFlyWithMe

Four phases. Spec writes the plan. Refuel loads the work. Fly executes it. Land ships it.

Spec runs your repository's own Spec Kit chain — specify, clarify, plan, tasks, analyze — headlessly, from a PRD. Clarify never blocks: questions the chain would have asked you interactively are answered, adopted, and filed for review later. Each completed step lands its artifacts in specs/NNN-feature/ as ordinary markdown you can read and edit. Interrupt it and it resumes from the first incomplete step.

maverick spec my-feature --from-prd prd.md

Refuel ingests that spec into beads — one epic, one bead per open task, with IDs, phases, parallel markers and file scope preserved and dependencies wired as a phase barrier. It makes zero model calls: the task list already carries the information, so Maverick parses it rather than asking a model to re-derive it. Run it again after the spec grows and only the new tasks are added. --dry-run previews the whole plan and writes nothing.

maverick refuel my-feature --speckit

Fly picks up the next ready bead and runs the full cycle: implement, validate with retry, a deterministic spec-compliance check, parallel review, accountability-tracked fixes, then a commit through Jujutsu. When one bead lands, it grabs the next. Work happens directly in your checkout, so you watch the diff appear — or pass --isolated to give each bead its own jj workspace that folds back only once it passes.

maverick fly --epic <epic-id> --auto-commit

Land curates your commits into clean history with a curator agent, then pushes and opens a PR — but only once every assumption the agents made has been answered or waived. More on that below.

maverick land

No Spec Kit in the repository? The original path still works end to end: maverick plan generate turns a PRD into a flight plan through a briefing room of parallel agents, and maverick refuel decomposes it with a model instead of a parser.

Your terminal shows the flight log:

  Maverick — Flight Log
  ---------------------

  ✓ bead-001  Add user model         implemented · reviewed · committed
  ✓ bead-002  Add auth middleware     implemented · reviewed · committed
  ⟳ bead-003  Add login endpoint     implementing...
    bead-004  Add session management  queued

This is the part that makes walking away defensible.

Every autonomous agent makes judgment calls it wasn't authorized to make. Most tools bury them in a commit message, or never surface them at all. Maverick treats an adopted assumption as a first-class artifact: whenever an agent adopts one — not only when it gets stuck — it reports the question it faced, the answer it chose, the alternatives it rejected, and how severe the call was. Each becomes a tracked entry under the owning epic, linked to the work that spawned it and stamped with the change ID once it commits.

Severity decides what happens next. Low-severity calls drop out of the ready queue and wait. High-severity ones block the next epic from starting until you've weighed in — so a bad assumption can't quietly become the foundation for a week of work.

Reviewing is a sweep, not an archaeology dig. maverick review --list shows the open queue with full provenance, and every verb speaks JSON, so the whole console works headlessly — including from a phone terminal.

maverick review --list                  # what's open, and why
maverick review <id> --answer "use UTC"  # resolve one
maverick review --spec my-feature --waive "accepted risk"
maverick reconcile                      # fold answers back into history
maverick land --status                  # can I land yet?

Every phase is powered by specialized personas, each bound to a provider and model you choose.

On the flight-plan path, Maverick doesn't trust one agent to do all the thinking.

The Briefing Room is a deliberation pattern that runs before decomposition. Three domain experts analyze the problem in parallel, each from a different angle. Then a fourth — the Contrarian — reads all three briefs and challenges their assumptions, identifies blind spots, and proposes simplifications. A deterministic synthesis step extracts the key insights into one coherent document.

It runs twice, tuned to different stages. The Pre-Flight Briefing turns a PRD into a flight plan — a Scopist draws the boundaries, a Codebase Analyst maps requirements onto existing code, a Criteria Writer drafts independently verifiable success criteria, and a Pre-Flight Contrarian attacks all three. The Refuel Briefing then turns that plan into work units, with a Navigator on architecture, a Structuralist on data models and contracts, Recon on risk and testing strategy, and the Contrarian challenging the lot.

Why not just ask one agent to plan everything? Because three independent perspectives catch more than one, the contrarian forces intellectual honesty, and the structured synthesis makes the reasoning auditable — you can read exactly which agent raised a concern and what the contrarian thought about it.

On the Spec Kit path this machinery isn't needed: the clarify step already asked the questions, and ingestion is a parser.

Because prompting is the easy part. The hard part is everything around it.

You can ask an agent to implement a feature. But who validates the output? Who runs the linter, the type checker, the tests? Who reads the review findings and decides what to fix? Who commits with a clean message? Who handles it when the tests fail and the agent needs to try again with different context? And when it quietly decided your timestamps were local time — who tells you, and what happens to the code once you disagree?

That's orchestration. That's what Maverick does. It turns "ask an agent to write code" into a complete, repeatable development workflow — with the same rigor you'd expect from a human team, but without the manual coordination.

Orchestrating agents reliably is harder than it looks. Most runners ask a model to produce structured JSON inside its prose, then parse it with retries when it arrives wrapped in markdown, missing a field, or carrying a hallucinated key. It's the architectural equivalent of duct tape, and it fails often enough that you stop trusting your own pipeline.

Maverick doesn't parse model prose. Every agent declares a Pydantic result model, and the runtime constrains the model to return exactly that shape — wrong shape, and the agent gets a validation error and self-corrects. The schema is the contract, and there's no parsing layer to break.

Each workflow is an explicit state machine. Actions are plain async functions that declare which slots of state they read and write; a graph wires them into transitions. There's no hidden chain and no implicit control flow — the routing lives in one file per workflow, and you can read it and know exactly what happens next.

Provider choice is a config decision, not an architectural one. Every model call goes through a single runtime abstraction, so agents are portable across providers — and within a bead, the implementer keeps its context from writing the code through to fixing the review findings, then starts clean on the next one.

This isn't the part of Maverick you'll see in your first five minutes. It's the part that means Maverick is still working in your fifteenth hour.

uv tool install git+https://github.com/get2knowio/maverick

Maverick is pre-1.0 and moving quickly, so install from main until the first stable release. It also needs jj (Jujutsu) for the commit path and bd (beads) for the work queue.

Initialize the project, write a spec, load it, and fly:

# Detect your providers and write maverick.yaml
maverick init

# Check prerequisites and credentials
maverick doctor

# Seed the runway with a codebase analysis
maverick runway seed

# Run the Spec Kit chain headlessly from a PRD
maverick spec my-feature --from-prd prd.md

# Ingest the spec into beads (zero model calls)
maverick refuel my-feature --speckit

# Implement, validate, review, and commit
maverick fly --epic <epic-id> --auto-commit

# Answer what the agents assumed, then ship
maverick review --list
maverick land

Or run fly continuously and keep adding work in another terminal:

# Terminal 1 — fly drains beads as they appear
maverick fly --watch --auto-commit

# Terminal 2 — keep speccing and refueling
maverick spec feature-2 --from-prd feature-2.md
maverick refuel feature-2 --speckit

All you need is an authenticated provider and something to build.