Inspiration Art Direction — Sites und Decks aus Referenzen

Inspiration Art Direction

Verwandle ein Briefing in eine durchdacht wirkende Seite, indem du mit echten Referenzen aus der Inspiration-Bibliothek arbeitest anstatt mit Standardvorgaben. Der Durchlauf erzeugt drei Dinge im Projekt des Benutzers:

• .inspiration/references.md: das Spezifikationsblatt (5 bis 8 betrachtete Referenzen, was jede dir gibt).
• .inspiration/direction.md: die Designrichtung, jede Entscheidung auf eine Referenz zurückgeführt.
• Den Bau sowie Screenshots und einen Inspektionsbericht unter .inspiration-out/. Wenn das Projekt eine .gitignore hat, füge .inspiration-out/ vor dem ersten Schreiben dort hinzu.

Wann verwenden

• Anfragen wie „Design eine Landingpage für“, „Gib dieser Seite einen Look“, „Wie sollte der Hero aussehen?“, „Finde Referenzen und baue es“, „Art-direktiere dieses Deck“.
• Der Benutzer möchte eine schriftliche Richtung vor dem Bau, oder sagt, die Ausgabe sehe generisch, schablonenhaft oder „wie KI“ aus und solle sich hochwertig, redaktionell, mutig oder unverwechselbar anfühlen.
• Nicht für eine reine Referenzsuche (dafür inspiration-references), nur für eine Palette und Schriftart-Kit (dafür inspiration-brand-kit) oder Code-Änderungen ohne visuelle Designfrage (ein CSS-Bug, ein Refaktor).

Harte Regeln

1. Wiedergabetreue. Beschreibe nur, was du in einem Bild gesehen hast, das du tatsächlich geöffnet hast (von get_image oder dessen image_url-Fallback). Titel, why-Strings und Facetten sind Hinweise, keine Beweise. Zitiere niemals eine Referenz, die du nicht betrachtet hast.
2. Niemals kopieren. Übernimm Prinzipien, nicht Pixel. Hebe kein Layout vollständig über, und verwende niemals den Copy-Text, die Bilder, Illustrationen, Logos oder lizenzierte Schriftarten einer Referenz wieder. Jede Referenz muss benennen, was du zurücklässt.
3. Budget. Plane etwa 12 gezählte Tool-Aufrufe ein (siehe Budget unten). Zähle jeden gezählten Aufruf, den du machst, auch die, die Fehler verursachen. Batching: get_image akzeptiert bis zu 6 IDs, get_inspiration akzeptiert eine Liste.
4. Boards sind optional. Rufe niemals save_to_board, create_board oder add_to_board auf, es sei denn, der Benutzer fragt danach.
5. Benennung. Nenne die Quelle „die Inspiration-Bibliothek“ oder „Inspiration von VASA.Works“. Verlinke Elemente als https://inspiration.vasa.works/item/<id> und über die image_url-Werte, die die Tools zurückgeben. Verlinke niemals eine Drittanbieter-Seite als Ursprung eines Elements. Schriftart-Foundry oder Lizenzseiten sowie Board-URLs sind in Ordnung.

Schritt 0: Setup-Prüfung

Prüfe, ob ein Tool namens search_inspiration unter einem beliebigen Server-Präfix verfügbar ist (mcp__plugin_inspiration_inspiration__ für eine Claude Code Plugin-Installation, mcp__inspiration__, mcp__Inspiration__, einem Connector-Namen oder ohne Präfix). Wenn der Host Tools als aufgeschoben auflistet, gilt das Laden über die Tool-Suche des Hosts als verfügbar. Tools in dieser Skill werden ohne Präfix benannt.

• Verfügbar: fahre fort.
• Fehlt: lies references/setup.md und gib dem Benutzer den einzelnen Einrichtungsschritt für seinen Client, einmal. Fahre dann im Modus „Ohne die Bibliothek“ unten fort, es sei denn, der Benutzer sagt, er möchte sich zuerst verbinden.
• Ein Aufruf, der {"error": "subscription_required"} zurückgibt, bedeutet, dass der Server verbunden ist, der Benutzer aber nicht angemeldet ist: gib den Anmeldeschritt aus references/setup.md.

