Skip to content
ENDE
 Book a pilot

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. Intake

    Paste a requirement or tag kanman in Slack. You get 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. Handoff

    A pull request with the evidence attached. Your people review and merge, or your policy does.

Intake

A requirement becomes stories you can check

Someone pastes a requirement into kanman or tags it in Slack. 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
  • 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.

Example

INV-41 Export invoices as CSV

Acceptance criteria

  1. AC1The export button downloads a .csv file
  2. AC2One row per invoice in the selected range
  3. AC3Amounts use the shared money formatter
  4. AC4An empty range shows a message and no file

Demonstrate

Open the invoices page, pick 1 to 30 September, press Export CSV and check the downloaded file.

Illustration

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

INV-43 · asked 4 min ago

Decision

INV-43 changes the invoice schema. How should I add the VAT column?

My recommendation

A new column with a default. Old exports keep working and nothing needs a backfill.

  • Go with the recommendation
  • Backfill existing invoices
  • Leave it for now

Answer here or straight from Slack or Microsoft Teams.

Illustration

Preset

  • Trial For the first week. Works on repos without acceptance specs and says so in every evidence pack.
  • Focused Only works on stories your people filed. Nothing on its own initiative.
  • Balanced (selected) Picks up ready work at a steady pace and asks when a call is big.
  • Autonomous Four stories at a time, for teams with good test coverage. Same gates, same sandbox.
  • Hardening Adds maintenance on a slow drip. Security advisories, outdated dependencies, broken doc links.

Presets change pace, initiative and the default protected paths. The sandbox and the gates are the same in every preset.

Illustration

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
  1. sandbox fresh environment ready (fra)
  2. verify npm run lint && npm test passed
  3. model picked by complexity: small change
  4. agent Claude Code, 6 files changed
  5. budget within the run budget
  6. gate acceptance spec queued on a clean checkout

Illustration

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

INV-41 Export invoices as CSV

Outcome gate passed

Acceptance criteria

  • The export button downloads a .csv file passed
  • One row per invoice in the selected range passed
  • Amounts use the shared money formatter passed
  • An empty range shows a message and no file passed
Spec
.kanman/acceptance/INV-41/export.spec.ts
Written
at intake, red before Ready
Ran on
clean checkout of 4e1c9a7
Duration
41.6 s
Run cost
€0.84
Trace thumbnail: the invoices page with the Export CSV button pressed and the downloaded file listed.
Illustration A capture from the demo sandbox replaces it.

Handoff

A pull request your people can trust

kanman opens the pull request with the evidence attached, updates the story in your tracker and writes the audit entry.

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

Conventions

  • Format money with the shared formatter.

    Learned from 3 review comments

    Active

  • New endpoints need a rate limit test.

    Learned from 2 review comments

    Active

  • No new dependencies without a note in the pull request.

    Added by a teammate

    Pinned

  • Use snake_case for event names.

    Learned from 4 review comments

    Retired

Illustration

Try it on your own backlog

A pilot takes six weeks with one team and one repo.

Book a pilot