Mit dem Board über die API zu arbeiten braucht den Developer-Tarif, denselben, den MCP-Server und CLI brauchen. Neue Workspaces bekommen 14 Tage Testphase in diesem Tarif, ohne Kreditkarte.

Verschiebt ein Commit mit Karten-Schlüssel die Karte automatisch?

Nein. Er verknüpft den Commit mit der Karte. Damit sie sich bewegt, brauchst du einmalig eine Regel in den Automationen des Boards, etwa: Commit verknüpft, dann nach In Arbeit verschieben, mit der Option, nur vorwärts zu bewegen.

Geht das auch mit Cursor oder Codex statt Claude Code?

Ja, der MCP-Server funktioniert mit allen drei. Die Einrichtung für Cursor und Codex steht auf der Agenten-Seite.

Ist ein Board für ein kleines Projekt nicht übertrieben?

Für ein Wochenendprojekt, das sonst niemand sieht, erledigt eine TODO.md-Datei, die der Agent pro Sitzung aktualisiert, denselben Job mit deutlich weniger Einrichtung.

Was gehört wirklich in die CLAUDE.md?

Mindestens: das Board und die Beschreibung der Karte zu Beginn der Sitzung lesen, nur an der Karte arbeiten, an der gerade gearbeitet wird, den Status-Block in der Beschreibung am Ende neu schreiben, für Menschen optional kommentieren, die Karte nach Review verschieben, und den Karten-Schlüssel in die Commit-Betreffzeile schreiben.

Claude Code Projektmanagement zwischen Sitzungen

Eine neue App-Idee geht in Claude Code, Cursor oder Codex schnell voran: Der Agent schreibt Code in Minuten. Nach ein paar Sitzungen wird aus dem schnellen Teil ein Problem. Niemand, weder du noch der Agent, weiß noch, was fertig ist, was halb fertig ist und was unterwegs entschieden wurde. Eine neue Sitzung sieht den Code, nicht die Entscheidungen dahinter, denn das Gespräch, in dem sie fielen, gehörte einer früheren Sitzung. Der Plan steckt in einer Markdown-Datei, die seit der dritten Sitzung nicht mehr stimmt, oder in einem Chat von gestern, verschwunden mit der Sitzung, in der er stattfand.

Die Lösung ist ein Board außerhalb der Sitzung, das der Agent zu Beginn liest und am Ende beschreibt, mit dem Karten-Schlüssel aus diesem Board in dem Commit, der aus der Sitzung herauskommt. Du, und jeder, dem du das Projekt zeigst, siehst den Stand, ohne Commits zu lesen.

Der Plan lebt außerhalb des Chats

Steht der Plan auf einem Board, wird die Sitzung selbst ersetzbar. Jede Sitzung fängt damit an, eine Karte zu lesen: wofür sie ist, und was der Status-Block am Ende ihrer Beschreibung über das schon Geschehene sagt. Sie endet damit, genau diesen Block neu zu schreiben, statt darauf zu hoffen, dass die nächste Sitzung sich erinnert. Der Karten-Schlüssel wandert in den Commit, sodass Code und Plan aufeinander zeigen, ohne dass du das von Hand nachträgst, und ein Blick auf das Board sagt schneller, woran es liegt, als ein ganzes Git-Log das könnte. Das ist gemeint, wenn von einem Gedächtnis zwischen Sitzungen für Claude Code die Rede ist, gehalten als Board, das es von außerhalb des Tools liest und beschreibt.

Das ist etwas anderes als ein Agent, der das Board eines Teams bedient, wie es Kanban-Board für KI-Agenten beschreibt. Hier gibt es meist ein Board und eine oder zwei Personen, und der Stand des Projekts muss irgendwo stehen, wo die nächste Sitzung und die nächste Person ihn wirklich lesen können.

Ein Claude-Code-Projekt in fünf Schritten organisieren

