--- title: "Claude-Code-Designsystem: 4 Bausteine für Marken-UI" canonical: https://wavect.io/de/blog/claude-code-design-system-files/ language: de description: "Baue ein Claude-Code-Designsystem mit REFERENCE.md, CLAUDE.md, DESIGN.md und Beispielen. Mit Prompts, QA-Checks und Team-Rollout für Produktteams in der Praxis." image: "https://wavect.io/img/blog/headers/header_claude-code-design-system-files.png" --- [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 Min Lesezeit · 2. September 2026 Zuletzt geprüft 2. September 2026 [**Weiter**](/de/blog/ai-coding-agents-context-not-intelligence/) # Claude-Code-Designsystem: 4 Bausteine für markentreue UI TL;DR Ein Claude-Code-Designsystem kann als vierteiliger Workflow im Repository leben: REFERENCE.md hält visuelle Evidenz und verbindliche Markenregeln fest, CLAUDE.md weist Claude an, diese Regeln vor Designarbeit zu laden und danach zu prüfen, DESIGN.md übersetzt sie in umsetzbare Tokens und Komponentenentscheidungen, und examples/ bewahrt freigegebene Arbeiten zur Wiederverwendung auf. Nur CLAUDE.md ist ein nativer Mechanismus von Claude Code; die anderen Namen sind sinnvolle Projektkonventionen, keine Vorgaben von Anthropic. Starte mit realen Arbeiten, trenne Beobachtungen von Entscheidungen, benenne Tokens nach ihrer Aufgabe, fordere mehrere Varianten an und prüfe Screenshots, Barrierefreiheit und automatisierte Tests. Teams sollten Verantwortliche benennen, die Dateien versionieren und den Workflow an repräsentativen Aufgaben pilotieren. **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](https://charliehills.substack.com/p/ai-design-system). 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](/de/blog/ai-coding-agents-context-not-intelligence/). Für produktionsreife Software bleibt unsere [Checkliste für KI-generierte Anwendungen](/de/blog/vibe-code-production-readiness-checklist/) zuständig. ## Welche vier Bausteine hat ein Claude-Code-Designsystem? | Baustein | Aufgabe | Was hineingehört | Was nicht | | --- | --- | --- | --- | | `REFERENCE.md` | Evidenz | Beobachtete Farben, Typografie, Abstände, Logo-Nutzung, Layouts und verbotene Muster | Ungeprüfte Vermutungen oder Umsetzungscode | | `CLAUDE.md` | Routing | Kurze Anweisung zum Lesen der Designquellen vor UI-Arbeit und zur Prüfung danach | Das ganze Markenhandbuch | | `DESIGN.md` | Umsetzungsvertrag | Semantische Tokens, Komponentenregeln, responsive Vorgaben, Barrierefreiheit und Entscheidungen | Ein Moodboard voller vager Adjektive | | `examples/` | Freigegebene Muster | Repräsentative Screens und Assets, die dein Team besitzt und wiederverwenden darf | Eine unsortierte Inspirationssammlung | 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](https://code.claude.com/docs/en/memory), 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](https://github.com/google-labs-code/design.md/blob/main/docs/spec.md) 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](https://support.claude.com/en/articles/14604397-set-up-your-design-system-in-claude-design) 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](https://www.designtokens.org/tr/2025.10/format/) 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? | Prüfung | Methode | Fehlersignal | | --- | --- | --- | | Token-Nutzung | CSS- oder Theme-Referenzen linten | Hart codierte Farben, Abstände oder Typowerte ohne freigegebene Ausnahme | | Komponenten-Reuse | Imports und gerenderte Zustände prüfen | Eine fast identische neue Komponente statt einer Erweiterung | | Responsive Verhalten | Repräsentative Desktop- und Mobile-Screenshots | Overflow, verlorene Hierarchie oder fehlende Zustände | | Barrierefreiheit | Automatisierte Checks plus Tastatur- und Screenreader-Test | Fehler bei Kontrast, Fokus, Labels, Bewegung oder Interaktion | | Visuelle Konsistenz | Direktvergleich mit dem nächsten freigegebenen Beispiel | Unerklärte Abweichung bei Dichte, Ausrichtung, Typografie oder Komposition | | Produktkorrektheit | Akzeptanztests und menschliches Review | Das Interface sieht richtig aus, löst aber die falsche Aufgabe | 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? | Bedarf | Repository-Workflow | Claude Design | | --- | --- | --- | | Versionierte Regeln neben dem Code | Sehr passend | Export oder Sync kann nötig sein | | Vorhandene Komponenten bei der Umsetzung | Sehr passend | Nützlich mit verbundener Codebasis | | Gemeinsame visuelle Exploration ohne Entwicklung | Erfordert Repository-Workflow | Stärker passend | | Deterministische CI-Checks | Sehr passend | Checks im Code-Repository ausführen | | Organisationsweit verwaltetes UI Kit | Eigene Governance nötig | Für gemeinsame Organisationssysteme gebaut | ## 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](/de/services/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](/de/software-development-guide/vibe-coded-prototype-to-production/) beim Scoping. ## Häufige Fragen ### Liest Claude Code DESIGN.md automatisch? Nein. Claude Code lädt unterstützte CLAUDE.md-Anweisungsdateien automatisch. Weise dort ausdrücklich an, wann DESIGN.md und REFERENCE.md gelesen werden, und prüfe das über die Memory-Ansicht oder einen beobachteten Testlauf. ### Ist DESIGN.md ein offizieller Anthropic-Standard? Nein. Es ist eine Projektkonvention und ein entstehendes offenes Format von Google Labs. Claude Code kann jeden lesbaren Dateinamen nutzen, auf den deine Anweisungen verweisen. ### Gehören Markenregeln oder Beobachtungen in REFERENCE.md? Beginne mit Beobachtungen und benenne ihre Quellen. Mache daraus erst verbindliche Regeln, wenn ein menschlicher Owner sie freigegeben hat. So wird ein zufälliges Muster nicht zur dauerhaften Policy. ### Wie viele Beispiele sollte Claude Code erhalten? Starte mit drei bis fünf freigegebenen Beispielen, die unterschiedliche Interface-Probleme abdecken. Ergänze erst dann eines, wenn es eine wiederkehrende Unklarheit löst. Abdeckung und Herkunft zählen mehr als Menge. ### Ersetzt das eine echte Komponentenbibliothek? Nein. Die Dateien erklären Entscheidungen und steuern den Agenten. Konsistenz in Produktion entsteht weiterhin durch wiederverwendbare Komponenten, maschinenlesbare Tokens, automatisierte Prüfungen und menschliche Verantwortung. ## 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.* ## Fazit Der dauerhafte Vorteil ist kein cleverer Prompt. Es ist ein kleines, prüfbares System, das Evidenz, Anweisungen, Umsetzungsregeln und freigegebene Beispiele trennt. Starte mit Arbeit, der dein Team schon vertraut. Mache Unsicherheit sichtbar, halte das Routing kurz und teste das gerenderte Ergebnis. Claude kann Regeln konsistent halten. Menschen entscheiden weiterhin, ob diese Regeln gut sind. ## Das könnte dich auch interessieren.. [**Coding-Agenten brauchen Kontext, nicht mehr Intelligenz** Warum dauerhafter Repository-Kontext, fokussierte Aufgaben und unabhängige Prüfung weit über visuelles Design hinaus zählen.](/de/blog/ai-coding-agents-context-not-intelligence/) [**AI Enablement oder generische KI-Beratung** Vergleiche einen gesteuerten Umsetzungsworkflow mit einem reinen Strategieprojekt.](/de/compare/ai-enablement-vs-generic-ai-consultancy/) Agent Engineering ## In diesem Cluster weiterlesen Coding Agents, MCP, Kontextsysteme, Evaluation und Kontrollen für verlässliche Automatisierung. [Mit dem Grundlagenartikel starten**Graph Engineering für KI-Agenten: Wann lohnt sich ein Knowledge Graph?**](/de/blog/graph-engineering-ai-agents/) - [Obscura Browser im Test: Aussagen, Grenzen und Produktions-Fit](/de/blog/obscura-rust-browser-ai-agents/) - [ChatGPT-Login: Das Modell sieht dein Passwort nicht](/de/blog/chatgpt-cloud-browser-secure-login/) - [KI-Agenten-Harness erklärt: Die Zuverlässigkeitsschicht rund um ein LLM](/de/blog/agent-harness-engineering/) - [Warum Agenten-Edits semantische Identität brauchen: SEMAPRAX in Rust](/de/blog/semantic-identity-rust-agent-edits/) - [LangChain Deep Agents im Test: Ist das Agent Harness produktionsreif?](/de/blog/langchain-deep-agents-review/) [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 Min Lesezeit · 2. September 2026 Zuletzt geprüft 2. September 2026 [**Weiter**](/de/blog/ai-coding-agents-context-not-intelligence/) ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/claude-code-design-system-files/#webpage", "@type": "WebPage", "dateModified": "2026-09-02", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-09-02", "url": "https://wavect.io/de/blog/claude-code-design-system-files/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Ein Claude-Code-Designsystem kann als vierteiliger Workflow im Repository leben: REFERENCE.md hält visuelle Evidenz und verbindliche Markenregeln fest, CLAUDE.md weist Claude an, diese Regeln vor Designarbeit zu laden und danach zu prüfen, DESIGN.md übersetzt sie in umsetzbare Tokens und Komponentenentscheidungen, und examples/ bewahrt freigegebene Arbeiten zur Wiederverwendung auf. Nur CLAUDE.md ist ein nativer Mechanismus von Claude Code; die anderen Namen sind sinnvolle Projektkonventionen, keine Vorgaben von Anthropic. Starte mit realen Arbeiten, trenne Beobachtungen von Entscheidungen, benenne Tokens nach ihrer Aufgabe, fordere mehrere Varianten an und prüfe Screenshots, Barrierefreiheit und automatisierte Tests. Teams sollten Verantwortliche benennen, die Dateien versionieren und den Workflow an repräsentativen Aufgaben pilotieren.", "articleBody": " Blog-Übersicht/AI und Agents/Agent Engineering Claude-Code-Designsystem: 4 Bausteine für markentreue UI TL;DR Ein Claude-Code-Designsystem kann als vierteiliger Workflow im Repository leben: REFERENCE.md hält visuelle Evidenz und verbindliche Markenregeln fest, CLAUDE.md weist Claude an, diese Regeln vor Designarbeit zu laden und danach zu prüfen, DESIGN.md übersetzt sie in umsetzbare Tokens und Komponentenentscheidungen, und examples/ bewahrt freigegebene Arbeiten zur Wiederverwendung auf. Nur CLAUDE.md ist ein nativer Mechanismus von Claude Code; die anderen Namen sind sinnvolle Projektkonventionen, keine Vorgaben von Anthropic. Starte mit realen Arbeiten, trenne Beobachtungen von Entscheidungen, benenne Tokens nach ihrer Aufgabe, fordere mehrere Varianten an und prüfe Screenshots, Barrierefreiheit und automatisierte Tests. Teams sollten Verantwortliche benennen, die Dateien versionieren und den Workflow an repräsentativen Aufgaben pilotieren. 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? BausteinAufgabeWas hineingehörtWas nicht REFERENCE.mdEvidenzBeobachtete Farben, Typografie, Abstände, Logo-Nutzung, Layouts und verbotene MusterUngeprüfte Vermutungen oder Umsetzungscode CLAUDE.mdRoutingKurze Anweisung zum Lesen der Designquellen vor UI-Arbeit und zur Prüfung danachDas ganze Markenhandbuch DESIGN.mdUmsetzungsvertragSemantische Tokens, Komponentenregeln, responsive Vorgaben, Barrierefreiheit und EntscheidungenEin Moodboard voller vager Adjektive examples/Freigegebene MusterRepräsentative Screens und Assets, die dein Team besitzt und wiederverwenden darfEine unsortierte Inspirationssammlung 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", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "vierteiliges Markensystem mit Prompts", "url": "https://charliehills.substack.com/p/ai-design-system" }, { "@type": "WebPage", "name": "Claude-Code-Memory-Anleitung", "url": "https://code.claude.com/docs/en/memory" }, { "@type": "WebPage", "name": "DESIGN.md-Format von Google Labs", "url": "https://github.com/google-labs-code/design.md/blob/main/docs/spec.md" }, { "@type": "WebPage", "name": "offizielle Anleitung zum Designsystem", "url": "https://support.claude.com/en/articles/14604397-set-up-your-design-system-in-claude-design" }, { "@type": "WebPage", "name": "Format der Design Tokens Community Group", "url": "https://www.designtokens.org/tr/2025.10/format/" } ], "dateModified": "2026-09-02", "datePublished": "2026-09-02", "description": "Ein Claude-Code-Designsystem kann als vierteiliger Workflow im Repository leben: REFERENCE.md hält visuelle Evidenz und verbindliche Markenregeln fest, CLAUDE.md weist Claude an, diese Regeln vor Designarbeit zu laden und danach zu prüfen, DESIGN.md übersetzt sie in umsetzbare Tokens und Komponentenentscheidungen, und examples/ bewahrt freigegebene Arbeiten zur Wiederverwendung auf. Nur CLAUDE.md ist ein nativer Mechanismus von Claude Code; die anderen Namen sind sinnvolle Projektkonventionen, keine Vorgaben von Anthropic. Starte mit realen Arbeiten, trenne Beobachtungen von Entscheidungen, benenne Tokens nach ihrer Aufgabe, fordere mehrere Varianten an und prüfe Screenshots, Barrierefreiheit und automatisierte Tests. Teams sollten Verantwortliche benennen, die Dateien versionieren und den Workflow an repräsentativen Aufgaben pilotieren.", "headline": "Claude-Code-Designsystem: 4 Bausteine für markentreue UI", "image": "https://wavect.io/img/blog/headers/header_claude-code-design-system-files.svg", "inLanguage": "de", "keywords": "KI-Engineering, Designsysteme", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/claude-code-design-system-files/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/claude-code-design-system-files/", "wordCount": 1891 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/ai-agents/", "name": "AI und Agents", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/agent-engineering/", "name": "Agent Engineering", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/claude-code-design-system-files/", "name": "Claude-Code-Designsystem: 4 Bausteine für Marken-UI | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nein. Claude Code lädt unterstützte CLAUDE.md-Anweisungsdateien automatisch. Weise dort ausdrücklich an, wann DESIGN.md und REFERENCE.md gelesen werden, und prüfe das über die Memory-Ansicht oder einen beobachteten Testlauf." }, "name": "Liest Claude Code DESIGN.md automatisch?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nein. Es ist eine Projektkonvention und ein entstehendes offenes Format von Google Labs. Claude Code kann jeden lesbaren Dateinamen nutzen, auf den deine Anweisungen verweisen." }, "name": "Ist DESIGN.md ein offizieller Anthropic-Standard?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Beginne mit Beobachtungen und benenne ihre Quellen. Mache daraus erst verbindliche Regeln, wenn ein menschlicher Owner sie freigegeben hat. So wird ein zufälliges Muster nicht zur dauerhaften Policy." }, "name": "Gehören Markenregeln oder Beobachtungen in REFERENCE.md?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Starte mit drei bis fünf freigegebenen Beispielen, die unterschiedliche Interface-Probleme abdecken. Ergänze erst dann eines, wenn es eine wiederkehrende Unklarheit löst. Abdeckung und Herkunft zählen mehr als Menge." }, "name": "Wie viele Beispiele sollte Claude Code erhalten?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nein. Die Dateien erklären Entscheidungen und steuern den Agenten. Konsistenz in Produktion entsteht weiterhin durch wiederverwendbare Komponenten, maschinenlesbare Tokens, automatisierte Prüfungen und menschliche Verantwortung." }, "name": "Ersetzt das eine echte Komponentenbibliothek?" } ] } ```