Code review | kanman documentation

kanman takes part in code review the way a good colleague does. Its independent reviewer reads your team’s pull and merge requests and leaves clear, concrete comments. When people review kanman’s own work, it reads their comments and acts on them. Both work on GitHub and GitLab.

Review people’s merge requests

Reviewing is the built-in habit Review merge requests on the team’s Habits tab (/<workspace>/teams/<team>/habits/review-merge-requests). It shows when kanman reviews and its last reviews, each linked to its merge request. To change it, tell kanman in the team’s chat:

You say	What happens
(nothing, the default)	On request: write `@kanman review` in a merge request, request kanman as reviewer, or assign the merge request to kanman. Only people with write access to the repository can ask.
“Review every merge request people open”	Every merge request: kanman reviews every merge request a person opens or adds commits to in the team’s repositories. Drafts are left out until they are ready. `@kanman review` works too.
“Pause reviewing our merge requests”	kanman reviews only its own merge requests until you start it again.
“When you review, always check the migrations”	kanman keeps your words with the habit and follows them in every review.

Only the team’s owners and leads can change it. kanman’s own GitHub and GitLab accounts are set under Team > Connections > My accounts and mentions (see Mentions and assignments). Other names that count as kanman, for example a GitHub team called kanman, are under Team > Budget and limits, More options, Reviewers of my merge requests.

Habits tab: the built-in habit Review merge requests opened, reviewing every merge request people open, and its last reviews

kanman reviews each new commit once. When the author pushes again, kanman reviews the new state and does not repeat itself.

What a review contains

kanman’s reviewer checks out the change, reads the diff, runs the relevant tests and looks at what your CI and scanners already said (linters, security scanners, SonarQube). It then sorts what it found:

Blocking: something that must change before merging, for example wrong behaviour, a dropped or weakened test, or a security finding the change causes. All blocking findings come together in one review comment: “Changes requested: 2 blocking findings”, each with where it is, why it matters and a suggested fix.
Should and nit: smaller points, each as a comment on its line.

When nothing blocks, the review comment says so. Every comment is marked as written by kanman, an AI agent.

What kanman never does on your merge requests

kanman only comments. It never approves, pushes to or merges a person’s merge request: the author decides and merges. These limits are enforced by kanman itself, not just promised. Each review stays within the team’s Tokens per review.

In the team chat

After a review, kanman says it in the team chat in one line, for example “I reviewed Bob’s MR web !12: 2 blocking findings”. The merge request is a link.

Review comments on kanman’s own work

When people review a pull or merge request kanman opened, kanman reads each comment and acts like a colleague: it fixes what is clear on the same branch, answers questions, and asks when a person should decide. kanman’s own merge requests are reviewed by its independent reviewer before they merge (see How kanman checks its work), whatever the habit above says.

Asking a reviewer for kanman’s work

With Ask a reviewer who knows the code in Team > Budget and limits (under More options, Reviewers of my merge requests), kanman asks one teammate to review each pull or merge request it opens, once. It picks someone who recently worked on the changed files and has write access to the repository. It never asks the author, its own accounts or bots, and it asks nobody when a reviewer is already set. This is off until you turn it on, because kanman contacts people on your code host.

Human approval before merge

Some teams want a person to approve every change before it lands, for example because their software process requires a second pair of eyes. Under Approval before merge in Team > Budget and limits choose:

Choice	What happens
Workspace default	The team follows the workspace’s choice (shown in brackets).
Required	kanman merges its own pull and merge requests only after a person with write access to the repository approved them on GitHub or GitLab.
Not required	kanman merges once its independent review and CI are green.

When approval is required:

Only a person counts. Approvals by kanman’s own accounts, by bots or by people without write access don’t. On GitHub the approval must be for the latest commit, and an open request for changes stops the merge.
kanman asks your team in the team chat, with a link to the merge request, and waits. The question also appears where your team sees what waits on whom, and reaches people through their notification settings. kanman asks once per change.
One approval per wave. When kanman makes the same change in many repositories (for example a dependency update), the team approves one merge request and that approval covers the others with exactly the same change. Every merge request still merges only with green CI.
Answer Don’t merge this change to stop it. kanman leaves the merge requests open and asks what should change.

Workspace owners and admins set the default for all teams in Workspace settings > Audit (/<workspace>/settings/audit) under Merges need a person’s approval. It is off unless you turn it on.

GitLab behind a VPN

A GitLab that only your runner reaches cannot send kanman webhooks. @kanman review and assignments still work: kanman looks for them every few minutes through your runner. Reviewing every merge request needs the merge request events of a webhook. The code stays on your runner: the reviewer reads it there, and only the comments leave your network. See GitLab behind a VPN.