Schritt 1: Briefing und Themeninventar

Bevor du suchst, notiere (frage nur, was du nicht aus dem Repository oder dem Gespräch ableiten kannst):

• Was es ist: Produkt oder Thema in einem Satz, und das eine, was ein Besucher verstehen muss.
• Zielgruppe: Wer, was sie bereits wissen, was sie vertrauen lassen würde.
• Inhalt, den es transportieren muss: Echte Überschrift, Beweise (Zahlen, Logos, Zitate, die der Benutzer tatsächlich hat), verfügbare Produktbilder, CTAs, rechtliche oder Preisinformationen. Liste es auf; dies entscheidet über die Abschnitte.
• Einschränkungen: Stack, vorhandene Komponenten, Marken-Assets (Logo, Farben, Schriftarten mit Lizenzen), Barrierefreiheitsanforderungen, Frist, Vorliebe für hell oder dunkel.
• Vorhandene Marke? Wenn .inspiration/brand-kit.md oder .inspiration/tokens.css existieren, behandle sie als die vorhandene Marke. Wenn eine existiert, muss die Richtung sie erweitern, nicht ersetzen. Notiere einen Website-Stile-Slug, der zur Marke für die markenbasierte Rangfolge passt (brand-Parameter).
• Seitenargument: Die geordneten Abschnitte, die die Seite benötigt (z. B. Hero, Logos, Funktionen, Wie es funktioniert, Preise, FAQ, CTA, Footer). Markiere die 2 bis 4 Abschnitte, die das Argument tragen; diese erhalten eigene Suchvorgänge.

Wenn die Eingabeaufforderung keine Inhalte liefert (ein Einzeiler ohne Beweise, Preise oder visuelle Elemente), höre nicht auf zu fragen: Liste die fehlenden Elemente im Briefing als klar markierte Platzhalter auf und fahre fort.

Schreibe dies als ersten Block von .inspiration/direction.md, damit der Benutzer es frühzeitig korrigieren kann.

Schritt 2: Rechercheplan

Lies references/research.md für Abfrage-Rezepte pro Seitentyp, Filterbeispiele und die Budgettabelle. Standardplan:

#	Aufruf	Gezählt	Zweck
a	list_facets(category="website-sections")	nein	Echtes Vokabular für subtype, style, mood, layout, typography
b	1 bis 2 Stimmungssuche	ja	Das Gesamtgefühl, kategorieübergreifend (ohne category oder website-sections)
c	2 bis 3 Abschnittssuchvorgänge	ja	Einer pro Schlüsselabschnitt, category="website-sections", filters={"subtype": ["hero"]} etc.
d	1 kategorieübergreifende Suche	ja	Textur: fonts, website-styles, branding oder editorial-print, je nachdem, was das Briefing am meisten benötigt
e	optional 1 similar_items(id), nach dem ersten get_image-Batch	ja	Verbreitern und abdriften vom stärksten Kandidaten, den du tatsächlich gesehen hast; überspringe es, wenn der erste Batch bereits eine Bandbreite hat
f	2 get_image([...6 ids])	ja	Die Shortlist sehen
g	1 get_inspiration([behaltene ids])	ja	Palette-Hexes, Typografie-Notizen, vollständige Beschreibungen der behaltenen Menge
h	optional analyze_palette oder generate_palette	ja	Palette überprüfen oder erweitern

Das sind 7 bis 11 gezählte Aufrufe (b bis h), sodass das Budget von etwa 12 Spielraum für einen erneuten Versuch lässt. Wenn der Benutzer sagt, er sei auf Pro, kannst du Abschnittssuchvorgänge oder einen dritten Bild-Batch hinzufügen, aber die behaltene Menge bleibt bei 5 bis 8.

