Claude Code workflows · controlled Codex runs (experimental) · MIT · — npm downloads
Run coding workflows.
Inspect the evidence. Decide what ships.
Coordinate Claude Code workflows and experimental controlled Codex runs with explicit
gates, review evidence and a local project workspace. See the task, inspect what was
recorded and resolve the next decision without treating missing evidence as a pass.
Bring your own authenticated coding CLI. Native workflows and controlled
runs have different capabilities; publication and deployment remain explicit operations.
The 60 products collapse into 6 reusable build pipelines (CRUD vertical-SaaS, booking, CRM, dashboard, marketplace, content) — each ships through three default stops — one line in PROJECT.md takes it to one — then automated to a live URL. See how it works ↗
How it works
Describe it. Review the evidence. Decide what ships.
1 · Describe
Say what you want to build.
A dispatch app, a booking portal, a CRM, a dashboard — name the product and the industry. The architect and design-advisor draft the spec, data model and screens.
2 · Review
Check the plan and the evidence.
Review architecture, configured checks and recorded outcomes. Required gates depend on the selected workflow and risk policy; missing evidence remains unknown, not approved.
3 · Decide
Build → test → review.
The configured workflow coordinates implementation and verification. Production deployment requires a supported adapter, infrastructure and separate authorization. Controlled Codex artifact publication does not activate a production service.
Role symbols match the admin. They identify responsibilities, not run status or measured quality. Explore the roles →
Every day
Three commands carry the day. The rest wait until you need them.
Start work
/start "…"
A new product or a task in an existing project. It picks the workflow; three decisions stay yours — what to build, how, and whether it ships.
What needs you
/inbox
Only the decisions waiting on you: gates, blockers, P0s. Nothing to scroll past.
Continue
/resume
Picks up where you left off — only what you already approved. A pending decision still waits for you.
The same three from the terminal, on Claude Code or Codex: great-cto run "…" · great-cto status · great-cto resume — add --host codex for Codex. All commands →
The dashboard
The task, its evidence and your next decision.
great-cto board opens a local workspace with Work, Decisions, Knowledge, Insights and Settings. Keep the selected project in view. Recorded activity is not proof of acceptance; a missing measurement stays unavailable.
Sample project, synthetic records. Captured from the 3.70 interface; not a live-model benchmark.
Follow the recorded execution. New controlled runs retain a controller-recorded causal graph of attempts, checks, verification, gates and repair. Native and legacy sessions remain partial or unavailable; missing links are not inferred. This is not a live terminal or workflow editor.See what still needs proof. Execution, checks, review, publication and runtime stay separate. A role verdict alone does not prove independent review.Keep project context close. Read Markdown and ADRs with source paths. Supported diagrams describe architecture, not live execution; other syntax keeps its source fallback.Separate outcomes from consumption. Project token consumption and estimates are not acceptance or quality scores. Missing actual task cost stays unavailable.
All screenshots above use isolated synthetic ACME data. The execution graph comes from the actual controller using offline stub responses, not live models. No customer projects, real provider calls or quality-uplift results are shown. Executors, Runtime and Capabilities remain under Settings. Capture contract.
Claude Code, controlled Codex and mixed runs: what is different?
Claude Code uses native commands, specialist roles and hooks. The experimental controlled runtime owns role dispatch, validated text proposals, the verifier and gates, and can route selected roles to either CLI. Eligible reviewers can inspect one frozen tree concurrently; they do not edit the same worktree concurrently. Ordinary Codex plugin sessions load skills, MCP and safety hooks, not the controlled pipeline automatically. Native sessions and legacy runs can have incomplete execution linkage. Host capabilities and recovery.
Domain packs remain opt-in. Their presence is not evidence of expertise or improved outcomes.
Receipts, not projections
One feature, end to end: 1h 26m and $3.40 in LLM cost.
A historical public run: spec → build → review → tests → merged PR, with timestamps and artifact links. It is not a benchmark of the current mixed-host pipeline or domain packs. No current-version quality uplift is established.
A whole product, not one feature
median $171 · 70/100
The open benchmark built 7 products end to end: median $171 in tokens, median quality 70/100 (range 58–86). Reproduce it with scripts/bench-run.sh.
The same feature with GreatCTO
1h 26m · $3.40 LLM
Architect → plan → implementation → review → tests → merged PR. Wall-clock from prompt to ship, with one human signing the spec.
A local engineering workflow system for Claude Code and experimental controlled Codex runs. Explicit stages, review and gates connect the work to its evidence. The board groups Work, Decisions, Knowledge, Insights and Settings. Ordinary Codex plugin sessions provide skills, MCP and safety hooks, not the controlled pipeline automatically. Merge, release and deployment require their own authority and evidence.
What can it build?
Real software products across 15 US industries — home & field services, professional services, retail, fitness, proptech, marketing, HR, construction, logistics, restaurants, plus regulated verticals: allied health, insurance agencies, accounting firms, dental practices and law firms, where great_cto auto-attaches the matching HIPAA, NAIC, SOX or trust-accounting compliance reviewer. The 60 products collapse into 6 reusable build pipelines: CRUD vertical-SaaS, booking, CRM, dashboard, marketplace and content/media.
How much is automated?
Automation follows the selected host, approval policy and supported capabilities. The default policy pauses at product, architecture and ship decisions. Required risk-specific gates remain; unsupported external operations require manual action. Approval of a stage does not grant unrelated merge, release or deployment authority.
What does it cost?
GreatCTO is open source (MIT) and runs locally. Use your own coding CLI and provider account. Provider subscriptions, usage charges and infrastructure are separate; token-price estimates are not your actual invoice. GreatCTO charges no seats or retainers.
Where does my data go?
The board and project files are local. Your coding hosts send prompts and selected code or tool context to their providers under your account. There is no GreatCTO-hosted dashboard or required GreatCTO account, and telemetry is off by default. External integrations have their own data policies. Privacy details.
How do I start?
Run npx great-cto init, describe the product you want, approve the spec, and GreatCTO builds and ships it. No signup required.
Enough reading.
Describe the product. Ship the software.
$ npx great-cto init
Describe a product · approve the spec · the pipeline builds & deploys it
Open source · MIT · self-hosted · your code stays on your machine
