Skip to content

What is tuckit?

If you build software with AI agents, and especially if more than one person on your team does, this will be familiar.

On Monday you and your AI agreed to fix one thing later, and never to touch another. On Tuesday a teammate’s agent picked up the same code. Nobody told it either thing. Both agents did good work, and the two pieces do not fit. When someone asks whether the feature is done, the answer is spread across two chat windows, and they disagree.

tuckit is a web page where those decisions get written down, along with what would count as done for each piece of work and what somebody actually saw when they checked. You can open it and read it. Every agent on the team opens the same page and writes to it directly.

A board split into four columns: Needs design, Needs steps, In progress, Ready to ship, with cards in each.

Everything you are building sits here as a card. The further right, the closer to finished.

  • Needs design: you have decided to do it, but not what to build
  • Done when?: you know what to build, but not what would settle that it is finished
  • In progress: there is a target, and nobody has met it yet
  • Ready to ship: somebody went and looked, and wrote down what they saw

You cannot drag these cards. When the contents change, tuckit moves them. So you never have to wonder whether a card is in the right column: nothing put it there except what is inside it.

One card in detail: Stage, Area, progress and tags at the top, then Spec, Constraints, and a Steps checklist marked done, doing and todo.

A card is one piece of work. tuckit calls it a slice (Slice). The name does not matter much; what is inside it does. There are four boxes.

What we’re building. Labelled Spec on screen. Leave it empty if you haven’t decided yet. Empty is the signal that says nobody has worked this out. Filling it in to make the card look finished just teaches your AI that the thinking is done.

What must not break. Labelled Constraints. Sentences like “don’t touch the payment code” or “leave the login screen design alone”. This is the first thing an AI reads when it picks the work up.

How we’ll know. Labelled Done when. One sentence saying what somebody would have to see to call this finished. “Run the tests” is a command and a card can satisfy it while the thing is still broken; “a date survives a save and a reload” is a sighting, and it can turn out to be false. Write it before the work, so it is a target the work can miss.

What was actually seen. Labelled Evidence. Filled in after somebody went and looked. tuckit does not judge it — it cannot run your tests — but it will not let a card be called finished while this box is empty.

Underneath, a running log (Activity) collects what actually happened: what was tried, what broke, where it landed.

When you don’t know where something belongs

Section titled “When you don’t know where something belongs”

The Inbox: four items with no area set, each with a “Choose area…” dropdown beside it.

Sometimes you notice something and have no idea where to file it. Type a title and leave it. It lands in the Inbox and you can sort it later, or unsort it again. Nothing here is one-way.

When you ask your AI to do something, it reads this board before it starts. What has been built, what was decided, what must not break: it is all written down, so it starts from what was already decided instead of from a guess.

When it finishes, it writes back. What it did, what blocked it, what it agreed to do next. Close the window and it is still there. A teammate’s agent, or a different AI tomorrow, reads the same board.

Both sides can do both. Anything the AI can write, you can write on the web page, and the other way round. Neither one hands off to the other; you are working on the same surface.

None of that happens because the board is there. A board your agent can reach is still a board you keep up to date by hand.

So the other half of tuckit is a one-command install into your agent, and what it puts there is a way of working. Three things arrive with it.

  • A live connection to your workspace, wired up already. No server to register, no token to carry between windows.
  • Two moments. One at the start of a session, sending the agent to the board instead of to git log. One before it stops, turning what it noticed along the way into cards — after showing you the list.
  • A set of named ways of working: designing a piece of work, building it, checking it for real before calling it done, landing it, tidying up afterwards. Each one writes what it produced onto the card, rather than into a markdown file the next session will never find.

The third is the part that is easy to underestimate. It is the difference between an agent that can reach your board and an agent that leaves it true.

Claude Code, Codex CLI and Antigravity all get the same set. What you install goes through it.

Coding agent. An AI that edits your code directly. Claude Code, Codex CLI, Antigravity and others. It doesn’t just show you code in a chat window; it opens your files, changes them, and runs things. This site shortens it to “agent”.

MCP. The name of the standard those agents use to reach tools outside themselves. tuckit follows it, which is why an agent can read and write your board without anyone building an integration first. Knowing the name is enough; you never have to learn how it works.

Past those two, there is not much new to learn. If you only ever use the web page, you need neither.

  • Not a memory feature. Nothing here belongs to one conversation or one vendor’s app. Switch which AI you use and the board is unchanged.
  • Not a general issue tracker. No sprints, no due dates, no estimates. Coming from Jira lists everything that’s missing.
  • Not agent-only. The web page is a real product surface, not a debug view.

So you don’t go looking:

  • A changelog.

If you want the pitch rather than the manual, tuckit.dev is the place for that.