A task-tracking workflow for Claude Code that you can actually review

Claude Code will happily work for an hour on a goal you gave it in one sentence. The difficulty is not getting it to work; it is knowing, afterwards, what it did. A transcript is the wrong shape for that: thousands of lines, most of them tool output, none of them a summary. What you want at the end of the hour is a list — what it added, what it finished, what it could not do — and the way to get one is to make the list part of the job.

Step one: give it a board, not a key

Connect Claude Code to a fenbs board over MCP. It is one command and a browser sign-in; no API key is pasted anywhere, and the token it ends up holding acts as you, narrowed by the scopes you ticked when you approved it.

claude mcp add --transport http fenbs https://fenbs.ai/api/mcp

Then, inside Claude Code, /mcp and choose fenbs. The browser opens, you sign in, you tick read, write and comment, you press Approve. From then on it can call the board’s tools by name: fenbs_list_items, fenbs_create_item, fenbs_update_item, fenbs_comment. Everything it does with them is recorded in the board’s history as “Claude via <you>”, which is the whole point.

Step two: tell it the rhythm, once

Claude Code reads a CLAUDE.md file at the root of your project at the start of every session. Four lines in it turn the board from something it can use into something it does use.

## The board
- Before starting any task, call fenbs_get_context, then fenbs_list_items for the In Progress lane.
- Work from the board: if what I ask is not on it, create the task first (kind: bug for a fix, feature for something new, enhancement for a change).
- When you start a task, move it to In Progress and comment what you intend to do.
- When you finish or get stuck, comment what happened (with the commit or the error), and move it to Completed only if the tests pass.

Two of those lines do more than they look. Reading AI context first means the assistant starts with what you have written down about how you work — naming, what never to touch, where things are — instead of rediscovering it. And “move it to Completed only if the tests pass” makes the lane mean something: a card in Completed is a card whose tests were green when it got there.

Step three: give it the right amount of permission

The first week, tick read and comment only. Claude Code can then read the board and report — “I would move BU-014 to Completed; the fix is in commit a1b2c3” — while you make the moves. Once you trust what it reports, tick write. If you narrow your own role on the board later, its token narrows with you at once; if you revoke the token, it stops and your own sign-in is untouched.

What a session looks like

1. You: “Fix the failing tests in the payment module.”
2. It calls fenbs_whoami, then fenbs_get_context, then lists In Progress. It finds BU-031 “Payment retries double-charge” already there.
3. It moves BU-031 to In Progress and comments “Reproducing with test_retry_idempotent; suspect the retry key is per attempt, not per order.”
4. It works. Forty minutes of tool calls you never need to read.
5. It comments “Fixed in 7f3e21a; retry key is now the order id. Tests pass (41/41).” and moves BU-031 to Completed. It also files EN-032 “Log retry attempts with the order id” as an enhancement it noticed.
6. You open the board’s history: two entries by “Claude via you”, in words. Done.

Reviewing a day in five minutes

The board’s History page lists every change with who made it. Filter your eye to the “Claude via” lines. Each one names a task and says what changed — moved, commented, created — and each task’s own page shows the assistant’s comments in order. If a move to Completed looks wrong, move it back; the history records that too, under your name. That is the review: not the transcript, the list.

Three habits that keep it honest

• Make it file what it notices. An assistant deep in one bug sees three others. “Create an item for anything you notice but do not fix” costs nothing and the backlog gains real entries with real context.
• Keep AI context short and true. Five notes it reads every time beat fifty it skims. When it learns something — “the staging database resets nightly” — ask it to add a context note, signed with its name.
• Do not let it close what it did not test. The Completed lane is only worth anything if it is strict about what gets in.