Workspace anlegen. Neue Workspaces bekommen 14 Tage Testphase im gewählten Tarif, ohne Kreditkarte, und laufen auf Servern in Deutschland.
API-Token anlegen, mit den Scopes, die der Agent braucht: boards:read und cards:read, um Board und Karten zu lesen, cards:write, um sie zu aktualisieren und zu verschieben, comments:write, um eine Notiz zu hinterlassen, und git:write für den Commit-Hook aus Schritt 4. Das braucht den Developer-Tarif, denselben, den MCP-Server und CLI brauchen.
MCP-Server in Claude Code einrichten:
```
claude mcp add zuuna \
  -e ZUUNA_API_TOKEN=zk_live_dein_token \
  -- npx -y mcp-server-zuuna
```
Cursor oder Codex statt Claude Code? Einrichtung für beide steht auf Zuuna für KI-Agenten.
Commit-Hook installieren, damit ein Karten-Schlüssel in der Commit-Betreffzeile die Arbeit automatisch verknüpft:
```
curl -o zuuna https://app.zuuna.de/zuuna.sh
chmod +x zuuna
./zuuna init https://app.zuuna.de zk_live_dein_token
```
Mehr zum Hook in der CLI-Referenz.
Ein paar Zeilen in die CLAUDE.md des Projekts eintragen, damit der Agent jede Sitzung dieselbe Routine befolgt, ohne dass du sie wiederholst.

Was in die CLAUDE.md gehört

## Zuuna-Board
- Lies das Board zu Beginn der Sitzung mit `zuuna_board`, dann die Karte, an der gearbeitet wird, mit `zuuna_card`: die oberste in „Als Nächstes“, oder die, die schon in „In Arbeit“ liegt. Ihre Beschreibung endet mit einem Status-Block: Fertig / Offen / Entschieden.
- Arbeite nur an dieser Karte. Liegt keine in „Als Nächstes“ oder „In Arbeit“, frag nach, bevor du etwas Neues anfängst.
- Trage den Karten-Schlüssel in die Commit-Betreffzeile ein, z. B. `APP-12: Passwort-Reset hinzufügen`.
- Schreibe am Ende der Sitzung den Status-Block mit `zuuna_update_card` neu: was fertig ist, was offen bleibt, was entschieden wurde und warum.
- Ergänze optional einen Kommentar mit `zuuna_comment` für Menschen, die die Karte später lesen; die nächste Sitzung liest keine Kommentare.
- Verschiebe die Karte mit `zuuna_move_card` nach „Review“, wenn sie bereit zum Ansehen ist.

Der Status-Block zählt am meisten: Eine Beschreibung, die sagt, was noch offen ist, macht die nächste Sitzung brauchbar statt zur Rätselei, denn der Agent liest die Beschreibung der Karte über MCP, aber nicht ihre Kommentare. Die Karte nach Review zu verschieben ist das, was eine Person, auch du selbst später, sich vor dem Fertig-Stempel ansieht; von dort weiter nach Erledigt zu verschieben ist deine Sache, der Agent hält bei Review an.

Ein Commit verknüpft die Karte, eine Regel verschiebt sie

Der Hook meldet jeden Commit, aber ein Karten-Schlüssel in der Betreffzeile oder im Branch-Namen verknüpft den Commit nur mit der Karte, er verschiebt sie nicht. Damit sich die Karte bewegt, etwa von Als Nächstes nach In Arbeit, brauchst du einmalig eine Regel in den Automationen des Boards: Commit verknüpft, dann nach In Arbeit verschieben, mit der Option, die sie nur vorwärts bewegen lässt. Keine Regel ist vorinstalliert. Beim ersten Mal sind es ein paar Klicks, danach aktualisiert sich das Board bei jedem Commit mit Karten-Schlüssel von selbst. Liegt das Projekt auf GitHub, GitLab, Gitea oder Forgejo, kannst du das Repository stattdessen direkt verbinden, dann lösen auch ein geöffneter oder gemergter Pull Request oder ein grüner oder roter Build Regeln aus, nicht nur der Commit-Hook.

Wann eine TODO.md-Datei reicht

Für ein Wochenendprojekt, das sonst niemand sieht, lohnt sich das alles nicht. Eine TODO.md-Datei neben dem Code, die der Agent am Ende einer Sitzung aktualisiert, erledigt denselben Job zu einem viel kleineren Preis: kein Token, keine Scopes, kein Board zum Nachsehen. Der Sinn eines Boards ist, dass sich mehr als ein Gedächtnis über den Stand eines Projekts einig sein muss, deins über mehrere Sitzungen hinweg, oder deins und das von jemand anderem. Stimmt das noch nicht, ist die einfache Datei die richtige Menge Prozess. Der Moment, ab dem sie nicht mehr reicht, ist meist deutlich: eine zweite Person liest den Code mit, oder du entscheidest etwas neu, das vor zwei Sitzungen schon geklärt war.