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

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

• Claude Design sitzt in einem Design-System-Projekt im Browser. Er entwirft Layouts, definiert Tokens, kuratiert Komponenten-Karten — das visuelle Gewissen des Projekts.
• Claude Code läuft lokal in meinem Code-Repository. Er macht echte Code-Änderungen, committet, läuft Lints, kennt die Nuxt/Vue-Codebase.

Klingt nach einem Traum-Team. Ist es auch — aber mit einem Haken: die beiden können nicht miteinander reden. Claude Design sieht meine lokale Codebase nicht. Claude Code sieht das Design-System-Projekt nicht. Beide arbeiten in eigenen Sandboxes.

Ich bin der Bote dazwischen.

Erster Versuch: Ich ließ Claude Design ein Handoff-Paket schreiben. 574 Zeilen README, alle Token, alle Screens, alle Interaktionen, alle Animationen. Dazu fünf JSX-Prototypen, neun Screenshots, eine colors_and_type.css.

Ich kopierte das Paket in den Frontend-Ordner und sagte Claude Code: „Setz das um.“

Es dauerte zwei Tage.

Nicht weil Claude Code langsam wäre — das Gegenteil. Sondern weil:

• Es keine Reihenfolge gab. Mit was anfangen? Tokens? Komponenten? Layout?
• Es keine „fertig“-Definition pro Aufgabe gab. Wann ist „die Sidebar umgestellt“ abgehakt?
• Es keine Akzeptanzkriterien gab. Was muss visuell vs. funktional stimmen?
• Ich nicht reviewen konnte. Ein riesiger PR zum Schluss vs. viele kleine, prüfbare Schritte.
• Findings auf dem Boden fielen. Claude Code sah während der Arbeit interessante Patterns — die wanderten nirgendwo hin.

Klassischer Fall von „too much context, no structure.“

Statt einem großen Paket, runterbrechen der kompletten Redesigns auf eine Datei pro Aufgabe. Jede Datei beschreibt genau eine Sache, die Claude Code tun soll — klein genug, dass sie in unter 30 Minuten erledigt ist.

Das Entscheidende ist nicht das Format, sondern was drin steht: welche Datei genau angefasst wird, wie „fertig“ aussieht (nicht als Gefühl, sondern als prüfbare Checkliste), und was danach zu testen ist. Dazu ein kurzes Vorher/Nachher-Snippet als konkreten Ankerpunkt — damit Claude Code nicht interpretieren muss, sondern ausführt.

Zwei Dinge haben sich schnell als unverzichtbar erwiesen: explizit aufschreiben, was nicht geändert werden soll (angrenzende Bereiche, die beim Anfassen verlockend aussehen), und was passiert, wenn etwas schiefgeht (Rollback in einem Satz).

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

Aber: Lebende Codebase. Claude Code hatte parallel an Komponenten gearbeitet, die mein Design-System gar nicht so spezifiziert hatte. Beispiel: Eine StatusBar mit Zoom-Prozent und Traffic-Light-Indikator. Klar besser als mein Original. Sollte das Design-System absorbieren.

Ich brauchte einen Rückkanal:

• Forward-Tickets (T-NN) fließen vom Design-System zum Code.
• Reverse-Tickets (R-NN) fließen vom Code zurück ins Design-System.

Bei eingehenden Findings vom Live-Code klassifiziere ich:

• 🟢 Promote — wird kanonisch ins DS aufgenommen, Card-Preview gebaut, künftige Forward-Tickets respektieren es.
• 🟡 Local divergence (OK) — Code darf da bewusst abweichen. Begründung dokumentieren.
• 🔴 Regression — versehentliche Abweichung, neues Forward-Ticket zum Zurückbauen.

Das macht Claude Design nicht zum diktatorischen Königsmacher, sondern zum Kurator. Das Design-System ist kein Diktat mehr, sondern ein Gedächtnis.

Letztes Problem: Jedes Mal musste ich Claude Codes Antwort manuell paraphrasieren und Claude Design zuwerfen. „CC sagt: T-04 done, Commit b50a667, findings: F4, F5.“ Fehlerquelle. Reibungspunkt.

Lösung: Eine einzelne Kommunikationsdatei, die zwischen beiden Kontexten hin- und herreist.

tickets/STATUS.md
├── 📨 INBOX     — CC schreibt rein, DS liest   (Append am Anfang)
├── 📤 OUTBOX    — DS schreibt rein, CC liest   (Append am Anfang)
├── 🎯 ACTIVE QUEUE — was als nächstes ansteht, in Reihenfolge
└── ✅ ARCHIVE   — chronologische Historie, append-only, Neuestes oben

Der Ablauf pro Runde:

1. Claude Design schreibt Tickets + Direktiven oben in OUTBOX. Gibt mir ein ZIP.
2. Ich entpacke das ZIP nach apps/frontend/tickets/ und sage Claude Code: „Lies STATUS.md, arbeite die Active Queue ab.“
3. Claude Code arbeitet die Queue ab, committet, schreibt seinen Status oben in INBOX.
4. Claude Code ist fertig — Commits, Lint, Findings dokumentiert.
5. Ich lade nur STATUS.md zurück zu Claude Design.
6. Claude Design liest INBOX, klassifiziert Findings, schreibt nächste OUTBOX-Runde + neue Tickets. Neues ZIP.

