design-reference — eine Oberfläche, die zur Referenz wird, nicht zur Vorlage
Eine Oberfläche ist eine Referenz, wenn jemand, der das Thema kennt, sie erkennt als für dieses Produkt gemacht und von jemandem an der Spitze des Fachs. Der Feind ist der Default: was jedes Modell für jeden ähnlichen Auftrag produzieren würde.
0. Die Projektregeln
Der erste Schritt jedes gerenderten Stücks — Bildschirm, Komponente, HTML-Dokument,
Artifact, PDF, Deck, Diagramm (cloud-diagram), Banner — ist der Scan des
Designsystems des Projekts, einmal pro Projekt pro Sitzung:
python3 -I ~/.claude/skills/design-reference/scripts/sweep.py <root> # Zusammenfassung
python3 -I ~/.claude/skills/design-reference/scripts/sweep.py <root> --css # :root mit --ds-*
Es liest die schriftliche Spezifikation (DESIGN.md, docs/design*), Tokens
(tailwind.config.*, CSS mit :root/@theme, *.tokens.json), das
Komponenten-Theme, package.json, components.json, Storybook- und Figma-Links,
und gibt das Urteil zurück: Projekt (das Stück trägt seine Tokens) oder
neutral (die neutrale Palette des Teams). --css gibt --ds-bg --ds-surface --ds-fg --ds-fg-2 --ds-accent --ds-border --ds-font-display --ds-font-body --ds-font-mono und den Dunkelmodus-Block aus; die Vorlagen des Teams lesen
diese Variablen. --json gibt den vollständigen Befund zurück. Priorität bei
Konflikten: Spezifikation > Tokens > Komponenten. Ein System pro Seite. Sage in
einem Satz, welches System das Stück trägt und wo es gefunden wurde. Die Marke
eines Kunden oder Drittanbieters: zuerst fragen. Details in references/design-system-sweep.md.
Lies dann die gemeinsamen Komponenten, die der neue Bildschirm verwenden wird.
Das Briefing und die bereits festgelegte visuelle Welt schlagen jeden Geschmack
von dir und jede Regel hier. Verfeinerung bewahrt Identität, Text und Verhalten;
Neugestaltung ersetzt die gesamte visuelle Welt — poliere niemals das Aussehen,
das verworfen wurde. Ein eigenes Design-Skill des Projekts (.claude/skills/)
gewinnt über dieses hier.
Ohne eine DESIGN.md ist das Projekt nicht unbedingt eine grüne Wiese: Der
Beweis ist der Code und die vorhandenen Bildschirme, nicht der Dateiname.
1. Oberflächenmodus (bestimmt alles, was folgt)
Wähle nach der angeforderten Oberfläche, nicht nach dem Produkt:
| Modus | Erfolg des Besuchers | Beispiele | Was regiert |
|---|---|---|---|
| Überzeugen | entscheidet und handelt | Landingpage, Preise, Kampagne | Aufmerksamkeit, Beweis, Handlungsaufruf — Design ist das Produkt |
| Bedienen | erledigt eine Aufgabe | App, Dashboard, Admin, Editor, Einstellungen | Scanbarkeit, Konsistenz, native Erwartung; die Marke lebt im Detail |
| Lesen | versteht etwas | Doku, Artikel, Changelog, Hilfe | Struktur für Verständnis, dann Lesekomfort |
| Erleben | ist im Werk | Portfolio, Galerie, Museum, Showcase | Das Werk führt ab dem ersten Bildschirm; die Oberfläche tritt zurück |
Die Landingpage eines Tools ist Überzeugen; die Dokumentation einer Modemarke ist Lesen; die Tour eines Museums ist Erleben.
2. Richtung vor Code (zwei Durchgänge, Pflicht)
Durchgang 1 — kompakter Plan, bevor eine Code-Datei geöffnet wird:
- Thema: Ein Satz: für wen es ist, was die einzige Aufgabe dieses Bildschirms ist, und was in der Welt dieses Themas (Materialien, Instrumente, Vokabular, Artefakte) zu einer visuellen Wahl werden kann.
- Farbe: 4–6 benannte Werte (Hex oder oklch), mit der semantischen Rolle jedes einzelnen.
- Schrift: 2+ Rollen — eine ausdrucksstarke Display-Schrift, die mit Zurückhaltung eingesetzt wird, eine ergänzende Grundschrift, bei Bedarf eine Dienstschrift für Daten. Niemals das Paar, das du in jedem anderen Projekt verwenden würdest.
- Layout: Konzept in einem Satz + ASCII-Wireframe. Vergleiche zwei Alternativen.
- Signatur: Das eine Element, an das man sich bei diesem Bildschirm erinnert. Die gesamte Kühnheit fließt dorthin; der Rest bleibt ruhig und diszipliniert.
- Bewegung: Ein orchestrierter Moment, oder keiner. Sage welcher.
Durchgang 2 — Selbstkritik. Frage zu jedem Punkt: „Würde ich das für einen ähnlichen Auftrag eines anderen Produkts produzieren?