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
Section titled “Architecting the spec”You start by talking to the Project Architect. It first asks how defined your project is, from “looking for ideas” to “fully defined, ready for development”, and meets you there: if your idea is still rough, it consults with you to sharpen it before any documents exist. Describe the product, or drop in what you already have (a brief, some notes, a few screenshots), and it drafts the first document for you to refine.
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
Section titled “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.
Staying in sync
Section titled “Staying in sync”The spec isn’t frozen once building starts. Publishing it creates a numbered version, and when the plan needs to change you open Update current sprint, make the changes as one batch, and commit them as the next version. Meanwhile the CLI writes back what actually happened, and the PM Hub shows every functionality’s real status, including where the build deviated from the plan.
What you end up with
Section titled “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.
- Quick start: idea to connected repo.
- Core concepts: the handful of terms worth knowing.
- Connecting your repo: put your agent to work.