Single Touchpoint. Beide KIs sind selbstorchestrierend, weil das File die Wahrheit ist. Ich muss nicht mehr übersetzen.

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. Kein 574-Zeilen-Handoff.

Der Workflow ist nicht eingefroren. Diese 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 im Format URL → visuelles Kriterium, die direkt in diese Tabelle wandern. Neue Phasen kommen oben rein, ältere bleiben darunter stehen.

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.

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` (letztere darf nur der Nutzer befüllen)

## 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
     (Card-Preview anlegen)
   - 🟡 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 — alle relevanten Themes/States)
   - Code-Patch (vorher/nachher-Snippet)
   - Side-Effects (auch wenn klein)
   - Verifikation (kanonisches Kommando, z. B. `npx eslint <file>`)
   - Abbruch-Bedingungen bei Refactor-Tickets
   - „Nicht hier ändern"-Notes für anliegende Themen
4. Update STATUS.md:
   - Alte INBOX-Einträge als `[x] processed` markieren
   - Neue OUTBOX-Direktive oben anfügen (Klassifikation + Active Queue +
     Reihenfolge)
   - ACTIVE QUEUE aktualisieren
   - Roundtrip ans ARCHIVE unten anhängen
5. Update VERIFY.md: kopiere neue `🔍 Verify-in-live`-Bullets aus der
   INBOX in die jeweilige Phasen-Tabelle. Spalte `Mike's note` immer
   leer lassen — der Nutzer befüllt sie selbst.
6. Pack nur die geänderten Dateien als ZIP für den Nutzer.

## Prinzipien

- Tickets klein halten — < 30 Minuten Time-box.
- DRY vermeiden — Patterns dokumentieren statt geteilte Komponenten extrahieren.
- Live-Code respektieren — Code-Evolution durch Reverse-Tickets absorbieren.
- Append-am-Anfang in INBOX/OUTBOX — alte Einträge bleiben.
- Cross-Repo-Tickets mit `.patch`-Fallback, falls Claude Code das Ziel-Repo
  nicht erreichen kann.
- Niemals raten. Bei Unklarheit: Frage in OUTBOX stellen, Folge-Roundtrip abwarten.

Wenn der Nutzer eine STATUS.md hochlädt: lies INBOX, klassifiziere Findings,
liefere den nächsten Roundtrip als ZIP.

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

Parallel arbeitet eine zweite Instanz — „Designer-KI" — in einem separaten
Design-System-Projekt und schreibt dir Arbeitsaufträge als Tickets. Ihr könnt
nicht direkt miteinander reden. Eure Kommunikation läuft über die Datei
`tickets/STATUS.md`, die der Nutzer zwischen euch trägt.

## Bei jedem Roundtrip

1. Lies `tickets/README.md`, falls noch nicht im Kontext — Konventionen + Schnellstart.
2. Lies `tickets/STATUS.md`:
   - 📤 OUTBOX oben → aktuelle Direktiven der Designer-KI
   - 🎯 ACTIVE QUEUE → Tickets in Bearbeitungsreihenfolge
3. Arbeite die Queue Ticket für Ticket ab:
   - Lies `tickets/T-NN-*.md` vollständig
   - Code-Patch anwenden, Lint laufen lassen, separat committen
   - Falls ein Refactor-Ticket Abbruch-Bedingungen verletzt:
     `git reset --hard`, in INBOX melden, weiter zum nächsten Ticket
4. Nach jedem Ticket: einen Block oben in 📨 INBOX anfügen:
   ### [ ] YYYY-MM-DD — T-NN done
   - Status: 🟢 done
   - Commit: <hash> auf <branch>
   - Files: <list>
   - Lint: `npx eslint <file>` → 0 errors
   - **🔍 Verify in live:**
     - <URL/Pfad> → <visuelles Kriterium>
   - Findings: F-NN — kurze Beschreibung (klassifiziert Designer)
5. Markiere alte OUTBOX-Einträge als `[x] acknowledged` sobald gelesen.

## Konventionen

- Lint: `npx eslint <file>` für Single-File-Tickets. `npm run lint` nur für
  Phase-Closeouts.
- Auto-Discover-Regel: bei Cleanup-Tickets weitere Dead-Symbole im selben
  Commit mitnehmen — < 5 zusätzliche Symbole, explizit im Commit-Body listen.
  Bei mehr Scope: abbrechen + Reverse-Ticket.
- Separate Commits pro Ticket — Cherry-Pick / Revert bleibt möglich.
- Findings melden statt selbst entscheiden. Weitere Spec-Abweichungen in
  INBOX als F-NN notieren, NICHT eigenmächtig fixen.
- Append-am-Anfang in INBOX — alte Einträge bleiben unangetastet.

## Cross-Repo-Tickets

Falls das Ziel-File nicht erreichbar ist: Patch als `tickets/T-NN.patch`
ausgeben (unified diff, `git apply`-kompatibel). INBOX-Status: `done (manual
transfer)`. Niemals nach „analogen" Files im eigenen Repo suchen und dort patchen.

## Bei Unklarheit

Lieber abbrechen und in INBOX melden als raten.

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 Findings-Klassifikation und nächster Planung. Davor: zwei Tage. 

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

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.