Ich habe vor Kurzem einen Diary-Skill für Claude Code veröffentlicht. Hooks erfassen die rohen Ereignisse, das Modell verdichtet sie am Ende jeder Session zu Prosa in der ersten Person. Als Rückspiegel funktioniert das gut. Wenn in einigen Monaten ein künftiger Agent das Projekt übernimmt, reichen das Ereignisprotokoll und die verdichteten Einträge zusammen aus, um zu rekonstruieren, was passiert ist und warum.
Über die Zukunft kann das Tagebuch aber nichts sagen. Öffnen Sie das Projekt an einem Samstagnachmittag mit zwei Instanzen von Claude Code in getrennten Git-Worktrees, und sofort stellen sich Fragen, auf die das Tagebuch keine Antwort hat. Was ist noch zu tun? An welchem Teil sitzt die andere Instanz schon? Wenn ich morgen zurückkomme, wo mache ich weiter? Ein Tagebuch steht in der Vergangenheitsform; ein Projekt braucht auch Präsens und Futur.
Die übliche Lösung dafür ist ein Tracker. Und vor vier Wochen hat OpenAI Symphony veröffentlicht, eine Open-Source-Spezifikation, die genau diese Art von Zustand in ein Koordinationsprotokoll verwandelt. Symphony behandelt einen Issue Tracker als Zustandsautomaten: Jedes Ticket bekommt seinen eigenen Agenten und seinen eigenen Workspace, Tickets durchlaufen Todo / In Progress / Review / Merging, und Agenten, die mitten in einer Aufgabe abstürzen oder hängen bleiben, werden automatisch neu gestartet. OpenAI berichtete für interne Teams von einem Sprung auf das Sechsfache bei den gemergten Pull Requests in den ersten drei Wochen von Symphony. Ein externer Fork portiert die Spezifikation auf Claude Code, mit GitHub Issues als Tracker.
Die Form stimmt. Das Gewicht stimmt nicht, zumindest für mich.
Was „das Gewicht stimmt nicht“ bedeutet
Symphony setzt Linear oder GitHub Issues als Control Plane voraus. Es setzt einen Koordinatorprozess voraus, der diesen Tracker abfragt. Es setzt Agenten voraus, die zwischen menschlichen Checkpoints weitgehend autonom arbeiten, wobei der Mensch Merge-Kandidaten prüft, statt Sessions zu managen. Das ist eine echte Architektur für ein echtes Problem: ein Entwicklerteam, das seinen Issue Tracker auf Autopilot stellen will. Mein Problem hat diese Form nicht.
Mein Problem sieht so aus. An einem Samstag habe ich zwei Terminals offen. Eines führt Claude Code im Worktree feature/payment aus, das andere in feature/auth-refactor. Beide sollen sehen können, was in diesem Projekt sonst noch geplant ist, sich ein Stück Arbeit nehmen können, ohne dass ich es ihnen zuteile, und es als erledigt markieren, wenn sie fertig sind. Ich will auf irgendein Artefakt schauen und sehen, wer woran arbeitet, ohne mich bei Linear anzumelden, ohne einen Koordinatorprozess aufzusetzen und ohne mein Projekt für den Rest seines Lebens auf die Spezifikation von Symphony festzulegen.
Mit anderen Worten: Ich will ein Board, aber dieses Board soll eine Datei im Repository sein und kein Dienst irgendwo anders.
An dieser Stelle wird Thariq Shihipars inzwischen berühmter Satz „HTML ist das neue Markdown“ wichtig. Das Argument in aller Kürze: Als Konfigurationsformat ist Markdown in Ordnung (CLAUDE.md, SKILL.md und der Rest), als Ausgabeformat, mit dem sich Menschen befassen sollen, taugt es wenig. Ein tausendzeiliger Plan in Markdown wird zur Textwand. Ein HTML-Artefakt, visuell, scrollbar und manchmal interaktiv, liest man tatsächlich. Ein Board aus Karten ist genau die Form, bei der Markdown gegen HTML klar verliert. Eine Markdown-Checkliste ist eine Textwand; ein Kanban-Board mit Spalten, Chips und farbcodierter Priorität erfasst das Auge auf einen Blick.
Das Board sollte also HTML sein, nicht Markdown. Gut. Aber wo liegt das HTML?
Das Substrat
Ich arbeite seit einigen Monaten mit rewritable. Das ist eine kleine Spezifikation, die festlegt, wie ein „sich selbst umschreibender HTML-Container“ aussieht: eine .html-Datei, die ihre eigene Runtime und ihre eigenen Daten enthält und Änderungen über die File System Access API in die Datei auf der Festplatte zurückschreiben kann. Sie öffnen sie in Chrome, bearbeiten sie, drücken ⌘S, und die Datei auf der Festplatte wird direkt aktualisiert. Schließen Sie den Tab und öffnen Sie ihn wieder, ist der Zustand noch da, weil er die Datei ist. Es gibt kein Backend, keine Datenbank und keinen Server, nur eine HTML-Datei, die zugleich eine Anwendung ist.
Für ein Projekt-Kanban ist dies das richtige Substrat auf der richtigen Ebene. .kanban/board.html wird zum Board. Die Datei können Sie mit cat ausgeben, mit grep durchsuchen, mit git add vormerken, sich selbst mailen oder in jedem modernen Browser öffnen. Die Kanban-App ist Teil der Datei; in Chrome geöffnet, zeigt sie das visuelle Board mit Drag-and-drop. Sie müssen keinen eigenen Viewer installieren, sich bei keinem Tracker-Dienst anmelden und keinen Orchestrator-Prozess starten. Das Board ist das Artefakt, so wie die Einträge des Tagebuchs das Artefakt für den rückblickenden Zustand sind.
Hier zahlt sich die Architektur auch ein zweites Mal aus. Der Diary-Skill und der Kanban-Skill haben technisch nichts miteinander zu tun (andere Dateien, anderer Speicher, andere Aufrufmuster), aber sie liegen auf derselben gedanklichen Achse. Das Tagebuch hält die Vergangenheit fest, das Kanban beschreibt die Gegenwart und die unmittelbare Zukunft. Beide liegen als Dateien im Projekt, beide kann Claude lesen und schreiben, beide kann ein Mensch ohne jedes Werkzeug öffnen. Symphony löst ein ähnliches Problem auf einer viel höheren Abstraktionsebene. Das hier ist dasselbe Problem auf der niedrigsten Abstraktionsebene, die ich finden konnte.
Zwei Oberflächen, eine Datei
Der Kanban-Skill bringt für Claude eine kleine Bash-CLI mit (init, add, claim, move, note, list), die das Karten-Array atomar bearbeitet. Eine typische Session sieht so aus:
$ kanban add "Refactor auth to use middleware pattern" --priority=high --tags=auth,refactor
2026-05-20-refactor-auth-to-use-middleware-pattern
$ kanban claim 2026-05-20-refactor-auth-to-use-middleware-pattern
claimed 2026-05-20-refactor-auth-to-use-middleware-pattern by alpha
$ kanban list
TO DO (1)
2026-05-20-investigate-flaky-test Investigate flaky test
IN PROGRESS (1)
! 2026-05-20-refactor-auth-to-use-middleware-pattern Refactor auth to use middleware pattern [alpha] #auth #refactor
REVIEW (1)
· 2026-05-20-document-the-api-endpoints Document the API endpoints #docs
Die vier Spalten (To Do, In Progress, Review, Done) entsprechen fast genau dem Zustandsautomaten von Symphony, nur ohne den Auto-Merge-Schritt. Jede Karte ist ein JSON-Objekt in einem <script type="application/json" id="kanban-cards">-Block in der HTML-Datei. Die Bash-Skripte setzen auf einem Python-Helfer auf, rwa_splice.py, der die JSON-Region per os.replace direkt in der Datei bearbeitet und dabei nie HTML parst. Die Inline-Runtime im Browser liest beim Laden der Seite dasselbe JSON, rendert die Spalten, bindet Drag-and-drop und schreibt Änderungen in den JSON-Block zurück, bevor die rwa-Runtime die Datei bei ⌘S committet.
Am interessantesten ist, was die Identität des Zuständigen bewirkt. Der Skill liest $KANBAN_AGENT_NAME, falls gesetzt (alpha, beta, review, was pro Worktree eben passt), und greift sonst auf einen kurzen Hash von $CLAUDE_SESSION_ID zurück. Setzen Sie KANBAN_AGENT_NAME=alpha in der Shell des einen Terminals und KANBAN_AGENT_NAME=beta im anderen, dann zeigen die Karten, die jede Instanz beansprucht, ihren Besitzer als dunklen Chip. Ein Versuch, eine bereits beanspruchte Karte zu holen, endet mit Exit-Code 2, statt sie zu übernehmen. Die Agenten bemerken einander, statt zu kollidieren.
Das ist die ganze Koordination. Kein Nachrichtensystem, kein Supervisor, kein zentraler Agent. Zwei Sessions von Claude Code, zwei Shell-Umgebungen, eine Datei. Das Protokoll claim → exit 2 ist das ganze Delegationsprimitiv, und für eine einzelne Person mit parallelen Sessions reicht es, wie sich zeigt, genau aus.
Was die erste Version falsch gemacht hat
Die erste Fassung hatte einen unauffälligen, aber üblen Bug, und er hat mich etwas gelehrt, das ich mir aus der Arbeit an rewritable eigentlich hätte merken müssen.
Die rwa-Runtime hydratisiert das Dokument bei jedem Laden der Seite aus IndexedDB und ignoriert das INLINE_DOC-Literal in der Datei, sobald IDB befüllt ist. Normalerweise will man genau das: IDB ist der Arbeitsstand, und ein Reload sollte Änderungen, die noch nicht committet sind, nicht zurückrollen. Bei einem Kanban-Board hieß das aber, dass alles, was Claude über die CLI in die Datei schrieb, für einen offenen Browser-Tab unsichtbar blieb. Man drückte F5, und nichts änderte sich. Die Anweisung „IndexedDB löschen und neu laden“ funktionierte, aber als Standardverhalten war das falsch. Ich hatte ein Board ausgeliefert, das still über seinen eigenen Zustand log, und den Workaround in der Referenzdokumentation versteckt, als wäre er ein Feature.
Die Lösung war kleiner als der Bug. Die Kanban-Runtime (das Inline-JS in INLINE_DOC) pollt jetzt alle 2,5 Sekunden fetch(location.href), solange der Tab sichtbar ist. Sie parst das Karten-JSON aus dem Literal in der Antwort, führt einen Three-Way-Merge gegen den Festplattenstand der letzten Abfrage und die aktuell im DOM liegenden Karten durch und schreibt das Ergebnis zurück. Was die CLI hinzufügt, beansprucht, verschiebt, notiert oder löscht, zeigt sich automatisch in offenen Tabs, neue Karten leuchten dabei kurz auf. Lokale Drags, die noch nicht committet sind, überstehen den Merge: Hat der Mensch Karte X in eine neue Spalte gezogen und die CLI danach Karte Y geändert, bleiben beide Änderungen erhalten. Der einzige mehrdeutige Fall, ein Drag und ein CLI-Schreibvorgang auf derselben Karte, geht zugunsten des Drags aus, denn der Mensch hat gerade gehandelt, und ihm das rückgängig zu machen wäre verwirrender als die Alternative.
Die Schleife beruhigt sich von selbst. Wenn der Stand auf der Festplatte dem im DOM entspricht, ist die Abfrage in wenigen Millisekunden erledigt, und man sieht nichts. Hat sich etwas geändert, wird der Diff übertragen. Es gibt kein Banner, kein Modal und keine Anweisung, den Cache zu leeren. Das Board bleibt einfach synchron.
Die Lektion war klein, aber von der Sorte, die ich immer wieder neu lerne: Einen Workaround zu dokumentieren heißt nicht, den Bug zu beheben. Wenn etwas nicht funktioniert, will man als Erstes einen Satz in die README schreiben. Richtig ist es, zu fragen, ob das System die Schleife selbst schließen kann, und die Lösung auszuliefern, wenn es das kann.
Wofür das Board eigentlich da ist
Zwei Zwecke, noch einmal konkret, jetzt, wo die Mechanik geklärt ist.
Der erste ist ein Status, den Menschen lesen können. Wenn ich mich an einem Samstagvormittag hinsetze, kann ich .kanban/board.html in Chrome öffnen und sehen, was offen ist, ohne die Prosa von irgendwem zu lesen. Die Refactor-Karte hat einen roten linken Rand, weil sie hohe Priorität hat. Die Documentation-Karte liegt ohne Zuständigen in Review, was mir sagt, dass meine letzte Session sie fertiggestellt hat und ich sie mir noch nicht angesehen habe. Die Investigation-Karte liegt ohne Tags in To Do. Das ist der gesamte Zustand des Projekts, auf einen Blick erfasst, in der Zeit, die man für einen halben Kaffee braucht.
Der zweite ist die Koordination zwischen parallelen Sessions. Wenn ich eine Instanz von Claude Code starte und ihr sage „nimm dir etwas vom Board“, führt sie kanban list --status=todo aus, wählt die freie Karte mit der höchsten Priorität, beansprucht sie und legt los. Macht eine zweite Instanz eine Minute später dasselbe, endet das zweite claim bei der ersten Karte mit Exit-Code 2, und der Agent nimmt die nächste darunter. Niemand musste etwas zuteilen, kein Koordinator musste etwas routen. Das Board war der einzige Zustand, den irgendwer brauchte.
Das Board leistet noch etwas Drittes, das ich nicht geplant hatte und das sich in der Praxis als das Nützlichste erweist. Wenn der Diary-Skill seinen Eintrag zum Ende der Session schreibt, verweisen die Einträge per ID auf Karten: Schwenk bei 2026-05-20-refactor-auth, nachdem der Express-Middleware-Ansatz an der asynchronen Fehlerbehandlung gescheitert war. Die Karten-ID ist ein stabiler Bezeichner zum Kopieren und Einfügen, der über Sessions, Worktrees und Agenten hinweg Bestand hat. Tagebuch und Kanban teilen keinen Code, aber ein Vokabular, und das Projekt gewinnt eine Kontinuität, die ihm kein einzelnes Werkzeug gegeben hätte.
Die leichte Version gibt es, weil die richtige Größe eines Werkzeugs von der Größe des Vorhabens abhängt. Symphony hat die richtige Form für ein Entwicklerteam, das seinen Issue Tracker auf Autopilot stellen will. Für einen einzelnen Entwickler mit zwei Sessions von Claude Code und einem Substrat, das sich ohnehin selbst umschreibt, lautet die Antwort .kanban/board.html: eine Datei, in der Sie Karten ziehen können und die Sie ohne Erlaubnis öffnen und auf einen Blick lesen können.
Ausgeliefert
Der Kanban-Skill liegt auf GitHub unter ikangai/claude-skills. So installieren Sie ihn in Claude Code:
mkdir -p ~/.claude/skills && unzip -o kanban.zip -d ~/.claude/skills/
Starten Sie Claude Code neu, damit der Skill erkannt wird, und führen Sie dann in einem beliebigen Projektverzeichnis kanban init aus, um .kanban/board.html anzulegen. Die erste Karte, die Sie hinzufügen, ist der erste Eintrag auf einem Board, das mit etwas Glück irgendwann die Textur eines Projekts annimmt, so wie das Tagebuch die Textur einer Session annimmt.
Aus dem Englischen übersetzt: zum Originalbeitrag