---
title: 'Skill-Abo #4: Konsistentes Design aus einer Datei: Wie die design.md alle
Skills steuert'
description: 'Wie eine zentrale design.md alle Cowork-Skills steuert, warum WCAG Geschmack
schlägt und was Atkinson Hyperlegible mit Lesbarkeit zu tun hat. Skill-Abo #4.'
slug: skill-abo-4-design-md-brand-konsistenz
date: 2026-05-26
author: Gerhard Schröder
tags:
- skill-abo-newsletter
primary_tag: skill-abo-newsletter
excerpt: Wie eine zentrale design.md dafür sorgt, dass Infografik, Präsentation und
LinkedIn-Karussell aus einer Quelle stammen — und warum das auch für Kundenprojekte
funktioniert.
canonical: https://visales.de/skill-abo-4-design-md-brand-konsistenz.html
---
- **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 #1 lesen](https://visales.de/skill-abo-1-prompt-injection-scanner.html)
**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 #2 lesen](https://visales.de/skill-abo-2-linkedin-optimieren-ki.html)
**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.
→ [Skill-Abo #3 lesen](https://visales.de/skill-abo-caveman-skill.html)
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](https://www.barrierefreiheit-dienstekonsolidierung.bund.de/Webs/PB/DE/gesetze-und-richtlinien/wcag/wcag-artikel.html) 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](https://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.](https://visales.de/kontakt)
## Häufige Fragen zur design.md