yakanban

Most projects that need a board have one. So setup adopts rather than provisions: point yakanban at the project the team is already using and it takes the columns as it finds them, adding only the fields it needs to store a priority, a claim and a dependency. Nothing is renamed, nothing is deleted, and the product owner's view does not change under them.

Old issues are left alone too. An issue that was never put on the board is still readable, and the first write is what puts it there, so a repository with years of history joins one ticket at a time, as work actually reaches it, instead of arriving as a migration nobody asked for.

The greenfield case is the same command with nothing to adopt: it creates the project, links it to the repository and gives it the default columns.

A developer and an agent work in a terminal. A product owner works in a browser, on the project board they were already using. Neither of them is looking at a copy, and nobody had to install anything to see the other's work.

yakanban is a client, not a store. Every write goes straight to the tracker; reads pass through a one-minute cache so an agent can poll a board without spending someone's API quota. There is no state on disk to reconcile, and nothing to lose when a laptop dies.

That has a price, and it is worth saying out loud: without a network you have no board. Offline was traded for never being wrong about who owns what.

Two agents pointed at the same backlog will pick the same ticket. A claim is a soft lock, an agent name and an expiry written into two ordinary project fields, so the second agent is refused and goes to find other work.

Ordinary fields, because a human has to be able to see them. Open the project in the browser and the claim is a column like any other: who holds what, and until when. Nothing about the coordination is invisible to the person who did not install anything.

Expiring, because an agent that dies mid-task must not take a ticket with it. The lock lets go by itself after an hour, and a long task renews it by writing a progress note.

pick claims the next available ticket and reads the claim back before returning it. That read is the reason several agents on one board is safe: list-then-claim checks nothing, because the answer is stale by the time it arrives.

The hard part of handing a board to an agent is not the API, it is telling it when to claim, when to park a task and when to stop and ask. Two skill files carry that, and they are compiled into the binary, so a downloaded release installs them with no checkout. An agent that reads them drives a ticket the same way as every other agent on the repository, which is the difference between a board and a log of what one assistant felt like doing.

skill install detects Claude Code, Codex, Cursor, Gemini CLI, Antigravity, Hermes, Pi and OpenClaw, shows you what it found and lets you change its mind before it writes anything. A file you have edited since is never overwritten without --force: each one carries a hash of the text yakanban wrote, so "stale" and "you changed this" are different answers.

Fifteen commands, and every one of them takes the same global flags. There is no command that prints JSON and another that does not.

--compact prints one tab-separated line per record, which is what you want when the reader pays by the token. --json prints the whole record when it does not. Both are on every command, alongside --table, --no-color, --refresh and --no-cache.

The exit codes are the part a script actually reads. Code 5 in particular is not an error: it means another agent got there first, and the correct response is to pick something else.

yakanban stores no credentials. It reads $YAKANBAN_GITHUB_TOKEN, $GH_TOKEN or $GITHUB_TOKEN, and when none of them is set it asks the GitHub CLI for the token you are already using: gh auth token. So gh is a prerequisite for the ordinary path, and the error says so rather than failing somewhere deeper.

That is the whole authentication story, and it is deliberately not ours. There is no login command, no keychain entry and no token file to leak, because the credential belongs to a tool that already manages it, and in CI, where gh is not the natural answer, one environment variable takes over.

One thing will catch you once. Projects v2 sits behind its own OAuth scope, so an account that authenticated with gh before ever touching projects needs it added:

gh auth refresh -s project

Both cases, no credential at all or a credential without the scope, exit 4, and in both the message is the instruction:

The site serves an llms.txt at its root: the command reference, the exit codes, the two skill files and the backend mapping, as links an agent can follow instead of a page it has to scrape.

It is generated from the same sources as this page. A hand-written contract is the first file to go stale, and a stale contract is worse than none.