Skip to content

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. 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. 2. Rules

    Your policy decides what kanman may touch, spend and merge. Big calls come to you with a recommendation.

  3. 3. Work

    Claude Code or Codex does the coding in a sandbox. kanman picks the model by complexity, so trivial fixes stay cheap.

  4. 4. Proof

    Before anything reaches review, an acceptance spec runs against a fresh environment. No spec, no Ready. No green run, no review.

  5. 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.
A drafted story with Given, When, Then acceptance criteria, its Demonstrate steps and the spec that has to fail first
A requirement typed into the general conversation, continued in the team's chat: kanman drafts three stories, they are approved and written to the tracker

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
kanman asks in the conversation: approve the plan for a story? With kanman's recommendation and the options Approve plan, Request changes and Reject
Team settings, Autonomy: the trust dial from Trial to Hardening on Balanced, and the steps from intake to live with who decides at each

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
The run page of a story: stages from planning to review, progress lines, the pull request and the cost against the run budget
A run from planning to review, with the checks passing one by one

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
Evidence pack of a finished run: 3 of 3 acceptance criteria passed, the acceptance spec passed in a clean environment, 14 tests and CI passed, cost and duration

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
A team's conventions: the rule learned from three review findings, with its areas and the actions Pin, Edit and Retire

Try it on your own backlog

Start with the Team plan, free for 14 days and without a card.

Start the 14-day trial