How it works

CubeDot has two halves. In the first, you turn an idea into a product spec. In the second, that spec drives your AI coding agent as it builds. The point of connecting them is simple: an agent working from a real spec ships the right thing; an agent working from a prompt ships a guess.

Architecting the spec

You start by talking to the Project Architect. Describe the product, or drop in what you already have (a brief, some notes, a few screenshots). It drafts the first document and you refine it.

The work is split into ten gates, each one a decision the next depends on: the brief sets direction, features break it into buildable units, the tech stack and data model give those units shape, and so on. Each gate reads the gates above it, so nothing is decided in isolation. Change something upstream and everything downstream that relied on it is flagged for another look.

Two rules keep the spec honest: a gate stays locked until the one before it is committed, and you can’t commit a gate that’s still incomplete.

Building against it

When the spec is ready, one CLI command connects it to your codebase. It writes an MCP config and a set of agent instructions, plus a .cubedot/ ledger.

From there your agent reads the full spec over MCP and builds functionalities in an order that works, because Gate 09 already worked out what depends on what. The ledger records each functionality moving from open to done, so progress is something you can see rather than guess.

What you end up with

A set of spec documents you own (they live in your repo), and a build loop where the agent always knows the next right thing to build. Not a prompt. A plan.

Next

• Quick start: idea to connected repo.
• Core concepts: the handful of terms worth knowing.
• Connecting your repo: put your agent to work.