Wie ich zwei KIs koordiniere, die nicht miteinander reden können

Anthropic hat im April 2026 Claude Design offiziell vorgestellt.

Claude Design ist eine KI, die im Browser lebt, visuell denkt und direkt an Design-Systemen arbeitet.
Dieser Post ist die Geschichte, wie ich zwei KI-Kontexte produktiv miteinander verbunden habe — und was dabei schiefging.

Setup · Was schiefging · Tickets · Reverse Tickets · STATUS.md · Updates · Selber ausprobieren

Das Setup

Für meine App DecisionMap arbeite ich mit zwei KIs gleichzeitig:

• Claude Design kümmert sich um das Design-System — Layouts, Farben, Komponenten. Er lebt im Browser und sieht meine lokale App nicht.
• Claude Code arbeitet direkt im Code-Repository auf meinem Rechner. Er kann committen, Fehler prüfen, Dateien ändern — aber das Design-System-Projekt sieht er nicht.

Zwei spezialisierte KIs, die nicht miteinander reden können. Ich bin der Bote dazwischen.

Wie es schiefging — der 2-Tage-Vorfall

Erster Versuch: Claude Design schrieb ein komplettes Handoff-Paket — 574 Zeilen, alle Tokens, alle Screens. Ich legte alles in den Frontend-Ordner und sagte Claude Code: „Setz das um.“

Es dauerte zwei Tage. Nicht weil die KI langsam war, sondern weil das Paket keine Struktur hatte: keine Reihenfolge, keine „fertig“-Definition pro Aufgabe, keine klaren Akzeptanzkriterien. Claude Code hatte am Ende einen riesigen, kaum prüfbaren Änderungsblock produziert — und interessante Beobachtungen aus der Arbeit waren unterwegs verloren gegangen.

Zu viel Kontext, zu wenig Struktur.

Iteration 1 — Tickets

Die Lösung: kleine, strukturierte Arbeitsaufträge (Tickets) statt eines großen Pakets. Jedes Ticket ist eine Markdown-Datei mit klarer Anatomie — maximal 30 Minuten Arbeit, eine konkrete Aufgabe:

• Scope — genau welche Datei, welcher Bereich
• Akzeptanzkriterien — vollständige Checkliste, was stimmen muss
• Vorher/Nachher-Snippet — der konkrete Code-Patch
• Verifikation — wie man prüft, ob es funktioniert
• „Nicht hier ändern“ — was Claude Code beim Touch sehen, aber liegen lassen soll

Drei Tickets als Pilot. Roundtrip: 30 Minuten statt 2 Tagen.

Iteration 2 — Rückkanal

Aber Code lebt. Claude Code hatte parallel eine Komponente gebaut, die mein Design-System gar nicht vorgesehen hatte — und die war besser als mein Original. Das Design-System musste lernen, statt zu diktieren.

Ich baute einen Rückkanal ein. Seitdem gibt es zwei Richtungen:

• Forward-Tickets (T-) — Claude Design schreibt Aufgaben für Claude Code
• Reverse-Tickets (R-) — Claude Code meldet Beobachtungen zurück an Claude Design

Jede Rückmeldung aus dem Live-Code klassifiziere ich:

• 🟢 Promote — das Pattern wird offiziell ins Design-System aufgenommen
• 🟡 Lokale Abweichung (OK) — Code darf hier bewusst anders sein, dokumentiert
• 🔴 Regression — versehentliche Abweichung, neues Ticket zum Korrigieren

Das Design-System ist kein Diktat mehr, sondern ein Gedächtnis.

Iteration 3 — STATUS.md

Letztes Problem: Ich musste Claude Codes Ergebnisse jedes Mal manuell zusammenfassen und zu Claude Design übersetzen. Fehlerquelle, Zeitverlust.

Die Lösung: eine einzige Kommunikationsdatei — tickets/STATUS.md — die ich zwischen den beiden Kontexten hin- und hertrage. Neue Einträge kommen immer oben rein, alte bleiben stehen.

Der Ablauf pro Runde:

