Claude-Code-Designsystem: 4 Bausteine für markentreue UI

Ein Claude-Code-Designsystem ist ein Kontext-Stack im Repository. Er zeigt dem Agenten, wie deine Marke aussieht, wie er sie umsetzt und wie er das Ergebnis prüft. Eine praktische Variante besteht aus drei Markdown-Dateien und einem examples/-Ordner. Sie ersetzt wiederholte Marken-Prompts durch versionierte Evidenz, Regeln und freigegebene Muster.

Bekannt wurde der Workflow durch Charlie Hills' vierteiliges Markensystem mit Prompts. Die Dateinamen sind dabei nicht magisch. Entscheidend ist, dass visuelle Evidenz, Umsetzungsregeln und Qualitätsprüfungen dauerhaft im Projekt liegen und nicht in einem alten Chat verschwinden.

Dieser Leitfaden macht daraus einen Workflow, den Produktteams prüfen, testen und pflegen können. Er beantwortet die Long-Tail-Frage, wie Claude Code einem Designsystem folgt. Die breitere Arbeit mit Repository-Kontext erklären wir im Artikel über Kontext für Coding-Agenten. Für produktionsreife Software bleibt unsere Checkliste für KI-generierte Anwendungen zuständig.

Welche vier Bausteine hat ein Claude-Code-Designsystem?

Genau genommen sind es vier Bausteine und nicht vier Dateien, denn der vierte ist ein Ordner. Nur CLAUDE.md hat für Claude Code eine besondere Bedeutung. Anthropic dokumentiert in der Claude-Code-Memory-Anleitung, dass projektbezogene CLAUDE.md-Dateien als dauerhafte Anweisungen geladen werden. Sie sollen konkret, kurz und gut strukturiert sein. REFERENCE.md, DESIGN.md und examples/ funktionieren, weil du Claude ausdrücklich darauf verweist.

Wie sollte das Projekt aufgebaut sein?

dein-projekt/
├── CLAUDE.md
├── REFERENCE.md
├── DESIGN.md
├── examples/
│   ├── README.md
│   ├── dashboard-freigegeben.png
│   ├── landingpage-freigegeben.png
│   └── pricing-card-freigegeben.html
├── src/
└── tests/

Ergänze in examples/README.md pro Artefakt eine Zeile mit Owner, Freigabedatum, Quelle, wiederverwendbaren Elementen und bekannten Ausnahmen. So wird ein altes Kampagnen-Asset nicht versehentlich zur dauerhaften Produktregel.

Prompt 1: freigegebene Arbeiten in REFERENCE.md übersetzen

Wähle drei bis fünf Beispiele, die eure Marke heute gut repräsentieren. Nutze eigene Produkt-Screens, ein Brand Deck, Marketinggrafiken oder die Komponentenbibliothek. Lege keine geschützten Assets von Wettbewerbern im Repository ab. Inspiration darf eine Entscheidung beeinflussen, wiederverwendete Beispiele müssen euch gehören oder entsprechend lizenziert sein.

Prüfe jede Datei in examples/. Trenne Beobachtungen von offenen Fragen.

Entwirf REFERENCE.md mit:
1. Quelleninventar und Freigabestatus
2. Farben mit gemessenen Werten und beobachteten Rollen
3. Typografie, Größen und Hierarchie
4. Abstands-, Grid- und Ausrichtungsmustern
5. Logo-Platzierung und Schutzraum
6. wiederkehrenden Komponenten und Kompositionen
7. fünf Mustern, die diese Marke vermeiden muss
8. ungeklärten Fragen

Erfinde keine fehlenden Werte. Zeige den Entwurf vor dem Speichern.

Ein gutes Ergebnis trennt Evidenz und Regel. „Die drei freigegebenen Screens nutzen 24 px zwischen Cards“ ist eine Beobachtung. „Alle Card-Gruppen müssen 24 px nutzen“ ist eine Regel, die ein Mensch freigeben sollte. Wer beides vermischt, macht historische Zufälle zur Doktrin.

Prompt 2: CLAUDE.md als schlanken Router nutzen

Halte den Verweis kurz. Eine große Anweisungsdatei verbraucht in jeder Session Kontext, obwohl das Detailmaterial nur bei Interface-Arbeit relevant ist.

## Interface-Arbeit

Lies vor neuen oder geänderten UI-Elementen REFERENCE.md und DESIGN.md. Prüfe danach das ähnlichste freigegebene Beispiel in examples/.
Nutze vorhandene Komponenten und semantische Tokens, bevor du neue anlegst.
Wenn Quellen widersprüchlich sind oder eine wichtige Entscheidung offenlassen, frage nach statt zu raten.
Vergleiche vor Abschluss das gerenderte Ergebnis mit den Designregeln und nenne jede absichtliche Ausnahme.

Der Router sagt, wann gelesen wird, welche Quelle Vorrang hat und wie die Prüfung aussieht. Bei einer bereits langen CLAUDE.md eignen sich pfadbezogene Regeln für Frontend-Dateien. Ein Import ordnet Inhalte besser, spart laut Anthropic aber keinen Startkontext, weil der importierte Text ebenfalls geladen wird.

Prompt 3: aus der Referenz einen Umsetzungsvertrag machen

DESIGN.md ist das Build-Regelwerk. Das entstehende DESIGN.md-Format von Google Labs beschreibt eine eigenständige Datei mit optionalen maschinenlesbaren Tokens im YAML-Frontmatter und menschlich lesbarer Begründung im Markdown-Text. Das erhöht die Portabilität, ist aber keine Voraussetzung von Claude Code.

