Skill-Abo #4: Konsistentes Design aus einer Datei: Wie die design.md alle Skills steuert
- Eine design.md ersetzt das 40-seitige Brand-PDF — maschinenlesbar, versionierbar, von jedem Skill automatisch gelesen.
- Wer alle Designinfos zentral speichert, ändert sein Corporate Design in einer Zeile — alle Outputs folgen sofort.
- Atkinson Hyperlegible statt Trendschrift, WCAG-Orange statt Wunschorange: Prinzip schlägt Geschmack. Immer.
In den letzten Ausgaben (TV-Serien-Style)
Skill-Abo #1: Prompt Injection Scanner von Mark Zimmermann. KI-Agenten sind angreifbar — durch manipulierte Texte in Dokumenten, E-Mails oder Webseiten. Der Scanner erkennt solche Angriffe in drei Schichten: Strukturmuster, semantische Absicht und systemisches Risiko. 100 % Erkennungsrate bei 56 Tests.
Skill-Abo #2: LinkedIn Optimizer + LinkedIn Orchestrator von Mark Zimmermann. Profil-Scoring in 10 Kategorien, drei Headline-Varianten, SSI-Aktionsplan. Plus: 7-Phasen-System von Positionierung bis Monetarisierung. Kostenlos, MIT-Lizenz, sofort installierbar.
Skill-Abo #3: Caveman-Skill von Julius Brussee. Claude wortkarg machen und damit Token — und Kosten — sparen. Plus: lokale KI für Transkripte und Datensouveränität. 65 % weniger Output-Overhead bei gleicher Arbeitsleistung.
Ich habe Modedesign in der Ausbildung erlernt. Ich weiß, wie knalliges Orange wirkt. Trotzdem habe ich nun das gedämpftere Orange für viSales gewählt. Nicht weil mir die Farbe egal ist. Sondern weil WCAG-Kontrast wichtiger ist als mein Geschmack.
Das ist im Grunde die ganze Geschichte hinter unserer design.md.
Was ist eine design.md — und warum kein PDF?
Google Labs hat es vorgemacht: Designentscheidungen in einer einfachen Markdown-Datei dokumentieren. Kein InDesign-Brand-Manual, kein 40-seitiges PDF das niemand öffnet. Eine lesbare, versionierbare Textdatei — für Menschen und Maschinen gleichermaßen.
Das Konzept stammt vom Google Labs Code Team und ist auf GitHub veröffentlicht: github.com/google-labs-code/design.md. Die Idee dahinter: Designentscheidungen nicht nur dokumentieren, sondern mit Begründungen versehen — so dass auch KI-Tools verstehen, warum etwas so ist wie es ist.
Ich bin auf das Konzept gestoßen wie ich die meisten Werkzeuge entdecke: kurzes Video angeschaut, nach 30 Sekunden gestoppt, Link aus der Beschreibung kopiert und Claude gegeben mit dem Hinweis „Erklär mir, wo uns das genau nützt.” Das ist mein Filter für neue Tools. Nicht das komplette Tutorial — sondern die direkte Frage: Was bringt das konkret für uns?
Die Antwort war eindeutig.
Das Problem: Jeder Skill hatte sein eigenes Orange
Wir haben mehrere Skills die visuelle Outputs erzeugen: Infografiken, LinkedIn-Karussells, SkillCMS-Seiten, Präsentationen, Word-Dokumente, PDFs. Jeder dieser Skills hatte seine Designinfos fest eingebaut — Farben, Fonts, Stilprinzipien direkt im SKILL.md.
Das klingt erst mal harmlos. Wird es aber nicht, wenn man ändern will. Eine Farbkorrektur bedeutete: sechs Skills öffnen, sechs Mal den Hex-Wert suchen, sechs Mal patchen, sechs Mal testen. Und dabei unweigerlich: kleine Abweichungen zwischen den Outputs.
Die Lösung: Eine Datei, alle Skills
Heute gibt es eine zentrale design.md. Alle Skills lesen von dort — Farben, Fonts, Stilprinzipien, WCAG-Begründungen. Wenn ich morgen entscheide, doch das knalligere Orange zu verwenden: eine Zeile ändern. Ein Commit. Alle sechs Skills liefern am nächsten Tag konsistente Outputs.
Ein Ausschnitt aus der Datei:
Das Warum steht direkt neben dem Wert. Nicht in einem separaten Dokument, nicht im Kopf des Designers — direkt da, wo der Skill es liest.
So funktioniert's
Die design.md ist eine einfache Textdatei im Markdown-Format mit YAML-Frontmatter. Im Frontmatter stehen die maschinenlesbaren Werte: Farben als Hex-Codes, Schriften als Font-Stack, Abstände als Pixel-Werte. Im Fließtext darunter stehen die Begründungen — lesbar für Menschen.
Jeder angepasste Skill der visuelle Outputs erzeugt, liest die Datei zu Beginn einer Session. Claude extrahiert die relevanten Werte und wendet sie automatisch an — ohne dass man jedes Mal neu erklären muss, welches Orange das richtige ist.
Das Ergebnis: Infografik, Präsentation, LinkedIn-Karussell und PDF sehen aus wie aus einem Guss — weil sie aus derselben Quelle kommen.
Warum wir das auch für Kunden machen
Wenn wir mit Kunden an KI-gestützten Workflows arbeiten, stellt sich schnell die Frage: Wie bekommt Claude die Designinfos des Kunden? Die klassische Antwort: Brand-PDF übergeben. 40 Seiten. Claude liest sie, extrahiert was relevant ist — meistens.
Die bessere Antwort: Wir destillieren die relevanten Designentscheidungen einmalig in eine kompakte design.md. Wenige Zeilen. Maschinenlesbar. Direkt in den Skill-Kontext geladen.
Das spart Zeit bei jedem einzelnen Workflow-Lauf. Und es macht etwas sichtbar was im PDF oft fehlt: das Warum hinter den Entscheidungen. Nicht nur „Hauptfarbe: Blau” — sondern „Hauptfarbe: #1D4ED8, WCAG-AA konform, nicht auf dunklem Hintergrund verwenden.”
Mein Take
Die design.md ist kein Skill. Sie ist die Infrastruktur unter den Skills. Der unsichtbare Teil der dafür sorgt, dass alle sichtbaren Teile zusammenpassen.
Das Google-Labs-Format hat mir gezeigt, dass es einen Standard dafür gibt — auch wenn ich unabhängig auf das gleiche Konzept gekommen wäre. Gut, dass es ihn gibt. Es erleichtert die Übergabe zwischen Tools, zwischen Sessions, zwischen Mensch und KI.
Eine Anmerkung: Die Infografik in dieser Ausgabe verwendet den System-Font-Stack, nicht Atkinson Hyperlegible. Warum? Weil SVG-Dateien keine externen Webfonts laden sollten — sie würden bei PDF-Export oder Offline-Rendering fehlen. Das ist eine bewusste Ausnahme von der design.md. Manchmal umgeht man das eigene System aus gutem Grund. Auch das gehört in die Dokumentation.
Viele Grüße aus Bochum,
Gerhard Schröder
PS: Du baust Cowork-Skills? Schick mir deinen besten — wenn er hält was er verspricht, stelle ich ihn hier vor. Einfach antworten.
Häufige Fragen zur design.md
Häufige Fragen
Was ist der Unterschied zwischen einer design.md und einem Brand-Manual?
Ein Brand-Manual ist für Menschen geschrieben — meist als PDF, mit Screenshots, Beispielen und Erklärungen. Eine design.md ist zusätzlich für Maschinen lesbar: KI-Tools, Skills und Workflows können die Werte direkt verwenden, ohne dass jemand manuell etwas überträgt. Das eine ersetzt das andere nicht zwingend — aber für den täglichen KI-Workflow ist die design.md das effizientere Werkzeug.
Muss ich programmieren können um eine design.md zu erstellen?
Nein. Eine design.md ist eine einfache Textdatei — YAML-Frontmatter für die Werte, Fließtext für die Begründungen. Wer eine E-Mail schreiben kann, kann eine design.md pflegen. Das Format von Google Labs Code ist bewusst einfach gehalten. Es gibt keine Syntax die man lernen muss — nur Struktur die man einhält.
Funktioniert die design.md nur mit Cowork-Skills?
Nein. Das Format ist werkzeugagnostisch — es funktioniert überall wo Claude oder ein anderes LLM eine Textdatei lesen kann. Cowork-Skills sind ein besonders guter Anwendungsfall, weil sie den Kontext der design.md direkt in jeden Workflow laden. Das Google-Labs-Format wurde unabhängig von Cowork entwickelt und lässt sich auch in anderen KI-Workflows nutzen.
Was passiert wenn ich die design.md ändere?
Alle Skills die auf die Datei referenzieren, verwenden beim nächsten Start automatisch die neuen Werte. Es gibt keine Synchronisierung, kein Deployment — die Änderung ist sofort wirksam. Ob du die Hauptfarbe anpasst, einen Font wechselst oder einen neuen Stil-Parameter hinzufügst — alle Skills folgen.
Wie detailliert muss eine design.md sein?
So detailliert wie nötig, so kompakt wie möglich. Eine funktionierende design.md kann mit Primärfarbe, Font und zwei Stilprinzipien beginnen. Mit der Zeit wachsen die Einträge: WCAG-Begründungen, Ausnahmen, Kontext für bestimmte Ausgabekanäle. Die Datei entwickelt sich mit dem Workflow.