Was kanman tut | kanman Dokumentation

kanman arbeitet als KI-Teammitglied in Ihrem Engineering-Team, nach Ihren Regeln. Es nimmt eine Anforderung entgegen, schreibt die Stories, liefert den Code über Claude Code oder Codex, belegt, dass die Änderung die Akzeptanzkriterien erfüllt, und führt ein Audit-Protokoll. Alles passiert in dem Tracker, den Sie bereits nutzen, auf EU-Infrastruktur oder auf Ihrer eigenen.

Coding-Agenten schreiben guten Code. Was den meisten Teams fehlt, ist alles um den Agenten herum: Wer macht aus einer vagen Anfrage kleine, testbare Arbeit, was darf der Agent anfassen und ausgeben, woran erkennt man, dass das Ergebnis tut, was verlangt war, und wer hat was freigegeben? kanman ist diese Betriebsschicht.

Die fünf Stufen

Jede Arbeit durchläuft dieselben fünf Stufen. So läuft eine Story zeigt sie mit einem Diagramm.

Stufe	Was passiert	Wo Sie beteiligt sind
1. Aufnahme	Aus einer Anforderung (geschrieben im Reiter Anforderungen des Teams oder in einem Slack-Thread) werden kleine Stories mit Akzeptanzkriterien im Given/When/Then-Format, einem Testplan und einem Demonstrate-Block.	Sie bearbeiten, verwerfen oder geben jede Story frei. Freigegebene Stories landen in Ihrem Tracker.
2. Dispatch	Erreicht eine Story die Spalte Ready, prüft kanman die Richtlinie des Teams: Pause, Arbeitszeiten, Budget und wie viele Runs gleichzeitig laufen dürfen. Während des Runs prüft es erlaubte Repositories, gesperrte Pfade und die Größe der Änderung.	Blockiert die Richtlinie die Arbeit, wartet die Story, oder kanman fragt Sie im Entscheidungseingang.
3. Ausführung	Claude Code oder Codex schreibt den Code in einer isolierten Sandbox, auf einem eigenen Branch, mit Verbindung zurück zu kanman.	Braucht der Plan eine Freigabe oder hat der Agent eine Frage, landet sie im Entscheidungseingang.
4. Prüfung	kanman führt das Outcome-Gate aus: die Akzeptanz-Spec der Story in einer frischen Umgebung und auf einem frischen Checkout, Ihre CI und einen unabhängigen Reviewer, der jedes Kriterium prüft. Eine automatische Nacharbeit ist erlaubt.	Scheitert die Prüfung weiterhin, hält kanman an und fragt.
5. Übergabe	kanman veröffentlicht das Nachweispaket am Pull Request und im Tracker-Issue, markiert den Pull Request als geprüft und schreibt einen Audit-Eintrag.	Ein Mensch prüft und mergt, sofern Ihre Richtlinie kein Auto-Merge für kleine Änderungen erlaubt.

Was kanman übernimmt und was es nutzt

kanman übernimmt die Teile, die ein KI-Teammitglied im Team sicher machen: Aufnahme, Richtlinien, Dispatch, Prüfung, Nachweise, Audit und Berichte.

Es nutzt, was Sie bereits haben:

Den Coding-Agenten. Standardmäßig Claude Code, alternativ Codex. Sie können Ihren eigenen Vertrag mit einem Modellanbieter einbringen.
Den Tracker. GitHub Issues, GitLab-Issues oder Jira. Der Tracker bleibt die maßgebliche Quelle, kanman spiegelt ihn.
Code-Hosting und CI. GitHub oder GitLab, auch selbst betriebenes GitLab, und Ihre bestehende CI.

Sie ziehen weder Backlog noch Repositories noch Ihren Review-Prozess zu kanman um.

Ein Teammitglied, keine Bot-Armee

In Ihrem Workspace gibt es genau ein kanman. Es spricht von sich als “ich”, erscheint neben Ihren Kolleginnen und Kollegen in Zuweisungslisten und im Tracker, und jede Aktion wird unter seinem Namen protokolliert. Intern plant, implementiert und prüft es, aber Sie verwalten nie eine Liste von Agenten.

Nach Ihren Regeln

Jedes Team hat eine Richtlinie. Ein Preset liefert sinnvolle Vorgaben, und jeder Regler lässt sich anpassen:

auf welchen Repositories und Branches kanman arbeiten darf und welche Pfade es nie anfassen darf
wie groß eine Änderung sein darf, in Dateien und Zeilen
was ein einzelner Run, ein Tag oder ein Monat kosten darf
ob ein Plan freigegeben werden muss, bevor Code entsteht, und wer mergt
welche Entscheidungen kanman selbst trifft, welche es meldet und welche es immer eskaliert

Manche Schutzmechanismen sind nicht abschaltbar: Die Akzeptanz-Specs sind für den Code schreibenden Agenten tabu, jede Änderung wird auf einem frischen Checkout geprüft, und alles, was Produktionsdaten oder Sicherheitseinstellungen berührt, geht immer an einen Menschen. Siehe Richtlinien, Presets und Befugnisstufen.

Belege statt Versprechen

kanman verlässt sich nie auf die Aussage des Coding-Agenten, eine Story sei fertig. Bevor die Arbeit beginnt, schreibt kanman aus dem Demonstrate-Block der Story eine ausführbare Akzeptanz-Spec und stellt sicher, dass sie fehlschlägt. Der Pull Request wird erst als geprüft markiert, wenn dieselbe Spec auf einem frischen Checkout besteht, die CI grün ist und der Reviewer jedes Kriterium geprüft hat. Das Ergebnis ist ein Nachweispaket im Pull Request und im Tracker-Issue: Kriterien, Gate-Ergebnisse, Testzahlen, Artefakte wie Playwright-Traces, Kosten und Dauer. Siehe Das Outcome-Gate und Nachweise.

Für wen kanman gedacht ist

kanman ist für Engineering-Teams mit etwa 5 bis 50 Personen gebaut, die bereits GitHub oder Jira nutzen, Coding-Agenten einzeln ausprobiert haben und nun ein Setup auf Teamebene mit Leitplanken wollen. Eingerichtet wird es meist von einer Engineering-Leitung, einem CTO oder einem Tech Lead. Täglich damit arbeiten die Entwicklerinnen und Entwickler, die Anforderungen schreiben, Entscheidungen beantworten und Pull Requests prüfen.

kanman ist kein allgemeines Projektmanagement-Tool und kein Chat-Assistent für alles. Es erledigt Engineering-Arbeit, innerhalb Ihres Prozesses.

Wo kanman läuft

kanman Cloud: Runs laufen auf isolierten Maschinen in Frankfurt am Main.
Self-hosted Runner: dieselbe Ausführungsumgebung als Container in Ihrer eigenen Infrastruktur. Er verbindet sich ausgehend mit kanman, Sie öffnen also keine eingehenden Ports.

Details unter Hosting und Datenstandort.

Nächste Schritte

Eine vollständige Story im Quickstart ansehen.
Den Weg einer Story verstehen: So läuft eine Story.
kanman für Ihren eigenen Code einrichten: Ein Team einrichten.