Skip to content

The Manager and Build

The Manager is the chat beside the board. It sees the project brief, the loops, the Task Book and the last few passes, so you can ask it about the board as well as plan with it.

A mode decides what the Manager is allowed to change. The conversation stays in a mode until you switch it; the Manager never switches on its own.

Mode Reads your files Can change
Ask Yes, when a folder is bound PROJECT.md only
Plan Yes, when a folder is bound Task Book cards, after you agree, and PROJECT.md
Code Yes Files inside one loop’s folder, and PROJECT.md
Build No Proposes a board, placed only when you press Build
  • Ask answers questions about the project and the board.
  • Plan turns a conversation into cards. It asks before writing them.
  • Code edits files directly, held to one loop’s folder. If that loop is running a pass in the same folder, the Code turn waits for it.
  • Build designs loops. See below.

When something matters, the Manager asks. A question comes with two to six options, at most one of them marked as recommended, and a free-text box. Nothing is preselected. A question you leave unanswered counts as “no preference”.

You can type while the Manager is working. The message is read at its next step, as a steer, rather than waiting for the turn to end. Editing an earlier message forks the conversation; the other version is kept.

Every loopspace with a folder has a PROJECT.md at its root. It is yours: it lives in the project, not in the app’s own folder, and it is meant to be committed. Every pass of every bubble reads it first.

It has two sections the app knows about:

  • Rules: how the project must be built. The Manager changes this only when you ask.
  • Current state: where the project stands.

If you ask for the project to be deployable, the Manager adds a Deployable line under Rules. From then on bubbles keep the production build passing and a deploy config beside it. You can turn this off from the brief’s panel.

Build lays out a board for you in two stages:

  1. It reads what it knows (the brief, the Task Book, the conversation), proposes a structure in plain words, and asks whether it is right.
  2. Once you agree, it proposes the loops: the bubbles in each, a prompt for each bubble, the folder each loop may write, and the detours each loop takes on failure.

The summary shown beside the Build button is exactly what Build will do. Pressing it:

  • asks for the loopspace’s folder first, if a proposed loop writes code and none is bound;
  • asks Edit or Replace when a proposed folder already belongs to a loop;
  • asks before replacing a team prompt you wrote by hand.

A loop that builds something a person looks at gets a designer before its coder and a reviewer after it, which runs the visual review. A loop with no interface gets neither.

An empty board or an empty Task Book is not a problem: when too little is known, Build asks.

The Task Book holds the board’s cards in six columns: Draft, Approved, Implementing, Review, Done and Blocked.

  • Loops take only Approved work. Draft is your gate.
  • Cards you type, and cards a planner bubble writes during a run, start in Draft.
  • Cards the Manager writes in Plan start in Approved, since you agreed to them in the chat.
  • A loop that finishes a card moves it to Review, where it waits for someone to agree.