Guide · Claude Code
Claude Code for teams: who is working on what right now?
Claude Code runs in each developer's terminal. The rest of the team cannot see what happens there. This guide shows how Claude Code writes its own tasks to a shared kanban board, with status, time and cost, without anyone logging work after the fact.
- Claude Code
- 5 steps
- macOS, Linux, Windows
- Updated October 30, 2026
The problem
To the rest of the team, every session is invisible.
Claude Code works on the machine of the person who started it, with its own history and its own context. For that person, this is handy. For the team, it means nobody else knows what the session is working on, whether it is stuck or whether it finished long ago.
Once two or three people run several sessions in parallel, the questions start in chat. Who is doing the login right now? Did yesterday's fix land? What did this cost this week? A ticket system only helps if someone keeps the tickets up to date. That is the first thing to go when an agent finishes in ten minutes what the ticket would take longer to write.
The way out: Claude Code keeps the board itself. It creates the task before it changes the first file and closes it after the commit.
On the board
What your team sees when Claude Code logs its own work.
One card per task, live for everyone who has the board open.
- Who: the person and their agent, such as “Anna · Claude Code”
- Where: the project and the branch, read from Git by the CLI
- The status in four fixed columns: Backlog, In progress, On hold, Done
- What the session is doing right now, such as “Thinking” or “Testing”, and whether it is asking you something
- The time worked, measured from the status changes, no stopwatch
- Tokens and estimated AI cost per task, from the session's own log
Day to day
You say what needs doing. Claude Code logs the rest.
A rule in the repository tells Claude Code when to run which command of the CLI. You work as usual.
- 01
Create and start
Before Claude Code changes the first file, the task is on the board, with you as the person and Claude Code next to you.
- 02
Test
No command of its own. Claude Code runs tests, lint and typecheck as always, and the card shows “Testing”.
- 03
Wait, if needed
If the task depends on an approval, it moves to On hold. Waiting time does not count as time worked.
- 04
Close
After the commit, Claude Code moves the task to Done, with a sentence on what it did and the link to the pull request.
Several agents
From a concept to tasks, built by several sessions at once.
Claude Code can plan a whole project and put it in the backlog as tasks. Several sessions then work through them in parallel, and the board shows which one is on what.
- 01
Write the concept
Have Claude Code write a concept for the project and break it into tasks that can be built one by one.
- 02
File the tasks
Claude Code creates each task with a description in the backlog, without starting it.
- 03
Start in parallel
Start several sessions, ideally each in its own Git worktree so they do not get in each other's way, and tell each one which task to take: “do #31”.
- 04
Follow it on the board
Every session works under its own task, and the gate counts per session. The board shows live which task is already running, which is testing and which is waiting for you, and
workban task listshows the next session what is already taken.
Set up
Connected in five steps.
Once per machine and once per repository. The setup page has the install command for your system.
- 01
Create a workspace
Sign up, no card needed, and give your team's space a name.
- 02
Install the CLI
One command in the terminal installs the Workban CLI, for macOS, Linux and Windows. You do not need Node.
- 03
Create a token
In Workban, open the user menu, go to Tokens and create a personal access key. You see it only once.
- 04
Log in
The CLI signs in on your behalf with the token, once per machine.
- 05
Connect the repository
Run this in your project's folder. From then on, Claude Code creates its own tasks.
workban init
What goes into the repository and what stays on your machine.
You commit the files in the repository once, and the workflow applies to everyone who clones it. The hooks live in your user settings.
- .workban.toml
- Which Workban project the repository belongs to.
- .claude/rules/workban.md
- The workflow: when Claude Code creates a task, starts it, puts it on hold and closes it. Claude Code loads the rule every time a session starts.
- .claude/skills/workban/SKILL.md
- How the CLI commands work. Claude Code loads the skill only when it needs it, which saves context.
- CLAUDE.md
- A pointer to the rule.
- ~/.claude/settings.json
- The hooks: they block changes without a running task, show what is running when a session starts and report token usage after every turn. In repositories without
.workban.tomlthey do nothing.
Gate
Even the quick fix in between ends up on the board.
As long as Claude Code has not started a task of its own, Workban holds back its changes in the repository. So it creates the task before it begins.
- Applies to Edit and Write always, and to shell commands as soon as they visibly write
- Counts per session: a second session in the same repository needs its own task
- A subagent works under the task of the session that started it
- Anything outside the repository, such as
/tmp, stays open - If Workban cannot be reached, the gate lets everything through. Your work never stops
Questions
What teams want to know first.
Do I have to work with Claude Code differently?
Does Workban read our code?
What does it cost?
Does it work with my Claude subscription, such as Max?
What about Codex and other agents?
Get started
Try it with your next task.
Workban is free. Your workspace is ready in a minute, and the first task appears as soon as your agent gets going. The app itself speaks German for now.