The Plan tab

You never have to plan before you build — type a change in the thread and it builds. But for anything with more than one moving part, the Plan tab is where you think it through first.

Two panes

Every project’s Plan tab is a brainstorm thread beside a ticket tree:

• The brainstorm thread is a conversation with the plan agent — a product partner you steer. It helps you break a direction into work, but it writes tickets, not code: nothing builds and nothing deploys from here. It only acts on what you ask for — it won’t invent scope of its own.
• The ticket tree is that work, structured. Tickets nest — a goal holds its epics, an epic holds its features — so a large project reads as a tree instead of a flat list.

What a ticket in the tree carries

Every field is editable inline, on the row:

• Status — backlog, active, done, failed, archived. Done is the terminal state: it means the work is built, not that it is live. Going live is a separate action — see Deploys & rollback.
• Type — goal, epic, feature, fix, chore. Goals and epics are structure: they exist to hold other tickets, and they are never built directly.
• Priority and an optional due date. An overdue ticket is marked as such.
• Labels — free text, as many as you like. Filter the tree by them.

The tree filters by status and by label, and it has separate views for open, done, and archived work, so a long-running project stays readable.

README.md

Your product keeps a README.md, and it is a real file in your app — the same one that lands in your GitHub repo. It says what the product is, who it’s for, what it does, and, under Non-goals, what it deliberately will not do.

Both agents write it and both carry it in every turn, so it is the one piece of context that survives a long conversation — what they fall back on when the transcript is trimmed. That makes the Non-goals list the most valuable thing in it: the code can show what you built, but nothing except that list records what you ruled out. Without it, an agent will cheerfully rebuild the login you removed.

It is rendered on the Overview tab, and it is the fastest way to see what you actually have. If the agents keep building the wrong thing, the README is usually why.

You change it the same way you change anything else here — by saying so. Tell either agent “we’re building for solo photographers, not agencies” or “we are never adding a signup wall” and it rewrites the README. It is not shipped with your live app, so your Non-goals stay yours.

From plan to build

A buildable ticket — a feature, a fix, a chore — has a Send to Build button. Press it and you land in the Build tab with that ticket attached to the thread, and the build agent picks it up: it writes the code and turns on what the feature needs. Planning decides what; building makes it real.

The button follows the ticket’s status:

• Send to Build while the ticket is open.
• Retry once a build has failed.
• Open once it’s done — it takes you to the thread to read what happened or keep iterating.
• Restore on an archived ticket, which returns it to the backlog.

A goal or an epic has no Send to Build button at all. It has Add instead, because structure tickets are containers: you build the tickets nested under them, one at a time.

When to reach for it

Type-and-build is right for a single, clear change. Come to the Plan tab when you’re scoping a bigger project, want to see the whole shape of the work before committing to any of it, or need to park tickets to build later. Everything you build still lands in project history the same way.