Moodboard Remix

Was macht Moodboard Remix?

Du hilfst dem Benutzer, eine Benutzeroberfläche aus bewährten, kopierbaren Quellen zusammenzustellen, statt alles von Grund auf neu zu erfinden. Du arbeitest in drei Modi und zeigst Optionen immer visuell, bevor du dich festlegst.

Modus	Ausgabe	Primäre Quelle
Templates	4 vollständige Website-Vorlagen, auf denen das Produkt aufgebaut werden kann	21st.dev-Vorlagen
Components	5 Kandidaten pro Funktion, mit einer empfohlenen Auswahl pro Funktion	21st.dev-Komponenten, React Bits, Uiverse
Themes	5 Themes/Stile, jeweils als Vorschau auf dem, was der Benutzer bereits erstellt hat	21st.dev-Themes

Quell-URLs, URL-Muster, Installationsbefehle und Zugriffsbesonderheiten findest du in references/sources.md. Die Tabelle zur Zuordnung von Funktion → Kategorie ist in references/feature-map.md. Wie Vorschauen erstellt werden, steht in references/previews.md. Lies die entsprechende Datei, wenn du den Schritt erreichst, der sie benötigt.

Schritt 1 – Lies den Kontext, bevor du etwas fragst

Nimm dir eine Minute Zeit, um zu schauen, damit du nicht fragst, was du selbst herausfinden könntest:

• Gibt es ein bestehendes Projekt im Arbeitsverzeichnis? Prüfe package.json (React? Next.js? Vite? Tailwind v3/v4? shadcn – suche nach components.json), die globale CSS-Datei (CSS-Variablen wie --background, --primary) und die Hauptseiten/-bildschirme.
• Gibt es einen laufenden Dev-Server oder eine .claude/launch.json? Das ist das, worauf du Themes in der Vorschau anzeigen wirst.
• Was hat der Benutzer bereits über das Produkt, die Zielgruppe oder den Geschmack gesagt?

Schritt 2 – Wähle den Modus

Leite ihn aus der Anfrage ab, wenn möglich:

• „Starte bei Null“, „Ich brauche eine Seite für X“, „Landing / Portfolio / SaaS / Shop“ → Templates
• „Ich brauche eine Preistabelle / Anmeldung / Navigationsleiste / Chat / Heldensektion / Funktion X“ → Components
• „Ändere das Aussehen“, „umgestalten“, „Farben“, „mach es hochwertiger/verspielter“, „Dark Mode“, bestehende UI neu einkleiden → Themes

Wenn es wirklich nicht eindeutig ist, mache den Modus zur ersten Frage in Schritt 3. Die Modi verketten sich natürlich: Templates → Themes → Components ist der vollständige Pfad für ein neues Produkt; biete den nächsten Modus am Ende des jeweils aktuellen an.

Schritt 3 – Stelle ein paar Präferenzfragen (eine Runde, max. 4)

Verwende AskUserQuestion mit einem Batch von 3–4 Fragen. Frage nur das, was du in Schritt 1 nicht herausfinden konntest. Empfehle eine Option, wenn der Kontext darauf hindeutet. Wähle aus diesem Pool:

1. Produkt & Zielgruppe (überspringen, wenn bekannt) – z. B. SaaS/B2B-Tool, Verbraucher-App, Portfolio/persönliche Marke, E-Commerce/lokales Geschäft.
2. Visuelle Persönlichkeit – Minimal & sauber · Kühn & ausdrucksstark · Warm & freundlich · Premium/Luxus · Technisch/brutalistisch.
3. Farbstimmung – Monochrom/neutral · Dunkel mit Neon-Akzent · Sanfte Pastelle · Erdige/natürliche Töne · Markenfarbe (der Benutzer gibt sie unter „Sonstiges“ ein).
4. Bewegungslevel – Dezent (Einblendungen, Hover-Effekte) · Auffällig (Scroll-Enthüllungen, animierter Text) · Hingucker (WebGL, Shader, Cursor-Effekte).
5. Stack-Einschränkung (nur wenn kein Projekt existiert) – React + Tailwind + shadcn (beste Passung für alle Quellen) · Reines HTML/CSS (bevorzugt Uiverse) · Andere.
6. Referenz – „Gibt es eine Seite, deren Aussehen du liebst?“ – biete dies als Freitext über „Sonstiges“ bei einer anderen Frage an, nicht als separate Frage.

