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.
Wieso eigentlich eine orange Teetasse in Videos?
2012 oder 2013 — Rückflug aus der Karibik. Langer Flug, Bordmagazin, hinten im Modeteil: eine Konzeptseite. Moodboard zur Modefarbe des Jahres. Alles weiß. Alles orange. Knallig.
Seitdem: orangene Outfits, eine orange Teetasse in Dutzenden Videos, ein oranger Hoodie der in mehr Konferenzräume mitgekommen ist als mancher Kollege.
Firmenfarbe — nicht weil eine Agentur das empfohlen hat. Sondern weil ein Bordmagazin auf dem richtigen Flug aufgeschlagen hat.
Das WCAG-konforme Anpassen des Orangetons hat dann eine Modedesign-Ausbildung gebraucht um zu akzeptieren. Prinzip schlägt Geschmack. Ach ja: Ich muss mir neue Klamotten kaufen. Das neue Orange passt nicht mehr zu allem.
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.
Vorher: Infografik-Skill kannte #FF8C00. LinkedIn-Skill kannte #F97000. PDF-Skill kannte #F98000. Alle „orange“. Alle leicht anders.
Wieso nutzt viSales den Atkinson Hyperlegible-Font?
Atkinson Hyperlegible wurde vom Braille Institute entwickelt — speziell für Menschen mit Sehbeeinträchtigung. Buchstabenformen die nicht verwechselt werden können. Maximale Unterscheidbarkeit auch bei kleinen Größen.
Ich habe die Schrift 2017 bei viSales eingeführt, nicht weil sie gerade im Trend war — sondern weil sie funktioniert. In Infografiken, in Präsentationen, auf kleinen Bildschirmen. Das ist das Kriterium.
Modeänderungen bei Schriften folge ich nicht. Die design.md hält das fest: nicht als Regel, sondern als Begründung. Wer künftig den Font ändern will, weiß warum er nicht einfach die nächste Trendschrift nehmen sollte.
Warum verwendet die Infografik dann nicht Atkinson Hyperlegible?
SVG-Dateien sollten keine externen Webfonts laden — sie würden bei PDF-Export, Website-Einbindung oder Offline-Rendering fehlen.
Der System-Font-Stack rendert überall zuverlässig. 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.
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:
primary: "#F97316" primary-dark: "#C2410C" # WCAG-AA 6.29:1 auf Weiß font: "Atkinson Hyperlegible" # Lesbarkeit > Mode accent: "#0891B2" # WCAG-AA 4.83:1 auf Weiß
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.
Für wen ist das?
Für alle die mehrere Cowork-Skills für visuelle Outputs nutzen und Wert auf konsistentes Design legen. Sobald man mehr als einen Skill hat der Farben, Fonts oder Stilvorgaben kennen muss, lohnt sich die Zentralisierung.
Für Teams die mit Kunden zusammenarbeiten: statt ein Brand-PDF in jeden Prompt zu laden, einmalig eine kompakte design.md erstellen. Spart Zeit bei jedem Workflow-Lauf und macht das Warum hinter Designentscheidungen sichtbar.
Weniger geeignet für alle die nur einen einzigen Skill mit Designinfos nutzen — da ist der Overhead der Zentralisierung größer als der Nutzen. Ab zwei Skills lohnt es sich.
Wie komme ich an die design.md?
Das Google Labs Code Team hat das Format auf GitHub veröffentlicht — inklusive Erklärung und Beispielen:
→ github.com/google-labs-code/design.md
Der einfachste Weg: Repository klonen oder die Beispieldatei herunterladen und an die eigenen Bedürfnisse anpassen. Die Struktur ist bewusst einfach gehalten — YAML-Frontmatter für Maschinen, Fließtext für Menschen.
Für Cowork: die Datei in den Workspace-Ordner legen und im jeweiligen SKILL.md referenzieren. Claude liest sie beim nächsten Session-Start automatisch. Kein Plugin, kein Setup — eine Textdatei.
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
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.
Das ist der Kern des Konzepts: eine Änderung, alle Outputs konsistent. 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 — das reicht für konsistente Outputs.
Mit der Zeit wachsen die Einträge: WCAG-Begründungen, Ausnahmen, Kontext für bestimmte Ausgabekanäle. Die Datei entwickelt sich mit dem Workflow.
