Great Cto

Ship products with the coding agent you already have.

npx great-cto init

Website · One real run → · Live demo · Blog · Changelog

Русский · 简体中文 · 繁體中文 · 日本語 · 한국어 · Español · Português · Deutsch · Français

great_cto is the layer around the coding agent you already run. It drives your Claude Code — or OpenAI Codex — through a whole build and hands you a repository you own and a URL that already works: architecture, data model, backend, frontend, generated tests and the deploy, finished. Not a plan. Not a prototype.

It is not a hosted app builder and does not replace your agent; without one there is nothing for it to orchestrate.

Seven products built end to end in the open benchmark cost a median of $171 in tokens. You pay your own LLM provider; great_cto bills you nothing and is MIT.

You are stopped three times — on what gets built, on how, and on whether it ships. Everything between those runs unattended, and it is the pipeline's job to be worth leaving alone: 69 specialist agents (architect, design-advisor, senior-dev, code-reviewer, QA, security, devops) with an independent model checking each stage's work before the next one builds on it.

   describe a product
        │
   🤖  problem framed · options weighed · brief written
        ▼
   👤  checkpoint 1 — approve WHAT gets built
        │
   🤖  architecture · data model · screens · plan
        ▼
   👤  checkpoint 2 — approve HOW it gets built
        │
   🤖  scaffold → backend → frontend → tests → review → security
        ▼
   👤  checkpoint 3 — approve the deploy
        │
   🤖  deployed · repo · live URL

Three checkpoints is the default, not the floor. One line in PROJECT.md takes it to one — you approve the deploy, and checkpoints 1 and 2 become a screen you read rather than a form you fill:

approval-level: ship-only

See When it asks you.

The board at localhost:3141 fills itself in — pipeline state, pending gates, per-agent cost, 30-day spend. You do not feed it; you check it.

Numbers, measured

The quality score is produced by running each product's own tests, not by counting files — which is why it says 70 and not a rounder, prettier number.

Quick start

npx great-cto init

Restart Claude Code, then:

/start "build a dispatch & scheduling app for an HVAC business"

The pipeline takes it from there. Day to day you touch three things:

Requires Node ≥ 18.17. Companion plugins (Superpowers, Beads) install automatically. After init, verify the host actually loaded the plugin — claude plugin list --json should show no errors for great-cto.