Lies REFERENCE.md und examples/README.md. Prüfe danach jedes freigegebene Beispiel.

Entwirf DESIGN.md als Umsetzungsvertrag mit:
1. semantischen Farb-Tokens, benannt nach Aufgabe statt Farbton
2. Typografie- und Abstandsskalen mit exakten Werten
3. Layout-, Grid- und Breakpoint-Regeln
4. Komponentenaufbau, Zuständen und Wiederverwendungsregeln
5. Interaktion, Bewegung und Reduced-Motion-Verhalten
6. Anforderungen an Barrierefreiheit
7. responsiven Beispielen und Randfällen
8. Entscheidungslog mit Datum, Owner und Grund

Markiere jede abgeleitete statt freigegebene Regel. Frage bei Widersprüchen nach. Zeige die Datei vor dem Speichern.

Rollenbasierte Namen überleben ein Redesign besser. color-text-primary beschreibt die Aufgabe; dark-gray nur den heutigen Wert. Wenn Werte auch in Design- und Build-Tools fließen müssen, braucht es daneben eine maschinenlesbare Tokenquelle.

Warum sind Beispiele wichtiger als ein längerer Prompt?

Regeln zeigen, was erlaubt ist. Freigegebene Beispiele zeigen Proportion, Dichte, Hierarchie und Komposition im Zusammenspiel. Anthropic empfiehlt für das separate Produkt Claude Design einen ähnlichen Ansatz: Die offizielle Anleitung zum Designsystem akzeptiert Codebasen, Prototypen, Präsentationen und Brand Assets und rät zu realen Beispielen statt nur zu Spezifikationen.

Wähle nach Abdeckung, nicht nach Menge. Ein dichtes Dashboard, eine Marketingseite, ein formularreicher Ablauf und ein mobiler Zustand erklären meist mehr als fünfzig fast gleiche Hero Sections.

Soll DESIGN.md Design Tokens ersetzen?

Nein. DESIGN.md erklärt Designabsicht; eine Token-Datei liefert ein strenges Austauschformat für Tools. Nutze beides, wenn Werte in Code, Design-Tools und Tests fließen. Das stabile Format der Design Tokens Community Group definiert ein JSON-Modell für Namen, Werte, Typen und Metadaten. Die Token-Datei verantwortet exakte Maschinenwerte, DESIGN.md erklärt deren Einsatz.

Wie verhindert man, dass das System Fehler kopiert?

1. Jede Quelle beschriften. Freigegeben, historisch, experimentell oder nur Inspiration.
2. Vorrang festlegen. Aktuelle Tokens schlagen Screenshots bei exakten Werten. Eine geprüfte Komponente schlägt eine alte Kampagnengrafik beim Verhalten.
3. Ausnahmen dokumentieren. Wenn eine Kampagne absichtlich das Grid bricht, gehört das ins Manifest.
4. Varianten verlangen. Lass drei Alternativen entstehen, bevor du polierst. Die Auswahl bleibt eine menschliche Designentscheidung.
5. Nur Geprüftes befördern. Ein Ergebnis wandert nach der Freigabe in examples/, nicht direkt nach der Generierung.

Was muss der Validierungsloop prüfen?

Der erzeugende Agent darf nicht der einzige Richter sein. Er kann den ersten Vergleich ausführen. Danach braucht es deterministische Checks und einen Menschen mit Freigaberechten.

Claude-Code-Dateien oder Claude Design: Was passt besser?

Wie führt ein Team den Workflow ein?

1. Repräsentative Arbeit wählen. Decke Produkt-UI, Marketing und mindestens einen schwierigen Zustand ab.
2. Quelldateien entwerfen und prüfen. Design verantwortet die visuelle Wahrheit, Engineering die Umsetzbarkeit.
3. Routing-Regel verdrahten. Halte CLAUDE.md kurz und teste, ob Claude die Quellen wirklich lädt.
4. Drei Aufgabentypen pilotieren. Neue Komponente, Änderung an einem Screen und responsive Reparatur.
5. Nacharbeit messen. Erfasse Review-Runden, nicht freigegebene Tokens, doppelte Komponenten, Accessibility-Fehler und akzeptierte Erstfassungen.
6. Pflege zuweisen. Benenne Owner für Tokens, Komponenten, Beispiele und Entscheidungslog.

Die Kaufentscheidung lautet nicht „Welches Prompt-Paket kaufen wir?“, sondern „Wer verantwortet den Designvertrag, wie prüfen wir ihn und welche Änderungen brauchen Freigabe?“ Wavects AI Enablement macht aus punktuellem Agenteneinsatz einen gesteuerten Workflow mit Repository-Kontext, Evaluationen und Review Gates. Wenn ein KI-generiertes Produkt bereits gehärtet werden muss, hilft der Entscheidungsleitfaden vom Prototyp zur Produktion beim Scoping.

Forschungsgrenze

Geprüft am 2. September 2026 anhand des ursprünglichen Workflows, der aktuellen Claude-Code-Memory-Dokumentation, der Google-Labs-DESIGN.md-Spezifikation, Anthropics Anleitung zu Claude Design und des stabilen Formats der Design Tokens Community Group. Produktverhalten und Beta-Verfügbarkeit können sich ändern. Wir nennen keine Produktivitätszahl, weil es für diesen Workflow keinen unabhängigen teamübergreifenden Benchmark gibt.