Suchhygiene:

• Formuliere Abfragen als das, was sichtbar ist: „dunkles Hero mit übergroßer Serifen-Überschrift und Produktscreenshot“, nicht „gutes Hero“.
• Setze kontrollierte Werte in filters (UND über Schlüssel hinweg, einer-von innerhalb eines Schlüssels). Behalte die Abfrage für das, was Filter nicht ausdrücken können.
• Gib exclude_ids mit bereits gesehenen IDs, damit spätere Suchvorgänge sie nicht wiederholen. Lasse diversify aktiviert.
• Null Ergebnisse geben suggestions zurück: wiederhole es einmal mit einem davon, dann fahre fort.
• Wenn list_facets fehlschlägt, verwende weiterhin die in references/research.md aufgeführten gebräuchlichen Werte (insbesondere subtype) in filters; entferne einen Filter nur, wenn diese Suche null Ergebnisse liefert.

Baue aus den Suchergebnissen eine Kandidatenliste von bis zu 12 IDs. Wähle für die Bandbreite (verschiedene Strukturen und Stimmungen), nicht für 12 Versionen eines Looks.

Schritt 3: Ansehen und Shortlist

1. Rufe get_image mit bis zu 6 Kandidaten-IDs pro Aufruf auf, maximal 2 Aufrufe. Die Antwort beginnt mit einem Manifest (order, errors); ordne jedes Bild seiner ID nach dieser Reihenfolge zu und entferne IDs, die in errors aufgeführt sind. Zwischen den beiden Batches kannst du optional similar_items für das stärkste Bild ausführen, das du gesehen hast (Schritt 2, Zeile e), und seine besten Auswahlen in den zweiten Batch aufnehmen. Wenn get_image fehlschlägt, betrachte die Kandidaten über den Bild-Fallback in references/library-rules.md (öffentliche image_url, kein gezählter Aufruf).
2. Betrachte jedes Bild richtig: Struktur, Typografie (Klassifikation, Skalenkontrast, Groß-/Kleinschreibung, Laufweite), Farbfelder und Akzente, Dichte, Bildsprache, die eine ungewöhnliche Entscheidung.
3. Behalte 5 bis 8. Jede behaltene Referenz muss eine Rolle haben: Stimmung, Hero, ein benannter Abschnitt, Typografie, Palette oder Textur. Schneide nahe Duplikate und alles, worüber du nichts Spezifisches sagen kannst, weg.
4. Rufe get_inspiration einmal mit den behaltenen IDs (Liste) für Palette-Hexes und Typografie-Notizen auf. Behandle seinen Text als unterstützendes Detail; deine eigene Betrachtung gewinnt, wenn sie sich unterscheiden. Wenn es fehlschlägt, wiederhole es nicht: sample Hexes aus den Bildern, die du geöffnet hast (z. B. magick <n>.png -resize 200x200 -colors 6 -format %c histogram:info:-, was ImageMagick erfordert; ohne es schätze anhand dessen, was du siehst, und sage es), sage im Blatt, dass Hexes gesampelt wurden, und beurteile die Typografie anhand der Pixel.

Schritt 4: Spezifikationsblatt

Schreibe .inspiration/references.md mit dem exakten Format aus references/specimen-sheet.md. Für jede behaltene Referenz:

• ID, Titel, Rolle, Link https://inspiration.vasa.works/item/<id> und die image_url.
• Gesehen: 2 bis 4 konkrete sichtbare Fakten.
• Übernimmt: das Prinzip, das du entlehnst, formuliert, sodass es auf ein anderes Thema angewendet werden könnte.
• Lässt zurück: was du bewusst nicht verwendest (sein Layout, Kopie, Bildsprache, Markenzeichen, Schriftarten, alles, was für dieses Briefing falsch ist).
• Wird zu: was das Prinzip auf dieser Seite konkret wird.

