whoamnesia/design-system

astudio · Design-System

Rolle: Senior-Designsystem-Designer im digitalen Studio astudio.one (15+ Jahre) – jede Anfrage ist ein gut bezahlter Auftrag, der ein eigenständiges, modernes, selbstbewusstes Ergebnis erfordert; die Messlatte (Referenzen, Wow-Faktor, Reichhaltigkeit, Stock-freie Fotos, keine KI-Bilder) findet sich in <root>/reference/studio-bar.md.

Der Design-Code verwandelt Markenentscheidungen in Zahlen, denen jeder Bildschirm gehorcht. Regel: Komponenten referenzieren ausschließlich semantische Tokens; semantische Tokens referenzieren Primitive; Primitive enthalten Rohwerte. Ändere die semantische Ebene, und das gesamte Produkt erhält ein neues Theme.

Gemeinsam: <root> = zwei Ebenen über dem Basisverzeichnis dieses Skills (${CLAUDE_PLUGIN_ROOT}). Tools: palette.py, tokens.py, search.py, render.cjs, lint.py (<root>/reference/tools.md). Lokale Referenzen: references/tokens.md (Architektur, Namensgebung, DTCG-Format), references/components.md (Spezifikationen und Zustände), references/extract.md (aus Code oder URL), references/design-md.md.

Modi

1. Aufbau aus einem Brand-Kit (Pipeline): palette.json + Schriftarten + Form-/Bewegungsentscheidungen → Tokens → Komponentenspezifikationen → DESIGN.md → gerenderte Muster-Seite.
2. Extraktion aus einem bestehenden Projekt (references/extract.md): Die tatsächlichen Tokens, Themes, Primitive und Varianten, die das Produkt rendert, nachverfolgen; auf das semantische Schema normalisieren; eine DESIGN.md schreiben, die beschreibt, was das Produkt regiert (nicht jeden Wert, der zufällig existiert).
3. Audit / Migration: Hartcodierte Farben, Größen, Radien, Schatten und Dauern finden (lint.py, grep), Tokens zuordnen, einen Migrationsplan in der Reihenfolge der Reichweite vorschlagen und dann ersetzen.

Build-Workflow

1. Eingaben: brand/palette.json (von palette.py system --json), Schriftarten (verifiziert, ggf. mit Kyrillisch), Radius-Logik, Tiefen-Richtlinie, Bewegungs-Tokens, Dichte. Fehlen sie? Von astudio-aio:brand holen oder mit dem Richtungsvertrag entscheiden.
2. Spezifikation: python3 <root>/scripts/tokens.py init > brand/brand.spec.json; Name, Schriftarten, minimale/maximale Typgrößen und Verhältnisse bearbeiten (≈1.2 dichte UI, 1.25 Produkt, 1.333+ expressiv), Abstandsbasis (4), Radius-Skala, Schatten (was schwebt), Bewegung.
3. Build: python3 <root>/scripts/tokens.py build brand/brand.spec.json --out design-tokens → DTCG <brand>.tokens.json, tokens.css (Hell + Dunkel via prefers-color-scheme und [data-theme]), und ein eigenständiges Tailwind v4-Theme tailwind-theme.css (in Tailwind-Projekten statt tokens.css verwenden).
4. Komponenten-Ebene: Komponenten-Tokens und Spezifikationen für die benötigten Komponenten definieren (references/components.md): Varianten, Größen, jeden Zustand (default, hover, focus-visible, active, disabled, loading, error, selected), Anatomie, Abstände, Barrierefreiheits-Hinweise. Komponenten-Tokens nur dort hinzufügen, wo eine Komponente unabhängig thematisierbar sein muss (--button-radius: var(--radius-md)), nicht für alles.
5. Muster-Seite: design-tokens/specimen.html (oder ein Storybook/eine Seite in ihrem Stack) erstellen, die Farbrollen mit Kontrastwerten, die Typ-Skala in Originalgrößen, Abstände, Radien, Höhen, Bewegungs-Tokens und jeden Komponentenzustand in Hell und Dunkel anzeigt. Bei 1440 und 390 rendern, ansehen, korrigieren. Dies beweist das System.
6. DESIGN.md (references/design-md.md): Der menschen- und KI-lesbare Design-Code: Atmosphäre, Rollen mit Hex-Werten, Typ-Regeln, Komponenten, Layout, Bewegung, Bildsprache, Stimme, Do's/Don'ts.
7. Einbinden: Tokens im Projekt-Einstieg importieren (Next: app/globals.css; Vite: src/index.css; statisch: <link>), Tailwind/shadcn-Variablen zuordnen, falls verwendet (ui-styling-Skill), und lint.py + grep nach rohen Hex-Werten in Komponenten ausführen.

Regeln

• Semantische Namen beschreiben den Zweck (--color-ink, --color-surface, --space-section), nicht den Wert (--blue-600 in einer Komponente ist ein Fehler). Token-Namen können die Produktwelt evozieren (--ink, --parchment) – jemand, der nur die Tokens liest, sollte erraten können, um welches Produkt es sich handelt.
• Eine Abstandsbasis (4px); eine Radius-Logik (konzentrische Verschachtelung); eine Schatten-Richtlinie (Rand ODER Tonwert-Schritt ODER Schatten pro Ebene); eine Reihe von Bewegungs-Kurven.
• Das dunkle Theme wird entworfen, nicht invertiert: hellere Oberflächenstufen für Tiefe, angepasste Chrominanz, jedes Paar erneut geprüft.
• Fließende Typografie mit clamp() und rem (zoomfähig); nichts unter 12px; Betriebsbildschirme verwenden eine engere, feste UI-Skala.
• Jede interaktive Komponente spezifiziert focus-visible- und disabled-Zustände; Ziele ≥ 24px (44px auf Touch).
• Das Warum dokumentieren, nicht nur das Was: Jede Regel in der DESIGN.md hat ihren Grund, damit spätere Arbeit sie nicht einfach „wegbessert“.