A Kanban Board for Claude Code: Plan the Work, Let Claude Pull the Next Card

A kanban board for Claude Code works best as a pull system. People do the planning: they write the cards, decide which are ready, and put the ready ones in order. Claude Code does the pulling: at the start of a session it takes the top ready card, moves it to In Progress, works it, comments what happened and moves it on. People then review what came out. The board is the contract between the two, and almost everything that goes wrong with an agent on a board comes from blurring who does which half.

Pull, not push

The push model is the one most people start with: open a session, type what you want, and let Claude Code decide what that means. It works for a single change. It stops working the moment there are ten things to do, because the order lives in your head, the scope lives in a chat message, and nothing survives the session except the diff.

The pull model moves both into the board. The order is the order of the ready lane. The scope is what the card says. The session prompt shrinks to one sentence — “take the next card” — and a new session, a different machine or a different assistant gets exactly the same instruction from the same place. You stop being the queue and become the person who fills it.

Lanes, read as instructions

An agent reads a lane as an instruction, so each lane needs one meaning and no exceptions. With the four fixed lanes fenbs uses, that reads:

• To Do — captured, not ready. Ideas, reports, things noticed in passing. Claude may add here but never pulls from here.
• Next Up — ready and ordered. Every card here is small enough and clear enough to start without asking a question. This is the only lane Claude pulls from.
• In Progress — being worked right now, by someone. If a card sits here overnight with no comment, something is wrong.
• Completed — finished and checked. A card arrives here with a comment saying what changed and how it was verified, or it does not arrive.

The line that does the work is the one between To Do and Next Up. Moving a card across it is a human decision: “this is ready, and it is more important than what is below it.” Keep that decision for people and the agent never works on something nobody agreed to.

A card an agent can finish

For a person, a card can be a week of work. For Claude Code, the useful unit is one session: one change, one commit, one check that says it worked. A card that fits that shape comes back finished. A card that does not comes back half-done, with a long comment explaining why, and the half-done state is the expensive one to review.

Three quick tests before a card goes into Next Up:

• Can you name the check? “The checkout test passes”, “the page renders at 390px”, “the export opens in a spreadsheet”. If the only check is “looks right to me”, the card is not ready.
• Does it touch one area? A card that needs the database, the API and two screens is three cards pretending to be one.
• Could someone else start it cold? If it relies on a conversation you had yesterday, that conversation belongs on the card.

What a good card says

fenbs gives every card two boxes, and they map neatly onto what an agent needs. The Problem is written once by whoever files it: what is wrong or missing, why it matters, and where — the file and line, or the screen. The Plan is how it will be done, written when somebody knows and rewritten as they learn. A person can write the plan before moving the card to Next Up, or leave it for Claude to fill in as its first step.

BUG-042  Bug · priority 3
Problem: Saving a draft invoice with no line items throws a 500.
  Expected a validation message. Seen on /invoices/new.
  Likely in src/invoices/save.ts:88, which reads items[0] unguarded.
Plan: Guard the empty case, return the "add at least one line" message,
  add a test for an empty draft. Done when the new test and the
  existing invoice tests pass.

Notice what is missing: no acceptance-criteria template, no story points, no labels to fill in. The kind (feature, enhancement or bug) and a priority number are enough structure. Everything else is sentences.

A WIP limit of one

The one rule of kanban is to limit work in progress, and it matters more for an agent than for a person. A person with three cards in progress knows which one they are actually doing. An agent that has moved three cards to In Progress has, at best, one real piece of work and two stale claims on the board.

So set the limit at one card per session. If Claude finishes early, it pulls the next. If it gets stuck, it comments why and moves the card back to Next Up — or to To Do, if the card turned out not to be ready — before it pulls another. fenbs has no WIP-limit setting to switch on; the limit is a rule you write into the instructions Claude Code reads, and the board shows at a glance whether it is being kept.

The pull loop, written down

Claude Code reads CLAUDE.md at the start of every session↗ (opens in a new tab). The pull loop is a few lines in it. Over MCP, fenbs names the lanes backlog, next, doing and done, and every card comes back with its priority, which is the number Claude uses to decide what is on top.

## Pulling work from the board
- A card in lane "doing" is claimed. Never take one unless I name it.
- List lane "next" and take the card with the lowest priority number.
  Never pull from "backlog"; that lane is not ready.
- Move it to "doing", then fill in its plan if empty (fenbs_update_item).
- One card at a time. Stuck? Comment why, move it back to "next", stop.
- Done? Comment what changed, the commit, and the check you ran; move it to "done".
- Noticed something else? File it in "backlog" with fenbs_create_item. Do not do it.

Two lines matter more than they look. “A card in In Progress is claimed” stops two sessions working the same card, because the move itself is the claim. “File it, do not do it” keeps scope where people can see it: the agent’s good ideas land in To Do, where a person decides whether they ever reach Next Up. The wider session rhythm — reading AI context first, reviewing the day in the history — is covered in a task-tracking workflow for Claude Code.

When to split a card

The board tells you when a card was too big. Split it when you see any of these:

• Claude’s plan has a “then” in the middle: “add the column, then backfill it, then change the screen”. Each “then” is a card.
• It moved back to Next Up with a comment that says “needs a decision on…”. The decision is a card for a person; the rest waits behind it.
• The comment on Completed lists three commits in different areas. It worked this time; next time, make it three cards.
• Two sessions in a row pulled it and neither finished. Stop pulling it and rewrite it.

When you split, link the pieces rather than nesting them. In fenbs, related tasks are linked both ways (relatesTo over MCP), so each piece stays a normal card with its own lane and the connection is still visible.

Other kanban tools for Claude Code

There are several ways to put Claude Code on a board, and they answer different questions. Local viewers such as claude-code-kanban↗ (opens in a new tab) read task files and transcripts that Claude Code already writes on your machine and draw them as a live board in the browser. Session managers such as Kanban Code↗ (opens in a new tab) make each card a Claude Code session, linked to its own git worktree, terminal and pull request. Both are built for one developer watching their own agents run.

A hosted board connected over MCP answers the other question: what should be worked on next, and what came of it, in a place other people can see and plan in. That is where fenbs sits. They are not mutually exclusive — a local viewer for the sessions in flight and a shared board for the plan is a reasonable pair.