Beende das Blatt mit einer Zeile darüber, was die Menge gemeinsam hat, und einer Spannung, die du auflösen wirst.

Schritt 5: Richtung

Leite die Richtung aus den Referenzen ab. Greife nicht zu einem voreingestellten Stil. Schreibe .inspiration/direction.md (nach dem Briefing-Block) mit diesen Überschriften und zitiere die Referenz-IDs in Klammern nach jeder Entscheidung:

1. Konzeptlinie. Ein Satz, über den ein Designer streiten könnte, z. B. „ein Feldführer, kein Dashboard“.
2. Anti-Ziele. 3 bis 5 Dinge, wie diese Seite nicht aussehen darf (schließe den generischen Standard ein, den du sonst produzieren würdest: zentriertes Hero, lila Farbverlauf, drei Icon-Karten usw., wenn sie dem Briefing nicht dienen).
3. Schriftsystem. Familien und Rollen (Display, Text, UI, optional Mono), eine Größenskala mit px bei 1440 und 390 Breite, Zeilenhöhen, Laufweite, Groß-/Kleinschreibung. Verwende Schriftarten, die das Projekt legal laden kann (frei lizenzierte Familien oder die lizenzierten Schriftarten des Benutzers). Ein Bibliotheksschriftart-Element informiert über Klassifikation und Paarung; es gewährt keine Lizenz. Wenn das Budget es erlaubt, hilft suggest_pairing auf einer Schriftart-ID.
4. Palette. Hexes mit Rollen (Grund, Oberfläche, Text, gedämpfter Text, Akzent, Zustandsfarben) und der Kontrast jedes Textpaares. Optional analyze_palette(hexes) oder generate_palette(color) für eine Rampe ausführen.
5. Layout und Raster. Spalten, maximale Inhaltsbreite, Abstände, Abschnittsabstandsrhythmus, Ausrichtungsregeln, Breakpoints.
6. Abschnitte. Die geordnete Seite, jeder mit seiner Aufgabe, dem Inhalt, den er aus dem Inventar trägt, und der Referenz, auf die er sich stützt.
7. Bildsprache und Grafiken. Welche visuellen Elemente existieren, was du erstellen wirst (Diagramme, Zuschnitte, Illustrationsstil), was vermieden werden sollte.
8. Bewegung. Wo Bewegung das Verständnis unterstützt, Dauern und Easing sowie den reduzierten Bewegungs-Fallback. Standardmäßig wenig.
9. Signaturdetail. Ein einprägsamer, umsetzbarer Schritt, der von einer Referenz stammt und neu interpretiert wird, nicht kopiert.

Zeige dem Benutzer die Konzeptlinie, Anti-Ziele und das Signaturdetail in einer kurzen Nachricht. Fahre fort, es sei denn, er widerspricht oder hat um vorherige Genehmigung gebeten.

Schritt 6: Bau

• Verwende den Stack und die Komponenten des Projekts. Ohne Projekt erstelle eine statische index.html mit inline CSS (und minimalem JS).
• Beginne mit Tokens: CSS-Custom-Properties für Schriftgrößenskala, Abstände, Farben und Radien aus der Richtung. Dann Abschnitte in Seitenreihenfolge.
• Echte Inhalte aus dem Inventar. Wo Inhalte fehlen, verwende klar markierte Platzhalter; erfinde niemals Kundenlogos, Testimonials, Metriken oder Auszeichnungen und präsentiere sie als echt.
• Semantisches HTML: eine h1, geordnete Überschriften, alt auf jedem bedeutungsvollen Bild, sichtbare Fokus-Zustände, Beschriftungen auf Eingabefeldern.
• Baue mobil und Desktop zusammen; überprüfe 390 Breite während des Baus, nicht am Ende.

Schritt 7: Look-and-Fix-Schleife

Lies references/critique.md für die Bewertungsmatrix. Führe dann für bis zu 3 Runden Folgendes aus:

