Guides
Step-by-step help for the tasks you do when you run kanman in a real team.
Each guide solves one task from start to finish and links to the reference for every setting it uses.
Write requirements kanman can finish
How to phrase requirements and stories so they pass the readiness checks, get a useful Demonstrate block and end in a verified pull request.
Meeting notes and transcripts
Share meeting notes, a transcript or a recording summary with kanman. It proposes the stories, decisions and context worth keeping, says who said what, and changes nothing until you pick.
Add an acceptance manifest to your repo
Teach kanman how to start your app in a fresh environment and run acceptance specs, so every story ends with real proof.
Give kanman your team's toolchain
Define once which image, variables, secrets and setup your repositories need. kanman's coding work, local checks, acceptance checks and bulk changes all run in it, on your runners and in kanman Cloud.
Let kanman set up your repositories for coding agents
kanman reads a repository without a verify manifest or agent instructions, drafts working settings, proves them in your team environment and brings them in the way your team's autonomy allows.
Set how much kanman does on its own
Pick a trust level for a team, see who decides at each step from intake to live, and change single steps without losing track.
Answer decisions from Slack
Connect Slack so kanman posts decisions with their options to a team channel, you answer with one click, and requirements from threads become stories.
Work with kanman in Slack and Microsoft Teams
Connect Slack or Microsoft Teams, choose the places each team talks to kanman, and ask questions, request changes and answer decisions from chat.
Channel modes and guardrails
Decide per channel how much kanman listens, who may turn chat into stories, and when kanman stays quiet.
Team context and connectors
Give kanman your team's documents, repositories, Confluence, Notion and SharePoint pages so it answers questions with sources, and only from what the asking person may see.
Ask about the code
Ask kanman where something is handled, why it is built this way, what changed last week or who knows a part of the code. Every answer links the files and lines, pull requests, decisions and stories it stands on.
Put kanman on call: services and signal sources
Add the services your team runs, connect uptime checks, alerting tools and log sources, and choose what kanman may do when something degrades.
Know the state of your systems: Backstage and Checkmk
Connect your Backstage catalog and Checkmk so kanman knows who owns which system, opens incidents from problems and answers "how is payment-api doing?".
Monitoring signals: Prometheus, Grafana and InfluxDB
Let kanman read your metrics and alerts, learn each service's normal, analyse what deviates and act only outside production: findings, fix stories, merge requests and a message to the person on call.
Run the self-hosted runner
Run kanman's code work on your own infrastructure with a Docker image that connects outbound only, without opening ports or sharing database credentials.
Model access on self-hosted runners
Let the coding agent on your self-hosted runner use your own cloud account for models, such as Amazon Bedrock, Google Vertex AI or Microsoft Foundry, so model keys never pass through kanman.
Run everything on your runners
Keep all model traffic and every repository action inside your network: kanman's cloud keeps the board, decisions and the audit log, and your self-hosted runners do the rest.
GitLab behind a VPN or firewall
Use kanman with a self-managed GitLab that is only reachable inside your company network: a runner inside the network does all repository work and talks to kanman over outbound HTTPS only.
Use kanman from Claude Code or Codex
Connect Claude Code or Codex to kanman with one command and a browser sign-in. Work on stories, answer decisions and ask kanman from your terminal, for every team of your workspace.
Roll out to a second team
Take what worked for the first team to the next one: reuse connections and settings, carry over the acceptance manifest pattern, and keep each team's rules its own.