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            # Claude Code (default) · add --host codex for OpenAI Codex

Restart your AI host, 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.

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.