What's on the screen

There isn’t much to memorise. Three things and one distinction, and tuckit works out the rest.

The smallness is deliberate. A model small enough for an AI to hold all at once is one it doesn’t get wrong, and one you never explain twice.

Org

The container inside your account. One company, or one project, depending on how you split things. Every area, card and member lives inside one.

An org has a short lowercase name used in addresses. Call it acme and your board is at /acme/board/. tuckit shortens that into the prefix on every card number, so you get ACME-42.

Those numbers earn their keep. Paste ACME-42 into a chat and both a person and an AI know exactly which card you mean.

One account can hold several orgs, but one agent connection reaches exactly one of them. If you run more than one project, that choice matters. Running several projects is about making it.

Area

A broad heading: frontend, backend, docs, infra.

Areas change rarely. They exist to hold cards, and an area is the only place a card can be filed. If you’re making an area per feature, you probably wanted a card.

Card (Slice)

One piece of work, from the moment someone thinks it matters to the moment it’s finished. The same card the whole way.

There’s no lighter object to jot into and no heavier one to graduate to. A passing thought and a quarter’s work are both cards, and the difference is how much has been written into one.

Inside are three boxes doing three different jobs. Keeping them apart is most of the skill.

What we’re building. Labelled Spec on screen. What you’re making and why. Empty means nobody has worked it out yet, and that’s a useful thing for the board to be able to say. Don’t fill it in just to make the card look complete.

What must not break. Labelled Constraints. The things a later reader would get wrong if nobody told them. “Don’t touch the payment code.” “The invoice export shares this function, so don’t change what it returns.” This is the box that keeps working after the session ends. Write it as though handing the work to someone who knows nothing.

Which area it’s in. Labelled Area. Empty means it’s still in the Inbox.

Plus a number (ACME-42), a status, an assignee and tags.

The Inbox isn’t a separate place

It isn’t a queue or a different kind of object. It’s the name for a card with no area that isn’t finished yet.

Writing something down before deciding where it goes is a proper path, not a fallback. You often know something matters before you know where it belongs. Setting an area files it; clearing the area sends it back. Both work.

Steps

The work inside a card, broken into an ordered list. Each one is todo, doing, done or dropped.

Usually an agent writes them and ticks them off. You can add and tick your own. Ticking them is what moves the card across the board, which is the next section.

If you ever look at the list of MCP tools, these appear there under the name Bite. Same thing as the Steps on screen.

Activity

A running log underneath each card. It records what happened: what was tried, what broke, where the work landed. It only ever gets added to.

So three boxes cover three different tenses:

Box	Tense	The question it answers
Spec	Future	What are we building, and why?
Constraints	Standing	What must never go wrong?
Activity	Past	What actually happened?

What you decide, and what tuckit works out

This is the one confusing part, and getting it wrong teaches the wrong habit. There’s a single test: who decides?

Status is a call a person made. One of open, shipped or dropped. It never changes on its own.

Stage is worked out by tuckit. It looks at what’s inside the card and recomputes every time. It isn’t stored anywhere, and neither you nor an agent can set it.

Stage	What it means	What moves it on
needs_design	The “what we’re building” box is empty	Work it out and write it in
needs_steps	It’s written, but there are no steps	Break it into steps
executing	There are steps and some are unfinished	Finish them
ready_to_ship	Every step is done	A person calls it finished
shipped / dropped	Finished. Follows Status	Nothing

So nobody moves progress by hand. Write what you’re building, write what must not break, tick steps off, and the position follows. The only manual move is the last one, because “this is actually done” is a judgement rather than a calculation.

Read progress from Stage. Read decisions from Status. A card sitting at open tells you nothing about how far along it is; one at ready_to_ship tells you it’s waiting on you.

The board

The board groups cards by Stage, not Status. Four columns, showing only work that’s moving.

You can’t drag cards between columns, because a card’s column comes from its contents. Dragging a card into the “worked out” column wouldn’t work it out.

Finished (Shipped) and abandoned (Dropped) aren’t columns. They sit below the board as counts you can click through, so finished work stays findable without taking up room that moving work needs.

Start to finish

1. Something comes up. Write it down as a card with no area. It lands in the Inbox.
2. Decide it’s worth doing. Give it an area. Reversible.
3. Work out what to build and write it into Spec. Past needs_design.
4. Break it into steps. Now executing.
5. Do them, ticking as you go, toward ready_to_ship.
6. Call it finished. The one part that’s yours.

Anything put off for later belongs on the board too. A committed next step is a card with an area; a vaguer idea is a card with none. Something that exists only in a chat window doesn’t exist.

The same thing, worked through

Monday, you notice signups break on Safari. You make a card called Signup fails on Safari and type nothing else. No area, so it’s in the Inbox; the “what we’re building” box is empty, so its stage reads needs_design. Total effort: a title.

Wednesday, you decide it matters. You put it in the frontend area. It leaves the Inbox and joins that area’s list. Still needs_design, because nobody has worked out what the fix is.

Thursday, you and your agent find the cause and it writes the finding into Spec. It also writes into Constraints: the date parser is shared with the invoice export, so don’t change what it returns. That’s the sentence that keeps working after the session ends. The stage becomes needs_steps on its own.

The agent adds four steps and the stage becomes executing. It works through them, ticking as it goes, and leaves a note in the log with a link. The last tick makes the stage read ready_to_ship.

Nobody moved that card. You set three things (an area, what you’re building, what must not break) and one remains: deciding it’s actually done.

Words you won’t find here

Older writing about tuckit mentions Workspace, Ticket and Plan. All three are gone. Workspaces became orgs, and tickets and plans folded into the single card, because making people pick an object type before they knew what the work was turned out to be the problem.

The words are org, area, card and steps. That’s the list.