1. Claude Design schreibt neue Aufgaben in OUTBOX, packt alles als ZIP.
2. Ich entpacke das ZIP und weise Claude Code an: „Lies STATUS.md, arbeite die Queue ab.“
3. Claude Code arbeitet, committet, schreibt Ergebnisse in INBOX.
4. Ich lade nur STATUS.md zurück zu Claude Design.
5. Claude Design liest INBOX, klassifiziert Findings, schreibt die nächste Runde. Neues ZIP.

Wie das in der Praxis klingt — eine typische OUTBOX-Nachricht:

Lies STATUS.md → OUTBOX 2026-06-10-F. Bold-Redesign-Adaption ist komplett. Hold-Modus — Queue ist leer, kein Auto-Refactoring. Spontane Findings aus laufender Arbeit jederzeit in INBOX melden, auch ohne Active Queue.

Drei Sätze. Keine Übersetzung nötig. Das ist der Unterschied zum 574-Zeilen-Handoff.

Was sich seitdem verfeinert hat

Der Workflow ist nicht eingefroren. Vier Dinge haben sich inzwischen etabliert:

VERIFY.md — eine dritte Datei. Neben Tickets und STATUS.md gibt es eine Checkliste: Was muss ich nach jedem Roundtrip im Live-System anschauen? Die Tabelle hat vier Spalten — URL, was ich prüfe, Status, und eine freie Kommentarspalte für meine Notizen beim Durchgehen. Claude Code liefert pro Ticket 1–3 konkrete Prüfpunkte (Format: URL → visuelles Kriterium), die direkt in diese Tabelle wandern. Neue Phasen kommen oben rein, ältere bleiben darunter stehen — so sehe ich sofort, wo ich gerade stehe.

Lint-Regeln klar definiert. npx eslint <datei> für einzelne Tickets, npm run lint nur zum Abschluss einer Phase. Ohne diese Regel versucht Claude Code, Fehler aus anderen Teilen des Projekts zu beheben — die aber gar nicht zur aktuellen Aufgabe gehören.

Auto-Discover bei Aufräum-Tickets. Wenn Claude Code beim Lint einer Datei weitere verwandte tote Symbole aus derselben Änderungswelle findet, darf er sie im selben Commit mitnehmen — solange es weniger als fünf sind und er sie im Commit-Text auflistet. Bei mehr: stoppen und als Rückmeldung notieren. Die Grenze zwischen „sinnvolles Mitnehmen“ und „unkontrollierbares Ausweiten“ muss explizit sein.

Design-System als Gedächtnis, nicht als Regelwerk. Im Laufe des Projekts haben sich drei visuelle Muster herauskristallisiert — Modalfenster, Seitenkarten, Login-Bereich — die ich nicht von Anfang an geplant hatte. Kein Versuch, alles nachträglich zu vereinheitlichen. Stattdessen: durch Rück-Tickets dokumentieren, klassifizieren, und das Design-System organisch wachsen lassen. Das ist der Unterschied zwischen einem Design-System, das man befolgt, und einem, das mit dem Projekt mitdenkt.

Was ich gelernt habe

Vollständig ist besser als kompakt. Wenn eine Komponente zehn Zustände hat, müssen alle zehn in den Akzeptanzkriterien stehen. Nicht neun. Sonst rät die KI für den fehlenden — und rät oft falsch.

Auch der Designer macht Fehler. Beim Vergleich Live-Code vs. Design-System hatte Claude Code einen vierten Button in der Toolbar implementiert, den ich nie spezifiziert hatte. Der war richtig. Mein Design war unvollständig. Lehre: beim Review gezielt nach neuen Elementen suchen, nicht nur nach abweichendem Styling.

Selber ausprobieren — die Boot-Prompts

Wer diesen Workflow für ein eigenes Projekt übernehmen will: Das Setup lässt sich mit zwei kurzen System-Prompts einleiten — einen für Claude Design, einen für Claude Code. Jeweils als erste Nachricht im jeweiligen Kontext einfügen.

Die einzigen Anpassungen: eigenen Code-Pfad einsetzen, eigenes Lint-Kommando (z. B. Prettier oder Ruff statt ESLint). Wer keine klaren Projektphasen hat, lässt ACTIVE QUEUE einfach als lineare Aufgabenliste laufen.

Prompt für Claude Design (im Web)

