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.
The loop
Section titled “The loop”- 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.
- The agent claims the next card. It calls
claim_nextand 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. - It does the work, in your repository, as it would any other task.
- 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. - 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.
Projects
Section titled “Projects”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.
In this section
Section titled “In this section”- Cards: what a card holds, and what makes a good one.
- The life of a card: claims, the claim token, and why done is not merged.
- What is next: how the next card is chosen.
- Scope and collisions: keeping two agents out of the same file.
- Versions and features: grouping cards.
- Git rules: what a project can require of an agent’s branch and pull request.