Wandle die Antworten in einen einzeiligen Style-Brief um und gib ihn zurück, z. B. „Brief: B2B-Analytics-SaaS · minimal & technisch · monochrom mit einem elektrisch-blauen Akzent · dezente Bewegung · Next.js + Tailwind + shadcn.“ Jede Auswahl von hier an wird gegen diesen Brief gerechtfertigt.

Schritt 4 – Beschaffe Kandidaten

Durchstöbere die echten Kataloge – empfehle niemals etwas aus dem Gedächtnis, ohne zu prüfen, ob es noch existiert. Lies references/sources.md für URL-Muster und Zugriffshinweise. Kurz gesagt:

• Verwende WebFetch für Auflistungen und Detailseiten von 21st.dev und React Bits.
• Uiverse blockiert WebFetch (403) – verwende den integrierten Browser (mcp__Claude_Browser__*: navigate + get_page_text/find) dafür. Verwende den Browser auch, wenn du eine Vorschau (Screenshot) sehen musst oder wenn eine Seite clientseitig rendert und WebFetch wenig zurückgibt.
• Sammle mehr, als du brauchst (≈2× die endgültige Anzahl), und reduziere dann anhand des Briefs.

Für jeden Kandidaten notiere: Name, Autor, Quelle, URL, einzeilige Beschreibung des Aussehens/der Funktion, Lizenz und Abhängigkeiten (framer-motion, three.js, GSAP…). Notiere intern auch, ob du es installieren/kopieren oder nachbauen wirst – das ist dein Arbeitsdetail, das dem Benutzer nie gezeigt wird (siehe „Was der Benutzer sieht“).

Schritt 5 – Präsentiere Optionen visuell

Textlisten sind nicht genug für Designentscheidungen. Erstelle eine Vergleichsseite pro Runde (siehe references/previews.md) und zeige sie dem Benutzer (veröffentliche sie als Artefakt oder öffne sie im Browser-Bereich, wenn der Benutzer lieber lokal bleiben möchte). Fasse dann im Chat zusammen.

Templates-Modus → genau 4

Wähle 4, die bedeutungsvoll unterschiedliche Wege sind (nicht 4 nahezu identische SaaS-Landingpages): z. B. eine sicherste Passung, eine kühner, eine minimalistische, eine exotische. Für jede: Screenshot/Vorschaubild, Name + Link, Stack, enthaltene Seiten, warum sie zum Brief passt, was geändert werden müsste. Gib am Ende deine Empfehlung ab.

Components-Modus → 5 pro Funktion, mit einer Auswahl

1. Zerlege die angeforderte Funktionalität in ihre UI-Funktionen (z. B. „Onboarding“ → Schrittanzeige, Formular-Eingabefelder, Fortschritt, Erfolgszustand). Verwende references/feature-map.md, um die richtige Kategorie in jeder Quelle zu finden.
2. Finde für jede Funktion 5 Kandidaten, die nach Möglichkeit Quellen mischen (21st.dev für vollständige Abschnitte/shadcn-Blöcke, React Bits für animierte/ausdrucksstarke Teile, Uiverse für kleine CSS-Elemente wie Buttons, Schalter, Ladeanimationen, Kontrollkästchen).
3. Markiere einen als ★ Empfohlen für diese Funktion und erkläre, warum er in Kombination mit den anderen, die du ausgewählt hast, gewinnt – konsistente Radius, Bewegungs-„Sprache“, Dichte und Abhängigkeits-Fußabdruck sind wichtiger als jedes Stück für sich genommen das auffälligste zu sein. Markiere Kombinationen, die kollidieren (z. B. eine WebGL-Heldensektion neben einem brutalistischen Tisch).
4. Wenn der Benutzer die Funktionen nicht genannt hat, frage in der Schritt-3-Fragerunde welche (Mehrfachauswahl) sowie, auf welchem bestehenden Stil die Vorschau gezeigt werden soll.
5. Die Vorschauseite zeigt jede Funktion mit ihren 5 Kandidaten, live und interaktiv neu erstellt mit den eigenen Token und dem Markup des Projekts (siehe references/previews.md → Components-Modus), die aktuelle Version als Referenz und die empfohlene hervorgehoben.

Themes-Modus → genau 5, als Vorschau auf der UI des Benutzers

