How it works
How it works
One story, start to finish. A request from finance becomes three stories, a sandbox run, an evidence pack and a pull request your team reviews.
-
1. Tell kanman
Describe the work in the app, in Slack or in Microsoft Teams. kanman asks what is unclear and drafts stories with acceptance criteria and a way to demonstrate each one.
-
2. Rules
Your policy decides what kanman may touch, spend and merge. Big calls come to you with a recommendation.
-
3. Work
Claude Code or Codex does the coding in a sandbox. kanman picks the model by complexity, so trivial fixes stay cheap.
-
4. Proof
Before anything reaches review, an acceptance spec runs against a fresh environment. No spec, no Ready. No green run, no review.
-
5. Hear back
kanman tells you the pull request is ready, with the evidence attached. Your people review and merge, or your policy does.
Tell kanman
A requirement becomes stories you can check
Someone tells kanman what they need, in the app, in Slack or in Microsoft Teams. kanman asks what is unclear, then drafts small stories with acceptance criteria.
Every criterion comes with a way to demonstrate it. That demonstration becomes the acceptance spec, written before any code exists.
- Stories land in your tracker, under your column names, or on the team's kanman board
- A person approves the stories before they are written to the tracker
- The spec must fail first. A spec that passes on today's code proves nothing.


Rules
Your policy decides what happens next
Before kanman starts, it checks the story against your policy. Which repos and paths it may touch, how much a run may cost, whether it may run now.
When a call is too big for the policy, it becomes a decision. You get the question, kanman's recommendation and the options, in the app, in Slack or in Microsoft Teams.
- Five presets from Trial to Hardening set the pace and initiative
- The sandbox and the outcome gate are the same in every preset
- Every check and every decision lands in the audit log


Work
The coding agent works in a sandbox
kanman hands the story to Claude Code or Codex, running headless in a fresh sandbox. In Frankfurt, or on your self-hosted runner.
It picks the model by complexity, so a typo fix does not cost what a migration costs. Budgets stop a run before it gets expensive.
- Your verify command (lint, types, tests) runs before anything else
- The agent has no write access to the acceptance spec
- A failed gate gets one rework attempt, then it comes back to you


Proof
The spec runs on a clean checkout
The outcome gate starts your app from the pull request's commit, in a fresh environment, and runs the story's spec. Nothing cached, nothing from the agent's machine.
The result is the evidence pack. Each criterion with passed or failed, the spec that checked it, the trace, the duration and the cost.
- No spec, no Ready. No green run, no review.
- In repos without specs, the Trial preset says so plainly in the pack

Hear back
A pull request your people can trust
kanman opens the pull request with the evidence attached, updates the story in your tracker, writes the audit entry and tells you in the conversation that the story is ready for review.
Your people review and merge, as they do today. If your policy allows automatic merges for small changes, those merge when every gate is green.
- Review comments that repeat become team conventions
- You can read, edit and retire every convention

Try it on your own backlog
Start with the Team plan, free for 14 days and without a card.