What kanman is | kanman documentation

kanman is your team’s own assistant. It lives in your team chat, knows your code and your people, keeps its habits while you are away, and each of you can also talk to it privately. It does the engineering work itself: you describe what you need, as a goal or a story, in the app, in Slack or in Microsoft Teams; kanman plans the work, has it written by helpers that each work in their own sandbox, checks every change with your repository’s CI and an independent review, merges it, and shows you every step while it happens. It asks you only what it cannot find out itself, and it asks once, in one place.

kanman is built on Claude Code. What it adds is everything a team needs around it: someone who keeps the whole board moving, a second pair of eyes on every change, limits that hold no matter what the model says, and a record of what was done and why.

Five ideas to know

Everything in kanman builds on five ideas. Each one has its own part of these docs.

Idea	In one sentence
kanman	One teammate for the whole team that each of you can also talk to privately. It does the work, says “I” and shows its proof.
Mind	The team’s board of outcomes and stories, and its memory: what kanman knows about your code, your conventions and your systems.
Habits	What kanman keeps doing on its own, for the team or just for you: when, what, where, and how far it may go.
Stories	One piece of work with acceptance criteria, from the first sentence to a merged, checked change.
Connections	A system kanman reads and acts in, with what it may do there: off, ask first or automatic.

Below these sit the ground rules each team sets: who is in the team, its hours, budget, models, repositories and connections. They do not do anything themselves; they bound what kanman may do.

You talk to kanman

Your workspace opens on a conversation with kanman. It is where you see what happened since your last visit, answer what needs you and hand over new work:

Describe work. Write a goal in a few sentences or paste a requirement. kanman turns it into stories on the team’s board and starts.
See it happen. The line above the message box shows how many helpers are at work and what each one is doing right now.
Answer what needs you. kanman’s questions wait for you in one place, with the options it sees. You answer once, and kanman goes on.
Ask why. Ask “why did you merge INT-241?” and kanman answers from what it recorded at the time.

kanman also answers in Slack and Microsoft Teams, in the same voice. See Talk to kanman.

How the work flows

Stage	What happens	Where you come in
1. Describe	You describe a goal or a story, or move a story to Ready.	You decide what matters.
2. Plan	kanman reads the board, the code and the notes, splits the work into stories and decides the order.	You see the plan in the activity log and can change it any time.
3. Work	Helpers write the code, each in its own sandbox on its own branch, and open a merge request.	Hand a story to yourself or a colleague whenever a person should do it.
4. Check	Your CI runs on the change. Then a reviewer that did not write the change checks it against the story’s acceptance criteria.	Read the review on the merge request if you like.
5. Merge	When CI is green and the review approves, kanman merges.	Review the merged change, or ask why it was done that way.

How a story flows walks through one example with a diagram.

What kanman owns, and what it uses

kanman owns the parts that make an AI teammate safe to run in a team: planning across the board, the independent review, the limits around every change, the questions to people and the record of what happened.

It uses what you already have:

Claude Code writes the code, with your own model provider contract if you bring one.
The tracker. GitHub Issues, GitLab issues or Jira, or kanman’s own board if you have none.
The code host and CI. GitHub or GitLab, including self-managed GitLab, and the CI pipelines your repositories already run.

You do not move your backlog, your repositories or your review process into kanman.

One teammate, not a crowd of bots

There is exactly one kanman in your workspace. It says “I”, shows up next to your colleagues in assignee lists, notes and on the board, and every action it takes is recorded under its name. It uses helpers for the work, and you see them at work, but you never manage a roster of agents.

Limits that hold

The important limits are not instructions to a model; they are enforced where the action happens:

kanman works only on your team’s repositories and pushes only its own branches. Your protected branches and your code host’s merge rules always apply.
A change merges only when CI is green and a reviewer that did not write it approved it. There is no other way for kanman to merge.
Code host tokens and model keys never reach the helpers that write the code, and every change is scanned for credentials before it is pushed.
Each helper works in its own sandbox, never on the machine itself.
Each team has one daily budget. When it runs out, kanman stops and says so.

If your team wants a person to approve every merge, require approvals on the code host: kanman then waits for that approval like any other teammate. See How kanman checks its work.

Who kanman is for

kanman is built for engineering teams of roughly 5 to 50 people that already use GitHub, GitLab or Jira, have tried coding tools individually, and now want a teammate that works the team’s board with the rest of the team. The person who sets it up is usually a head of engineering, a CTO or a tech lead. The people who work with it every day are the developers who describe work, answer questions and hand stories back and forth.

kanman is not a general project management tool, and its conversation is not a chat assistant for everything. It talks about your team’s work and does engineering work, inside your process.

Where kanman runs

kanman Cloud: work runs on isolated machines in Frankfurt, Germany.
Self-hosted runner: the same environment as a container in your own infrastructure. It connects outward to kanman, so you open no inbound ports.

See Hosting and data residency for details.

Next steps

Try it: Your first hour has six short steps, each with something to paste into the chat.
See the path of the work: How a story flows.
Set kanman up on your own code: Set up a team.