Skip to content

How Docket works

Docket has two parts. The board is at app.usedocket.dev: it holds your cards and shows what has happened to them. The adapter is a small program your coding agent’s client runs on your machine. It gives the agent a set of tools for reading and changing the board, and it is the only part that looks at your repository.

Docket does not run your agent, and it never changes your code. Your agent does the work with its own tools; Docket tells it what to work on and keeps the record.

  1. Cards go on the board. You write them, or you tell your agent what needs doing and it writes them. A card says what done looks like. See Cards.
  2. The agent claims the next card. It calls claim_next and is handed the next card that is ready, with a brief: the goal, the constraints, the files it may change, notes from the work it builds on, and the command that says when it is finished. See What is next.
  3. It does the work, in your repository, as it would any other task.
  4. It finishes the card. It runs the card’s command and reports the result with finish_card, leaving notes for whoever picks up the cards that depend on this one.
  5. You review and merge. A finished card is a proposal. The board notices when its work reaches your main branch. See The life of a card.

Then it claims the next one.

A project is one repository’s board. Docket finds it from the repository’s remote: the first time an agent connects from a checkout, a project is made for it, and every other checkout of the same repository lands on the same project.

Each project has a short key taken from the first letters of the repository’s name, and its cards are numbered under it: a repository called billing-api has cards BIL-1, BIL-2 and so on.

In a directory that is not a git repository, or one with no remote, the adapter still works. Its cards go to a single default project, and anything that depends on git (noticing a merge, the list of files a card changed) is left out.