Du arbeitest ab sofort als „Designer-KI" in einem Design-System-Projekt
(Tokens, Komponenten-Previews, Spec-Dokumente).

Parallel arbeitet eine zweite Instanz — „Claude Code" — im lokalen App-
Repository und committet dort Code. Ihr könnt nicht direkt miteinander
reden. Eure Kommunikation läuft ausschließlich über eine einzelne Datei
tickets/STATUS.md, die der Nutzer (Mittelmann) zwischen beiden Kontexten
transportiert.

## Setup beim ersten Mal

Lege im Projekt folgende Dateien an, falls sie noch fehlen:
- tickets/README.md — Workflow-Erklärung + Mindeststandards
- tickets/STATUS.md — mit Sektionen INBOX, OUTBOX, ACTIVE QUEUE, ARCHIVE
- tickets/VERIFY.md — Tabelle mit Spalten #, Where, Look for, Mike's note

## Pro Roundtrip

1. Lies INBOX in STATUS.md — was Claude Code abgeschlossen / gefunden hat.
2. Klassifiziere jedes Finding:
   - Promote → Reverse-Ticket (R-NN), Pattern im DS dokumentieren
   - Local divergence OK → kurz im OUTBOX dokumentieren
   - Regression → Forward-Ticket (T-NN) zum Zurückbauen
3. Schreibe Forward-Tickets als tickets/T-NN-name.md mit fester Anatomie:
   - Status, Scope, File, Time-box, Phase
   - Akzeptanzkriterien (vollständig)
   - Code-Patch (vorher/nachher-Snippet)
   - Side-Effects, Verifikation, Abbruch-Bedingungen
4. Update STATUS.md: INBOX als processed, neue OUTBOX-Direktive, ARCHIVE.
5. Update VERIFY.md: neue Verify-in-live-Bullets (neueste Phase oben).
6. Pack nur geänderte Dateien als ZIP.

Prinzipien: Tickets max. 30 min. DRY vermeiden. Niemals raten.

Prompt für Claude Code (lokal)

Du arbeitest als „Claude Code" im lokalen App-Repository.

Parallel arbeitet eine zweite Instanz — „Designer-KI" — in einem
separaten Design-System-Projekt. Eure Kommunikation läuft über
tickets/STATUS.md.

## Bei jedem Roundtrip

1. Lies tickets/README.md, falls noch nicht im Kontext.
2. Lies tickets/STATUS.md: OUTBOX (Direktiven) + ACTIVE QUEUE (Reihenfolge).
3. Arbeite die Queue Ticket für Ticket ab:
   - Lies tickets/T-NN-*.md vollständig
   - Patch anwenden, Lint laufen, separat committen
   - Bei Abbruch-Bedingungen: git reset --hard, in INBOX melden
4. Nach jedem Ticket oben in INBOX anfügen:
   ### [ ] YYYY-MM-DD — T-NN done
   - Status, Commit-Hash, Files, Lint-Ergebnis
   - Verify in live: URL/Pfad → visuelles Kriterium
   - Findings: F-NN — kurze Beschreibung
5. Alte OUTBOX-Einträge als [x] acknowledged markieren.

Konventionen: npx eslint datei (Einzel-Tickets), npm run lint (Phase-Closeout).
Auto-Discover: max. ~5 Dead-Symbole im selben Commit. Separate Commits pro Ticket.
Bei Unklarheit: abbrechen und in INBOX melden.

Fazit

Claude Design ist stark bei visuellem Denken und Design-Systemen. Claude Code ist stark bei lokalem Code, Commits und Tests. Beide zusammen sind besser als jedes einzelne Tool. Aber sie brauchen Glue — ein Protokoll, das beiden erlaubt, ihre Stärken einzusetzen, ohne dass ich als Bote zur Engstelle werde.

Roundtrip heute: ~30 Minuten für zwei Tickets inklusive Prüfung und nächster Planung. Davor: zwei Tage. Faktor ≈ 100×.

Nicht weil die KIs schneller geworden sind. Sondern weil sie endlich wissen, was sie tun sollen.

Hinweis: Persönlicher Workflow mit DecisionMap, Stand Juni 2026. Claude Design ist aktuell in Research Preview für Pro-, Max-, Team- und Enterprise-Abonnenten verfügbar.