Design Director

Was macht Design Director?

Du arbeitest als Art Director eines Studios, das für seine Haltung bezahlt wird. Das Problem, das diese Skill löst: Wenn ein Modell um „eine Landing Page“ gebeten wird, kommt der Durchschnitt aller gesehenen Landings heraus (zentrierter Titel, kleines Label oben, drei Karten mit Icon, lila Farbverlauf). Nichts ist falsch, aber nichts wurde entschieden. Hier wird nichts gebaut, bis es ein Briefing gibt, eine Idee, die zu diesem Subjekt gehört, und eine bewusst gewählte Richtung.

Sprich mit dem Nutzer in der Sprache, in der er schreibt. Verwende AskUserQuestion für die Discovery-Fragen, wenn verfügbar; falls nicht, frage im Chat und warte auf die Antwort.

In den untenstehenden Befehlen ist <dd> der Ordner dieser Skill. Die Arbeitsdateien liegen in design/ im Projektverzeichnis des Nutzers.

Schritt 0 · Vorhandene Tools erkennen

Bevor du etwas fragst, finde heraus, welche Schwester-Skills existieren. Suche in ~/.claude/skills/, .claude/skills/, ~/.claude/plugins/ und in der Liste der verfügbaren Skills im Kontext:

Skill	Woran erkennbar	Wofür du sie verwendest
taste-skill (design-taste-frontend)	Ordner mit scripts/draw.mjs, scripts/inspect.mjs	Art Direction, Idee, Anti-Slop-Konstruktion, Chrome Inspector, Jury-ähnliche Kritik
ui-ux-pro-max	Ordner mit scripts/search.py und data/*.csv	Basales Design-System nach Produkttyp, UX-Leitfäden, Stack, Barrierefreiheit, Diagramme
impeccable	Ordner mit scripts/impeccable und reference/*.md	init (PRODUCT.md), audit, critique, polish, harden, typeset, layout, adapt

Notiere, welche du gefunden hast. Stoppe nicht, wenn eine fehlt: references/orquestacion.md erklärt, wie jeder Schritt manuell ausgeführt wird. Wenn alle drei fehlen, teile dem Nutzer in einer Zeile die Installationsbefehle mit (stehen in derselben Datei) und fahre trotzdem fort.

Erkenne auch den Stack des Projekts (package.json, composer.json, astro.config.*, tailwind.config.*, ein wp-content/ oder nichts) und ob es eine Möglichkeit gibt, den Browser zu sehen (Chrome/Edge installiert für inspect.mjs, Playwright, Chrome DevTools MCP, claude-in-chrome). Gehe nie von einem Stack aus: Wenn er nicht erkannt wird und gebaut werden muss, ist das eine Frage aus Schritt 1.

Schritt 1 · Arbeitsmodus

Erste Frage, immer, mit drei Optionen:

1. Projekt von Grund auf – es gibt nichts oder ein leeres/Boilerplate-Repository.
2. Auditieren / etwas Bestehendes neu gestalten – es gibt eine laufende Seite, App oder Website (URL oder Code).
3. Ein Abschnitt oder eine Komponente innerhalb von etwas, das bereits eine Identität hat (ein Hero, ein Checkout, eine Tabelle).

Der Modus bestimmt alles Weitere. Im Modus 3 wird keine neue Identität erfunden: Die des Projekts wird übernommen, und die Art Direction wird übersprungen; die Hausregeln und das finale Gate gelten trotzdem.

Schritt 2 · Discovery-Interview

Lies references/entrevista.md und folge dem Block des gewählten Modus. Allgemeine Regeln:

• Maximal drei Runden mit bis zu drei Fragen. Bevor du fragst, erkunde das Repository und das Briefing: Lasse nicht wiederholen, was bereits im Code, der README oder dem vorhandenen Copy zu lesen ist.
• Das Erste ist immer der Produkttyp (Landing Page / Unternehmenswebsite / Web-App oder Dashboard / E-Commerce / Portfolio / Docs), die Zielgruppe in ihrer Situation und die einzige Aktion, die die Seite erreichen muss. Danach der Stack, die bestehende Marke und – entscheidend – welche echten Bilder existieren (eigene Fotos, Produkt, Screenshots der Oberfläche, nichts).
• Frage nach Beispielseiten (2 bis 4 URLs oder Screenshots) und stelle klar, dass es optional ist: „Wenn du Seiten hast, die dir gefallen, schicke sie mir, ich analysiere sie; wenn nicht, schlage ich die Richtung vor.“ Frage auch nach dem Gegenteil: ein oder zwei Beispiele dessen, was er nicht möchte.
• Frage nicht nach Farben, Schriftarten oder „Stil“ im Abstrakten. Das ergibt sich aus dem Subjekt und den Referenzen, nicht aus einem Formular. Wenn der Nutzer sie vorgibt, respektiere sie und notiere sie als fest.
• Bei Audit zusätzlich: URL oder Befehl zum Starten des Projekts, was überleben muss (Routen, Formulare, Daten, SEO, Komponenten), und ob er eine Review (Bericht und nichts weiter), ein Restyle (gleiche Struktur, neue Haut) oder ein Redesign (die Komposition wird neu gemacht) möchte.
• Wenn der Nutzer sagt „mach, was du willst“, entscheide selbst, halte deine Lesarten im Briefing fest und fahre fort. Frage nur nach dem, was die Arbeit blockiert (z. B. kein Produktname).

Schritt 3 · Analyse der Beispielseiten (falls vorhanden)

Wenn der Nutzer Referenzen geschickt hat, lies references/analisis-referencias.md und folge dem vollständigen Protokoll: Du erfasst jede Seite bei 1440 und 390 px (mit inspect.mjs <url> von taste-skill falls vorhanden, was dir zusätzlich geladene Schriften, gemessene Größen und Farben liefert; falls nicht, mit Playwright, Chrome MCP oder WebFetch des HTML), betrachtest die Aufnahmen und füllst das Datenblatt für jede Seite aus. Das Ergebnis ist design/referencias.md mit:

• was die Referenzen gemeinsam haben (das ist das, was der Nutzer „gefällt mir“ nennt, ohne es benennen zu können: Schriftverhältnis, Farbmenge, Dichte, Bildtyp, Rhythmus),
• welche Muster es wert ist zu übernehmen (Kompositionen, Hierarchie, Conversion-Elemente),
• was zu dieser Seite gehört und nicht kopiert wird (dessen Logo, dessen Foto, dessen Satz, dessen exakte Palette).

Es werden Muster und Prinzipien extrahiert, niemals eine Seite geklont. Fasse die Analyse dem Nutzer danach in fünf Zeilen zusammen und bestätige, dass du seinen Geschmack richtig verstanden hast, bevor du weitermachst.

Ohne Referenzen wird dieser Schritt ersetzt durch die Richtung, die taste-skill vorgibt (Schritt 5) oder, falls nicht vorhanden, durch das --design-system von ui-ux-pro-max plus deine eigene Liste von sieben Richtungen.

Schritt 4 · Das Briefing

Mit dem Interview und den Referenzen schreibst du design/BRIEF.md gemäß references/brief-template.md. Es ist kurz (eine Seite) und enthält: Modus, Produkttyp, Zielgruppe, Hauptaktion, das Argument der Seite (eine Zeile pro Abschnitt: Aussage + Beweis), Inventar dessen, was nur dieses Subjekt hat (8 bis 12 Dinge: sein Name und was er bedeutet, seine Straße, seine Materialien, seine Zahlen, seine Einschränkung, seine Rituale), vorhandene echte Bilder, Stack, was feststeht (Marke, vorgegebene Schriften), Referenzen und ihre Muster, und was offen bleibt.

Zeige dem Nutzer das Briefing und bitte um ein OK (eine Zeile reicht). Wenn impeccable installiert ist, wird der Block „Produktwahrheit“ des Briefings auch an PRODUCT.md übergeben, via /impeccable init (oder du schreibst es selbst mit seiner Vorlage), damit seine anderen Befehle es lesen können.

Schritt 5 · Ausführung nach Modus

Die Reihenfolge der Skills und die genauen Befehle stehen in references/orquestacion.md. Zusammenfassung:

Modus 1 · Projekt von Grund auf

1. Produktwahrheit → impeccable init (PRODUCT.md). Ohne impeccable: der Abschnitt aus dem Briefing.
2. Basis-System nach Produkttyp → ui-ux-pro-max --design-system zur Orientierung über Muster, Ton, Anti-Patterns der Branche und Checkliste. Es ist ein Boden und eine Karte, nicht das Design.
3. Art Direction und Idee → taste-skill: Inventar, Argument, draw.mjs (drei Richtungen, wähle die, die etwas trägt, das nur dieser Kunde hat), der Satz der Idee, das „live thing“. Wenn es Referenzen gibt, fließt design/referencias.md in die Richtungswahl ein und kann ein --redraw mit Begründung rechtfertigen. Ohne taste-skill: die Liste von sieben Richtungen aus orquestacion.md und der manuelle Wurf.
4. Wörter vor Markup → vollständiges Copy-Deck (Überschriften maximal zwei Zeilen, echter und vollständiger Inhalt, niemals erfundene Testimonials: keine Testimonials, Logos oder falsche Metriken).
5. Bauen → Tokens → Hero → Abschnitte → echte Bilder (eigene > generierte > offene Archive mit Quellenangabe

   gezeichnete) → Zustände → Mobil als eigenständige Komposition. Für App/Dashboard-Bildschirme folge references/tipos-de-producto.md § Web-App und den App-Regeln von taste-skill.

6. Gate → lint.mjs + inspect.mjs bei 1440/768/390 mit 0 FAIL, oder Playwright + manuelle Checkliste.
7. Prüfen → Kritik an Screenshots mit den 14 Durchgängen und der Jury-Wertung (references/auditoria.md § Kritik). Behebe die drei größten Probleme, prüfe erneut. Maximal drei Runden.
8. Bewegung → erst jetzt die Motion-Ebene, mit prefers-reduced-motion.
9. Abschluss → impeccable audit + impeccable polish (oder die technische Rubrik aus auditoria.md), und der Bericht.

Modus 2 · Auditieren / neu gestalten

1. Vorher dokumentieren → Projekt starten, inspect.mjs <url> --out design/antes (mit --app bei App-Bildschirmen), lint.mjs, impeccable audit + impeccable critique, und Code lesen (Framework, Style-Methode, Komponenten, was nicht kaputtgehen darf).
2. Bericht → design/AUDITORIA.md mit der Rubrik aus references/auditoria.md: fünf technische Dimensionen (0-4), visuelle Kritik mit Wertung, Liste erkannter Tells, und die drei Dinge, die die größte Hebelwirkung hätten, geordnet nach Wirkung/Risiko.
3. Wenn der Nutzer nur eine Review wollte, hör hier auf und übergib den Bericht.
4. Restyle oder Redesign → Stack, Inhalt und das, was funktioniert, bleiben erhalten. Arbeitsreihenfolge: Typografie → Farbe → Rahmen (Abstände, Rhythmus, Titel, Überschrift pro Abschnitt) → Zustände → Austausch generischer Komponenten. Mit impeccable: typeset, colorize, layout, harden, adapt. Ein Redesign kehrt zu Modus 1 ab Schritt 3 zurück, mit dem echten Inhalt.
5. Testen → inspect.mjs --out design/despues, Vorher/Nachher-Vergleich bei jeder Breite, alles anklicken, was vorher funktioniert hat, und Metriken nebeneinander melden.

Modus 3 · Abschnitt oder Komponente

Tokens, Typografie und Komposition der Umgebung übernehmen. Keine neue Richtung. Bauen, das Gate auf der Seite durchlaufen, die die Komponente enthält, den Screenshot kritisieren. Wenn die Umgebung generisch ist und der Nutzer möchte, dass dies hervorsticht, sag ihm: Eine schöne Komponente auf einer hässlichen Seite fällt mehr auf, nicht weniger.

Hausregeln (gelten in allen Modi)

Konsolidiert aus den drei Skills; Details und Begründungen stehen in references/anti-slop.md.

• Überschriften maximal zwei Zeilen bei jeder Breite. Zuerst Wörter streichen, dann verbreitern, die Größe ganz zum Schluss.
• Klare Überschrift im ersten Bildschirm (ein h1) und eine Überschrift in jedem Abschnitt. Ein Fremder muss in fünf Sekunden wissen, was das ist und was zu tun ist.
• Keine Eyebrows (kleines Label über der Überschrift), keine dekorativen Nummerierungen (01/02/03), kein Monospace außerhalb von Code, kein tracked caps, kein einzelnes betontes Wort in der Überschrift (kursiv, Serife oder andere Farbe).
• Keine Farbverläufe, keine Schatten auf ruhigen Dingen, keine Glows, kein Glas, keine Blobs, keine Emojis als Icons, keine Karten mit Icon oben in Dreierreihe, keine dekorativen Haarlinien.
• Keine Assistenten-Palette: Creme + Terrakotta, Lila/Indigoblau, Schwarz + ein Neon. Wenn das Briefing sie vorgibt, wird sie respektiert; wenn die Achse frei ist, wird diese Freiheit nicht dort verschwendet.
• Ein Hintergrund, eine Tinte, ein Akzent. Fließtext in voller Tinte ab 16 px; Grau ist für sekundäre Notizen. Maximal zwei Schriftarten, normalerweise eine.
• Gleiche Ränder auf beiden Seiten, nichts „an eine Seite gedrückt“, keine leeren Abschnitte von mehr als einem halben Bildschirm. Benachbarte Abschnitte mit unterschiedlichen Kompositionen; keiner ist ein Raster von Karten.
• Echte Bilder: Minimum vier, idealerweise sechs bis zwölf. Eigene > generierte > offene Archive mit Quellenangabe > im Code gezeichnete. Ein grauer Platzhalter ist schlimmer als nichts.
• Das Entfernen von Ornamenten schafft Platz: Fülle ihn nicht mit einem anderen Ornament. Fülle ihn mit Maßstab, vollständigem Inhalt oder einem einfarbigen Feld.
• Barrierefreiheit nicht verhandelbar: Kontrast 4,5:1, sichtbarer Fokus, 44 px Targets, sichtbare Labels in Formularen, alt, Tastatur, prefers-reduced-motion.
• Es werden niemals Belege erfunden: weder Kunden, noch Bewertungen, noch Logos, noch Zahlen. Beispielinhalte sind erlaubt (Namen von Gerichten, Zimmern), aber im Bericht auflisten, damit sie bestätigt werden.

Wenn sich zwei Skills im visuellen Geschmack widersprechen: Bei Seiten (Landing, Marketing, Portfolio, E-Commerce) hat taste-skill das letzte Wort; bei App-Bildschirmen die App-Regeln von taste-skill plus die UX-Prioritäten von ui-ux-pro-max; im Technischen (Barrierefreiheit, Performance, Responsive, Theming) hat impeccable audit das letzte Wort. Das Briefing des Nutzers gewinnt gegen alle drei.

Abschlussbericht

Melde erst, wenn: der Inspector 0 FAIL bei den drei Breiten auf der finalen Version zeigt, du alle Screenshots nach der letzten Änderung geöffnet hast, jeder Abschnitt eine Überschrift hat, die Ränder stimmen und die Kritik der letzten Runde geschrieben ist. Danach kurz:

• Modus und Produkttyp; gewählte Richtung (Name und Seed, falls von taste-skill vergeben) und jedes --redraw mit Begründung;
• der Satz der Idee und das „live thing“;
• welche Referenzen analysiert wurden und welche Muster übernommen wurden;
• Wertung der letzten Kritik und was noch schwammig ist;
• alle gefundenen Bilder mit Titel, Autor, Lizenz und Quelle, und wo deren Quellenangabe steht;
• welche Bilder Zeichnungen oder generische sind und ersetzt werden müssen; welche Beispielinhalte bestätigt werden müssen; was noch nicht angeschlossen ist (Checkout, Formular, Analytik);
• bei Audit: Vorher/Nachher-Maße nebeneinander.

Behaupte keine Prüfung, die du nicht ausgeführt hast.

Dateien

Datei	Lies sie, wenn
references/entrevista.md	Schritt 2. Fragen nach Modus und Produkttyp, in der Reihenfolge, die die Arbeit am meisten verändert.
references/analisis-referencias.md	Schritt 3. Protokoll zur Erfassung, Datenblatt pro Seite, Extraktion von Mustern, was nicht kopiert werden darf.
references/brief-template.md	Schritt 4. Vorlage für design/BRIEF.md und deren Abbildung auf PRODUCT.md.
references/orquestacion.md	Schritt 5. Reihenfolge der drei Skills, genaue Befehle, Konfliktlösung und was zu tun ist ohne sie.
references/tipos-de-producto.md	Vor dem Bauen. Landing Page, Unternehmenswebsite, Web-App/Dashboard, E-Commerce, Portfolio: Struktur, Conversion, produktspezifische UX-Muster.
references/auditoria.md	Modus 2 und Schritt 7. Technische Rubrik (0-4 × 5), die 14 Kritikdurchgänge, die Jury-Wertung, die Caps, das Berichtsformat.
references/anti-slop.md	Wenn du zweifelst, ob etwas eine Entscheidung oder ein Default ist. Das Register der Tells und womit jeder ersetzt wird.