Code review
kanman reviews your team's merge requests like a careful colleague: on request or every one, with comments only. It never approves, pushes to or merges a person's merge request.
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
Open Team > Code review (/<workspace>/teams/<team>/team/review). Under Review people’s merge requests, choose when kanman reviews:
| Choice | What happens |
|---|---|
| Off | kanman does not review your team’s merge requests. |
| On request (default) | 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. |
| Every MR | 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. Pick repositories to limit it to them; with none picked, all of the team’s repositories count. @kanman review works too. |
The page also shows kanman’s own GitHub and GitLab accounts as they are set in Chat and mentions, with a link there. Under Names that count as kanman you can add other names, for example a GitHub team called kanman. Type a name and press Enter to add a chip.
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), never through the setting above.
Asking a reviewer for kanman’s work
With Ask a reviewer who knows the code in Team > Code review, 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.
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. Every MR 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.
Last updated: January 1, 0001
Open kanman