On OpenAI Codex (npx great-cto init --host codex) you get the skills and the MCP server — not the pipeline above. Codex has no plugin surface for hooks, slash commands or role agents, so /start, /inbox, the gate chain and secret-scan do not run there. That is a limit of the host, not a setting: hooks in a plugin manifest is never read (openai/codex#16430, #39895). The installer prints the same split before it does anything.

Two harnesses, one review. Since 3.26.0 Codex does take part in the pipeline — from inside Claude Code, as the second reviewer. Declare it once:

# .great_cto/PROJECT.md
capabilities:
  second_opinion: codex      # or: openrouter · none

and on every high-stakes change the Claude code-reviewer and codex exec (read-only sandbox, your Codex login, no API key) review the same diff at the same time. Findings merge; a P0 from either side blocks; where they disagree, both sets reach the human at the gate — the stricter one sets the verdict, and nobody averages. The board's Harnesses card detects Codex, holds the switch, and shows beside it what the second opinion did: every run, including skipped ones, from .great_cto/cross-review.log. Four states, and the fourth is the point — declared but unavailable is never shown as off.

How much it helps is measured there, not asserted here. What the log holds so far: the first real Codex review — of the commit that wired Codex in — found a P1 that the author and the test suite had both missed; the review of the fix found nothing. Two runs is evidence of the mechanism, not a rate. The rate is the card's job.

When it asks you

One setting in .great_cto/PROJECT.md decides where the pipeline stops:

Counts are pipeline stops. Every level also carries one guard that is not a process choice: importing data over existing records stops you at every level, auto included, because that one destroys what was there.

ship-only is the minimum that is still honest. One stop — the deploy, the only decision whose consequence leaves your machine. The what gets built decision does not vanish, because a pipeline that spends a day on the wrong thing is the expensive failure: it arrives as one screen in your console, printed once, before the build starts.

ABOUT TO BUILD — say nothing and this proceeds, say something and it stops.

  What gets built:  the offline-first checkout; ship the queue before the UI
  Why:              reliability wins this segment, not features
  Stop if:          under 20% of orders are created offline after four weeks
  Left open:        which conflict rule for a re-submitted order

  Full brief: docs/product/BRIEF-checkout.md

Silence is consent, and the screen says so. If the brief cannot be read, the gate comes back — "I could not show you" is never delivered as "you were shown and said nothing".

gates-only gained the product gate in v3.0.0. It used to stop on how to build and whether to release, and never on what to build — the decision that is wrong for six stages before anyone finds out. It costs one pause per product, not per feature: product-owner is an entry point and runs only from /start.

A regulated archetype — fintech, healthcare, gov — keeps its security, compliance and ship gates at every level, including auto. A lighter level delegates judgement; it never skips compliance. Full table: docs/GATES.md.

The three doubts worth having

“I can't trust code I didn't watch being written.” Neither do we, so nothing is taken on an agent's word about itself. Each stage is checked against what it actually produced — do the named files exist, do the frozen acceptance criteria pass when run, and only then is a separate model asked whether each requirement is addressed. Where that check cannot tell, it returns unverifiable, which is not a pass.

“It will spend money while I sleep.” Per-agent budgets decline to dispatch past their cap and name the number. A run whose cost could not be measured reads unmeasured and holds nothing — a limit firing on a number nobody measured is worse than no limit, and a confident $0.00 for unmeasured work is how a spend goes unnoticed.

“And then I'm locked in.” One command to install, MIT, running on your machine against your own LLM account. Delete great_cto and the repository it built is still yours — ordinary Next.js, Postgres and Stripe that any engineer can pick up.

What makes it different

• Specialists, not a generalist — 69 agents with narrow jobs and their own review gates, instead of one assistant that types faster than it thinks. The roster →
• Critics before code — architecture, spec, and schema critics run before planning, where a mistake still costs hours instead of days.
• Scope enforced at write time — an agent physically cannot touch files outside its brief. Not flagged at review; refused at write.
• QA that distrusts itself — critical paths written as Gherkin before test code, then mutation testing asks whether the suite would catch anything at all.
• Memory across sessions — decisions, lessons, and promoted patterns persist per project and globally; an interrupted run resumes knowing which stages ran.
• Cost you can see — per-agent spend, estimate-vs-actual drift, and cost-per-accepted-change on the board, not in a spreadsheet.
• Spending caps that refuse — agent-budgets: in PROJECT.md caps what a stage may spend, and the pipeline declines to dispatch past it, naming the number. An estimate never refuses: while no verdict carries a real cost the cap reads unmeasured and holds nothing, because a limit firing on a number nobody measured is worse than no limit. Set and cleared from the board.
• A stage is checked before the next builds on it — the pipeline used to hand one agent's output to the next on the strength of a line the agent wrote about itself. Now a second model (Kimi K3 via OpenRouter) checks it, cheapest question first: do the files the verdict names exist, do the frozen ## ACCEPTANCE criteria pass when run, and only then is a model asked whether each requirement is addressed. Three answers, never two — verified, rework, or unverifiable, which is not a pass: an agent that claims nothing and freezes no criteria is reported, or the cheapest way to pass becomes claiming nothing.
• Work goes back, and the return has a ceiling — a stage that fails verification returns REWORK with the findings quoted, and the agent that just ran fixes it. Distinct from BLOCKED, which means a human must decide. After three passes it stops being the agent's problem and becomes one, because two machines handing work back and forth do not get bored.
• Quality kept apart from what happened — the verdict says what a run did; a score says how well, in its own append-only store, produced by a different actor at a different time. A re-score appends rather than rewrites, several scorers can disagree about one run, and every score names who made it. An unassessed run counts as null, never zero — a pass rate divides by what was actually assessed and reports the rest beside it.
• Silence is recorded — the dispatcher writes what it decided to .great_cto/pipeline-runs.jsonl, including when it decided nothing and why. Every pipeline defect found this year hid in the gap between "nothing should happen" and "nothing could happen".

Everything runs locally, MIT-licensed, on your own keys. Your code stays on your machine; prompts go to your LLM provider and nowhere else. Telemetry is off by default (docs/PRIVACY.md).

Limitations

• For one builder — a solo founder or CTO. Two or more engineers sharing the pipeline have outgrown it.
• Not a CI/CD system — gates run locally; you still merge through GitHub Actions.
• Not certification-audited — PCI/HIPAA/SOC2 scaffolds are starting points, not certifications.
• Not deterministic — LLM output. Gate verdicts deserve a sanity check.
• Spend is measured, attribution is not yet per-agent — cost is read from the host's own session transcript rather than from an agent's self-report, so the tokens are real. But the transcript the hook is handed covers the session, not one subagent, so a run's cost can be attributed to whichever stage finished last — inflated by orders of magnitude. Treat per-agent figures as a ceiling until this is fixed. A stage with no measurement at all still shows unmeasured rather than a confident $0.00, and budgets do not fire for it.

Documentation

Docs hub → · Getting started · Gates & approval levels · Agents · Commands · Archetypes · Architecture · MCP · FAQ · Everything else — critics, jurisdictions, cost breakdown, CI, alerts

Community

Issues · Discussions · Blog · Security policy · Contributing

MIT — LICENSE. Built by @avelikiy: CTO building AI-native trading and fintech platforms; great_cto is my own loops, automated one agent at a time.

If it saved you time, a star helps other solo builders find it.

Stop being the only person who can ship.