kanman aus Claude Code oder Codex nutzen

kanmans Runs nutzen den kanman MCP-Server, um die Story zu lesen, Fortschritt zu melden und Fragen zu stellen. Denselben Server können Sie zu Claude Code oder Codex auf Ihrem eigenen Rechner hinzufügen. Dann können Sie oder Ihr lokaler Agent eine kanman-Story im Terminal aufgreifen, und die Arbeit durchläuft trotzdem dieselben Gates und endet mit demselben Nachweispaket.

Das hilft, wenn eine Story einen Menschen an der Tastatur braucht, wenn Sie mit Ihrem Agenten an einer kniffligen Änderung zusammenarbeiten wollen oder um kanmans Ablauf auszuprobieren, bevor Sie Stories abgeben.

Was Sie bekommen

Alle Parameter und Ergebnisse stehen in der Referenz der MCP-Tools.

Schritt 1: Ein Token anlegen

1. Öffnen Sie in kanman Einstellungen, API und klicken Sie auf Token erstellen, zum Beispiel mit dem Namen „Laptop Anna“.
2. Wählen Sie eine kurze Laufzeit, zum Beispiel 30 Tage.
3. Kopieren Sie das Token und legen Sie es in Ihrem Shell-Profil oder Passwortmanager ab:

export KANMAN_API_KEY=km_your_token

Der Server akzeptiert jedes aktive Token des Workspaces, zu dem die Story gehört.

Schritt 2: Den Server hinzufügen

Die Adresse des Servers nennt die Story, an der Sie arbeiten wollen. Nutzen Sie den Story-Schlüssel, den kanman an der Story zeigt, zum Beispiel SBX-12:

Claude Code

claude mcp add --transport http kanman \
  https://api.kanman.ai/functions/v1/executor-mcp/stories/SBX-12 \
  --header "Authorization: Bearer $KANMAN_API_KEY"

Prüfen Sie mit claude mcp list, dass kanman verbunden ist. Für die nächste Story ändern Sie den Schlüssel in der Adresse (claude mcp remove kanman, dann erneut hinzufügen).

Codex

Ergänzen Sie ~/.codex/config.toml:

[mcp_servers.kanman]
url = "https://api.kanman.ai/functions/v1/executor-mcp/stories/SBX-12"
bearer_token_env_var = "KANMAN_API_KEY"

Starten Sie Codex im Repository. Die kanman-Tools erscheinen in seiner Tool-Liste. Wenn Ihr Client zusätzliche Header senden kann, ergänzen Sie x-kanman-executor: codex, damit die Run-Seite Codex als Executor zeigt.

Schritt 3: Die Story aufgreifen

Bitten Sie Ihren Agenten im Repository, die Story zu übernehmen:

Use kanman to work on SBX-12. Read the story, start work, and follow the policy.

Der Agent ruft get_story und start_work auf. start_work eröffnet einen Run für die Story (zum Beispiel run-7f3k) und verschiebt sie nach In Progress. Arbeiten Sie auf Ihrem eigenen Branch.

Während Sie arbeiten:

• Fortschrittszeilen aus report_progress erscheinen für das Team auf der Run-Seite
• check_policy sagt Ihnen vorab, ob ein Pfad gesperrt ist (zum Beispiel infra/**), statt erst im Review zu scheitern
• Fragen, die Sie mit request_human_input stellen, landen im Entscheidungseingang; der Run wartet auf die Antwort

Schritt 4: Zur Prüfung einreichen

Wenn die Änderung committet und gepusht ist und der Pull Request offen ist, rufen Sie submit_for_review mit einer Zusammenfassung und der URL des Pull Requests auf (oder lassen Sie Ihren Agenten das tun). kanman führt dann dieselben Gates aus wie bei eigenen Runs: die Akzeptanz-Spec in einer frischen Umgebung, den Diff-Wächter, gesperrte Pfade und Diff-Grenzen, CI und das Review. Die Story geht erst nach Review, wenn alle bestehen, und der Pull Request bekommt das Nachweispaket.

complete_work lehnt ab, bis die Prüfung bestanden ist. Genau darum geht es: Eine Story ist fertig, wenn sie belegt ist, egal wer den Code geschrieben hat.

Gut zu wissen

• Ihre Commits behalten Ihre eigene Autorschaft. Das Audit-Log hält die Schritte des Runs mit Ihnen als Akteur fest.
• Die Modellnutzung Ihres lokalen Agenten läuft über Ihr eigenes Abonnement und wird nicht auf das Budget des Teams angerechnet.
• Widerrufen Sie das Token unter Einstellungen, API, wenn Sie es nicht mehr brauchen.