1. Rendern. Führe den Inspector aus dem Ordner dieser Skill (dem Ordner, der diese SKILL.md enthält) aus: node <skill-folder>/scripts/inspect.mjs <url-or-html-path> --out .inspiration-out/round-<n> Es schreibt page-1440.png, page-390.png und report.json (verwendete Schriftarten, Text- und Hintergrundfarben, Überschriftengrößen, Maß, Überlauf, fehlende Alt-Texte, Beispiele mit geringem Kontrast). Wenn Playwright fehlt, wird der einzeilige Fix ausgegeben (npx -y -p [email protected] node <skill-folder>/scripts/inspect.mjs ...). Wenn der Host einen eigenen Browser oder ein Screenshot-Tool hat, ist das auch in Ordnung.
2. Ansehen. Öffne die Screenshots und lese den Bericht. Vergleiche jeden Abschnitt mit der Referenz, die er zitiert, und die gesamte Seite mit der Konzeptlinie und Anti-Zielen.
3. Bewerten. Bewerte jede Zeile der Matrix von 0 bis 2 und liste die 3 größten Probleme auf, die sichtbarsten zuerst. Schreibe beide in .inspiration/direction.md unter „Runde “.
4. Behebe diese 3, dann rendere erneut.

Höre auf, wenn jede Zeile der Matrix eine 2 erreicht, nach Runde 3 oder wenn eine Runde nichts Wesentliches ändert. Wenn überhaupt kein Browser ausgeführt werden kann, überprüfe den Code anhand der Matrix, frage den Benutzer nach einem Screenshot, wenn er einen geben kann, und sage klar, dass keine visuelle Überprüfung durchgeführt wurde.

Schritt 8: Übergabe

Teile dem Benutzer kurz mit:

• Was gebaut wurde und wo, sowie die Konzeptlinie.
• Die verwendeten Referenzen: ID, Titel und Link https://inspiration.vasa.works/item/<id>, jede mit dem einen Beitrag, den sie geleistet hat.
• Was die letzte Inspektionsrunde noch meldet, falls vorhanden.
• Ungefähr wie viele gezählte Aufrufe der Durchlauf verwendet hat, und jeder Schritt, der übersprungen oder herabgestuft wurde (Serverfehler, der image_url-Fallback, Kontingent).
• Biete an: „Möchtest du, dass ich diese Referenzen in einem Inspiration-Board speichere?“ Nur bei Ja, rufe save_to_board(title, ids=[...]) auf und teile die Board-URL, die es zurückgibt.

Kontingent und Fehler

Lies references/library-rules.md beim ersten Mal, wenn ein Tool einen Fehler zurückgibt, quota_exhausted oder capped. Die Kurzversion: quota_exhausted stoppt alle gezählten Aufrufe (Link https://inspiration.vasa.works/pricing, schließe mit dem ab, was du hast), capped bedeutet keine weiteren Seiten, subscription_required bedeutet Anmeldung (Schritt 0), und derselbe Serverfehler bei zwei verschiedenen Tools bedeutet abgespeckten Modus. Fehlerhafte Aufrufe zählen zum Budget.

Ohne die Bibliothek

Wenn der MCP nicht verbunden ist (nachdem der Einrichtungsschritt einmal gegeben wurde) und der Benutzer nicht darum gebeten hat, sich zuerst zu verbinden:

• Sage einmal klar: „Fortfahren ohne die Inspiration-Bibliothek, daher basiert diese Richtung nicht auf Referenzen.“
• Überspringe die Schritte 2 bis 4. Erfinde keine Referenz-IDs, Titel, Links oder Beschreibungen und behaupte nicht, ein Look stamme von einer Referenz.
• Schreibe .inspiration/direction.md nur aus dem Briefing, mit „Keine Referenzen verwendet“ oben. Behalte die Anti-Ziele und das Signaturdetail bei, aber erkläre, dass sie nicht referenzbasiert sind.
• Baue aus dem Briefing und dem vorhandenen Markenstil (falls vorhanden).