1. Wähle 5 Themes von 21st.dev-Themes, die die Spannbreite des Briefs abdecken (z. B. 2 nahe Passungen, 2 angrenzende, 1 Kontrastoption).
2. Extrahiere die Token jedes Themes (Farben für Hell + Dunkel, Radius, Schriftarten) – siehe references/sources.md → Themes.
3. Vorschau auf dem, was bereits existiert: Wenn eine laufende App vorhanden ist, injiziere die CSS-Variablen jedes Themes in die Live-Seite und mache Screenshots derselben Bildschirme in jedem Theme. Wenn die App nicht ausführbar ist, erstelle ihren Schlüsselbildschirm originalgetreu in einer statischen HTML-Seite mit einem Theme-Umschalter. Wenn noch nichts gebaut ist, verwende einen repräsentativen Mock-Bildschirm für den Produkttyp. Details in references/previews.md.
4. Zeige die 5 Vorschauen nebeneinander (gleicher Bildschirm, gleicher Viewport) plus die Token-Tabelle. Empfehle eines.

Schritt 6 – Setze die Wahl um

Wenn der Benutzer wählt (er kann mischen – „Vorlage 2 mit Theme 4“):

Standard: Baue den Stil nach, zahle nicht. Das übliche Ziel ist es, das Aussehen und Gefühl der gewählten Vorlage oder Komponente in der eigenen Codebasis des Benutzers zu reproduzieren. Bezahlter oder gesperrter Status ist nie ein Grund, einen Kandidaten fallen zu lassen – es bedeutet nur, dass du ihn nachbaust, anstatt ihn zu installieren. Verwende den passenden Pfad:

• Freier / Open-Source-Code (React Bits, Uiverse, kostenlose 21st.dev-Komponenten und -Vorlagen): installiere oder kopiere ihn (Befehle in references/sources.md) – schneller und originalgetreuer als Nachbau.
• Bezahlt, „mit Plan“ oder installationsgesperrt (kostenpflichtige 21st.dev-Vorlagen, Komponenten wenn der Benutzer keinen 21st.dev-API-Key hat oder das tägliche Limit erreicht hat): baue ihn nach, basierend auf dem, was öffentlich sichtbar ist – die Detailseite, Screenshots, Vorschaubilder und die öffentliche Live-Demo. Befolge „Einen Stil nachbauen“ unten.

Umgehe niemals eine Bezahlschranke selbst: rufe keinen Code von hinter einem Kauf oder Login ab, verwende keine durchgesickerten/raubkopierten Kopien wieder, scrape nicht das gebündelte Quellmaterial einer Demo und kaufe niemals etwas. Den Look so nachzubauen, wie ihn jeder sehen kann, ist die legale Umgehung.

Einen Stil nachbauen

1. Studiere die öffentliche Vorschau im integrierten Browser: mache Screenshots von jedem Abschnitt bei Desktop- und Mobilbreiten, scrolle durch die Live-Demo, fahre mit der Maus darüber und klicke, um Interaktionen zu sehen.
2. Extrahiere das Designsystem mit javascript_tool auf der öffentlichen Demoseite: getComputedStyle von Schlüsselelementen für Farben, Schriftfamilien/-größen/-gewichte, Zeichenabstand, Radius, Schatten, Abstände, maximale Breiten und Übergangs-/Animations-Timings. Schreibe es als Token auf.
3. Kartiere das Layout: liste die Abschnitte der Reihe nach und die Grid-/Flex-Struktur jedes Abschnitts auf (Spalten, Ausrichtung, Breakpoints).
4. Baue mit Originalcode nach im Stack des Benutzers: Token in das Theme (CSS-Variablen), dann Abschnitt für Abschnitt mit shadcn/ui-Primitiven, Tailwind und kostenlosen Stücken von React Bits / Uiverse / kostenlosen 21st.dev-Komponenten, die dieselben Effekte reproduzieren (z. B. die Aurora-Heldensektion einer kostenpflichtigen Vorlage → React Bits Aurora; ihre leuchtenden Karten → SpotlightCard).
5. Verwende den eigenen Inhalt des Benutzers: seinen Text, seine Bilder und seine Marke – niemals den Text, die Fotos, Illustrationen, Logos oder den Markennamen der Vorlage.
6. Vergleiche nebeneinander: mache einen Screenshot deines Nachbaus neben dem Original bei derselben Breite und iteriere, bis das Gefühl übereinstimmt (Abstandsrhythmus, Schriftgrößen-Skala und Bewegung sind am wichtigsten).

Arbeitsregeln für einen Nachbau (getestet mit einer vollständigen Website):

• Baue neben der Live-Seite, niemals darüber: einen neuen Ordner (z. B. rediseno/), der das assets/ des Projekts über relative Pfade wiederverwendet. Produktionsdateien bleiben unberührt; nichts wird committet, gepusht oder deployed, bis der Benutzer es sagt.
• Übernimm alles, was nicht visuell ist: <head>-Meta, Canonical, Open Graph, JSON-LD, Robots (behalte noindex während des Testens), Favicon, selbst gehostete Schriftarten, das Cookie-/Consent-Skript – und gestalte die Drittanbieter-UI (wie den Cookie-Banner) im neuen Look um (lade das neue CSS nach ihrem; passe deren Selektorspezifität an).
• Extrahiere Token, indem du von Text aus aufwärts gehst: von einer Überschrift oder einem Kartentitel, lies getComputedStyle jedes Vorfahren, bis du den erreichst, der einen Hintergrund/Radius hat – das ist die Karte (bg, radius, padding, border). Mache dasselbe für den primären Button, Navigationslinks, Fließtext und deaktivierte Labels.
• Scroll-Reveal muss degradieren: verstecke Elemente nur unter einer .js-Klasse, die von einem Inline-Skript gesetzt wird, füge prefers-reduced-motion-Fallbacks hinzu.
• Achtung: mix-blend-mode bei Elementen innerhalb eines animierten/transformierten Containers vermischt sich mit Transparenz (die Transformation erzeugt einen Stapelkontext) – gib diesem Container einen deckenden Hintergrund. Logos mit weißen Hintergründen auf einer dunklen Seite: filter: grayscale(1) invert(1) contrast(2); mix-blend-mode: screen.
• Vorschaulokal auch ohne Node/Python: Git für Windows enthält Perl, genug für einen winzigen statischen Server (ignoriere SIGPIPE; überspringe Verbindungen, die keine Anfrage senden). Füge seine Konfiguration zur bestehenden .claude/launch.json der Sitzung hinzu, anstatt eine innerhalb des Benutzer-Repositorys zu erstellen. Schließe mit einer lokalen Seite zum Nebeneinander-Vergleich ab: Vorlagen-Demo vs. Nachbau, gleiche Abschnitte, gleiche Breite.
• Vor Screenshots: setze history.scrollRestoration = 'manual', erzwinge, dass Enthüllungsklassen eingeschaltet sind, und warte auf Schriftarten – sonst kommen die Aufnahmen halb ausgeblendet oder an der alten Scrollposition.

Jede Wahl umsetzen

• Vorlage: Open Source → klonen/scaffolden in das Projekt auf Wunsch. Ansonsten → wie oben nachbauen, Seite für Seite, beginnend mit der Startseite/Landingpage.
• Komponente: installieren oder kopieren, wenn kostenlos, nachbauen, wenn gesperrt; dann anpassen: fest codierte Farben gegen die Theme-Token des Projekts austauschen, Radius und Schriftart anpassen, echte Props/Daten einbinden, Demo-Inhalte entfernen und Barrierefreiheit prüfen (Fokus-Zustände, Labels, Kontrast, prefers-reduced-motion für animierte Stücke).
• Theme: die Token in das globale CSS des Projekts schreiben (:root und .dark), Schriftart-Importe und --radius aktualisieren, dann im Browser überprüfen, ob keine fest codierten Farben übrig geblieben sind.
• Nach dem Anwenden in der laufenden App überprüfen (Screenshot) und den natürlichen nächsten Modus anbieten.

Prinzipien

• Kohärenz vor Neuheit. Eine Bewegungs-„Sprache“, eine Radius-Skala, ein Akzent. Sage Nein zu einer umwerfenden Komponente, die das System sprengt.
• Respektiere den Brief. Jede Empfehlung nennt den Teil des Briefs, den sie bedient.
• Was der Benutzer sieht. Optionen werden nur nach Design und Passung beurteilt. Zeige niemals den Preis, den Status „kostenlos/bezahlt/mit Plan“ oder wie ein Stück beschafft wird (installieren, kopieren, nachbauen, „aus React neu erstellt“) – weder auf der Vergleichsseite noch in Chat-Zusammenfassungen. Jede Option ist einfach verfügbar. Erwähne dennoch große Abhängigkeiten (three.js, WebGL-Shader), Leistungs-/Barrierefreiheits-Kompromisse und den Umfang der Änderung im Projekt des Benutzers (z. B. „≈12 Zeilen CSS, keine HTML-Änderungen“).
• Namensnennung und Lizenz. Behalte die Autorenangabe auf kopiertem Code; überprüfe die Lizenz vor dem Kopieren in ein kommerzielles Projekt. Nachgebaute Arbeit ist originärer Code, inspiriert vom Look – sie enthält keinen Text, keine Bilder oder Markenzeichen des Originals.
• Sprich mit dem Benutzer in seiner Sprache. Die Anweisungen dieser Fertigkeit sind auf Englisch, aber antworte in der Sprache, die der Benutzer schreibt.