senlindesign/taste-skill

Anleitung zur Installation und Nutzung des Taste-Skills für die Designanalyse einer Website.

Taste – Reverse-Engineer das Design-DNA einer Website

Dieses Skill verwandelt eine URL in zwei Dateien:

• ./{domain}.md – menschenlesbar. Zwei Abschnitte:
  • Design Map – praktische Tokens (Farben, Schriftskala, Abstände, Radien, Schatten, Raster)
  • Geschmacks-DNA – 3–4 meinungsstarke Trade-offs (Auslöser → Entscheidung → Grund → Beleg)
• ./{domain}.json – strukturiert. Gleiche Daten, maschinenlesbar, für nachgelagerte Tools (Cursor, Windsurf, Designsysteme).

Die Pipeline lehnt allgemeine Beschreibungen wie „sauber und modern“ ab. Eine fertige taste.md sollte sich anfühlen, als würde ein Senior-Designer erklären, warum diese bestimmte Seite diese bestimmten Entscheidungen getroffen hat – und welche plausiblen Alternativen sie verworfen hat.

Wann aktivieren

Aktiviere dieses Skill immer dann, wenn der Nutzer das Design einer Website untersuchen und als Leitfaden für zukünftige Designarbeit erfassen möchte. Erfasse all diese Fälle:

• Explizite Slash-Form: /taste <url>
• Natürlichsprachliche Anfragen: „Analysiere das Design von vercel.com“, „Was macht Stripes Seite so gut?“, „Extrahiere die Design-Tokens von linear.app“, „Gib mir das Design-DNA von are.na“
• Nachahmungsabsicht: „Ich möchte, dass sich mein Dashboard wie Linear anfühlt“, „Erstelle mir eine Landingpage im Stil von “, „Portiere das Design dieser Seite in mein Projekt“
• Wettbewerbsanalyse: „Vergleiche unser Aussehen mit “, „Welche Design-Konventionen verwendet “
• Überall dort, wo der Nutzer eine URL erwähnt und nach ihren Designentscheidungen, Typografie, Farben, Abständen, Philosophie oder „Gefühl“ fragt

Wenn der Nutzer eine URL in Verbindung mit einem visuellen/Designthema erwähnt, tendiere zur Aktivierung – Claude neigt dazu, Skills zu wenig auszulösen. Im Zweifelsfall verwenden. Die Kosten einer verschwendeten Skill-Aktivierung sind gering; die Kosten einer generischen Designberatung, wenn dieses Skill eine spezifische, belegbasierte Analyse hätte liefern können, sind hoch.

NICHT aktivieren für: „Daten von einer Website extrahieren“ (Scraping-Skill verwenden), „Inhalt von zusammenfassen“ (WebFetch verwenden), „Diese Seite bereitstellen“ (nicht relevant).

Voraussetzungen

Dieses Skill erfordert den Playwright MCP Server (https://playwright.dev/docs/getting-started-mcp), der installiert und verbunden sein muss. Überprüfe mit:

claude mcp list | grep playwright

Wenn du playwright: ... - ✓ Connected siehst, ist alles gut. Wenn nicht, installiere ihn:

claude mcp add playwright -s user -- npx -y @playwright/mcp@latest --isolated

Warum --isolated: Jeder /taste-Durchlauf startet mit einem frischen Browserzustand, sodass Cookies, Login-Sitzungen und vorheriger Cache nicht in die analysierte Seite gelangen. Ohne diese Option würde /taste https://linear.app während einer aktiven Linear-Sitzung das App-Dashboard statt der öffentlichen Marketing-Seite analysieren – falsche Oberfläche, falscher Geschmack.

Warum npx @playwright/mcp@latest (ohne --browser-Flag): Playwright lädt ein eigenes gebündeltes Chromium herunter (~100 MB, einmalig). Dies ist portabler als die Verwendung des systemeigenen Chrome – es funktioniert auf Maschinen ohne Chrome, bietet konsistentes Rendering über alle Nutzer hinweg und öffnet niemals ein Fenster im echten Browserprofil des Nutzers.

Nach der Installation muss der Nutzer Claude Code neu starten, damit die MCP-Tools (mcp__playwright__browser_*) in dieser Sitzung erscheinen. Wenn Playwright beim Ausführen dieses Skills nicht verfügbar ist, stoppe und teile dem Nutzer klar mit: „Ich benötige Playwright MCP, um die Seite zu scrapen. Führe claude mcp add playwright -s user -- npx -y @playwright/mcp@latest --isolated aus und starte Claude Code neu, dann versuche es erneut.“

Beim ersten Start kann Playwright ~30–60 Sekunden dauern, bevor seine erste browser_navigate zurückkehrt – das ist der einmalige Chromium-Download. Nachfolgende Durchläufe starten in Sekunden. Wenn der Nutzer vorab herunterladen möchte, um die Wartezeit zu vermeiden, kann er einmalig npx playwright install chromium ausführen, bevor er dieses Skill aufruft.

Arbeitsablauf

Befolge diese fünf Phasen in der angegebenen Reihenfolge. Jede Phase hat explizite Erfolgskriterien – fahre erst fort, wenn die aktuelle Phase das erzeugt hat, was die nächste Phase benötigt.

Phase 0 – URL und Exportziel parsen

Schritt 1 – URL

Extrahiere die URL aus der Nachricht des Nutzers. Akzeptiere diese Formen:

• /taste https://linear.app
• „Analysiere das Design von vercel.com“ (füge https:// hinzu, falls fehlt)
• Eine bloße URL an beliebiger Stelle in der Eingabeaufforderung

Wenn der Nutzer keine URL angegeben hat, frage danach. Wenn er einen Dateipfad oder etwas angegeben hat, das offensichtlich keine URL ist, frage, ob er eine gehostete Seite meint. Fahre erst fort, wenn du eine echte URL hast.

Löse gängige Kurzformen auf, bevor du navigierst: linear.app → https://linear.app, https://www.stripe.com ist in Ordnung.

Schritt 2 – Domain für Dateibenennung extrahieren

Extrahiere aus der URL den Hostnamen und entferne ein etwaiges www.-Präfix. Beispiele:

• https://linear.app → linear.app
• https://www.stripe.com → stripe.com
• https://vercel.com/home → vercel.com

Speichere dies als {domain}. Alle Ausgabedateien werden danach benannt: {domain}.md, {domain}.json und alle Exportdateien. Verwende niemals den generischen Namen taste.md – dieser Name kollidiert, wenn der Nutzer dieses Skill auf mehreren Websites im selben Verzeichnis ausführt.

Schritt 3 – Exportziel + Crawl-Umfang

Wenn der Nutzer sowohl ein Exportziel als auch einen Crawl-Umfang in seiner Nachricht angegeben hat, überspringe diese Frage vollständig. Wenn eines fehlt, frage einmal in einer einzigen Nachricht:

„Zwei kurze Fragen, bevor ich beginne:

Exportziel – mit welchem Tool baust du?

 1  Cursor          → .cursor/rules/{domain}-taste.mdc
 2  Windsurf        → .windsurf/rules/{domain}-taste.md
 3  Claude Code     → CLAUDE.md (fügt Abschnitt „Design Taste“ hinzu)
 4  GitHub Copilot  → .github/copilot-instructions.md (fügt hinzu)
 5  Bolt            → .bolt/prompt
 6  Antigravity     → GEMINI.md
 7  v0 by Vercel    → taste-tokens.css + Anleitung
 8  Figma Make      → taste-figma.css + Anleitung
 9  Lovable         → Text zum Einfügen in Projektwissen ausgeben
10  Überspringen    → nur {domain}.md + {domain}.json behalten

Crawl-Umfang – nur diese Seite oder 2–3 verlinkte Seiten erkunden?

 1  Nur diese Seite       → schneller, fokussiert auf das, was du mir gegeben hast
 2  Verlinkte Seiten erkunden → Ich besuche 2–3 Navigationsseiten und führe die Daten zusammen
```“

Speichere Antworten als {exportTarget} und {crawlScope}. Standardwerte: {exportTarget} = „skip“, {crawlScope} = „single“. Frage nicht erneut.

Phase 1 – Seitendaten erfassen (Playwright MCP)

Führe diese Schritte in der Reihenfolge aus. Wenn ein Schritt fehlschlägt, stoppe die Pipeline und melde den Fehler dem Nutzer – fahre nicht stillschweigend mit beeinträchtigten Daten fort.

1. Ändere die Größe des Viewports auf 1440×900, damit die Messungen über alle Durchläufe hinweg konsistent sind:

   mcp__playwright__browser_resize  width=1440  height=900
   

2. Navigiere zur URL:

   mcp__playwright__browser_navigate  url=<die URL>
   

3. Warte kurz auf clientseitige Hydrierung. Schwere SPAs (figma.com, notion.so) benötigen einige Sekunden nach domcontentloaded, um echte Inhalte darzustellen. Verwende:

   mcp__playwright__browser_wait_for  time=3
   

   Wenn der Seiten-Snapshot nach 3 Sekunden immer noch wie ein Lade-Skelett aussieht, gib ihm weitere 3 Sekunden. Wenn es danach immer noch ein Skelett ist, vermerke es in der endgültigen Ausgabe („Seite möglicherweise unvollständig gerendert; einige Messungen sind Annäherungen“).

4. Erstelle zwei Screenshots – zuerst den Viewport, dann die gesamte Seite:

   4a. Viewport-Screenshot (1440×900, unskaliert – dies ist deine primäre visuelle Referenz für Schritt 1):

   mcp__playwright__browser_take_screenshot  type=jpeg  filename={domain}-viewport.jpeg
   

   4b. Bedingter Ganzseiten-Screenshot – überprüfe zuerst die Seitenhöhe:

   mcp__playwright__browser_evaluate  function=() => document.documentElement.scrollHeight
   

   • Wenn ≤ 6× Viewport-Höhe (≤ 5400px bei 1440×900): Normalen Ganzseiten-Screenshot erstellen:

     mcp__playwright__browser_take_screenshot  fullPage=true  type=jpeg  filename={domain}-fullpage.jpeg
     

   • Wenn > 6× Viewport-Höhe: Ganzseiten-Screenshot überspringen (zu hoch, verschwendet Tokens). Stattdessen zwei gezielte Viewport-Aufnahmen machen:

     // Seitenmitte (50% Scrollen)
     mcp__playwright__browser_evaluate  function=() => window.scrollTo(0, document.documentElement.scrollHeight * 0.5)
     mcp__playwright__browser_take_screenshot  type=jpeg  filename={domain}-mid.jpeg
     // Fußzeile
     mcp__playwright__browser_evaluate  function=() => window.scrollTo(0, document.documentElement.scrollHeight)
     mcp__playwright__browser_take_screenshot  type=jpeg  filename={domain}-footer.jpeg
     // Zurück nach oben scrollen
     mcp__playwright__browser_evaluate  function=() => window.scrollTo(0, 0)
     

   Verwende den Viewport-Screenshot als primäre visuelle Referenz in Schritt 1 – er repräsentiert den ersten Eindruck, den der Designer beabsichtigt hat. Verwende die Ganzseiten- oder Mittel-/Fußzeilen-Screenshots, um Muster zu überprüfen, die nur weiter unten auf der Seite auftauchen (Fußzeilen-Typografie, späte Farbvariationen usw.). JPEG hält die Token-Kosten im Vergleich zu PNG niedrig.

5. Führe den DOM-Extraktor aus. Lese references/extract.js und übergib seinen gesamten Inhalt als function-Argument:

   mcp__playwright__browser_evaluate  function=<Inhalt von references/extract.js>
   

   Das Tool gibt ein JSON-Objekt zurück. Speichere es mental als domData – du wirst es in Schritt 1 einspeisen.

6. (Optionale Bereinigung) Der Browser bleibt für den Rest der Sitzung geöffnet. Kein Grund, ihn zu schließen, es sei denn, der Nutzer fragt danach.

Mehrseitige Erfassung (nur wenn {crawlScope} gleich „multi“ ist):

Nach der Erfassung der primären Seite extrahiere Navigationslinks und besuche bis zu 2 zusätzliche Seiten derselben Website.

6a. Extrahiere Navigationslinks aus der bereits geladenen primären Seite:

(function() {
  const links = [];
  const seen = new Set([location.pathname]);
  const skip = /\/(login|logout|signup|sign-in|register|auth|account|checkout|cart|password|reset)\b/i;
  document.querySelectorAll('nav a, header a, [role="navigation"] a').forEach(a => {
    try {
      const u = new URL(a.href);
      if (u.hostname !== location.hostname) return;
      if (skip.test(u.pathname)) return;
      if (seen.has(u.pathname)) return;
      if (u.pathname === '/' && location.pathname !== '/') return;
      seen.add(u.pathname);
      links.push({ href: u.origin + u.pathname, text: (a.innerText || a.textContent).trim().slice(0, 40) });
    } catch(e) {}
  });
  return links.slice(0, 6);
})()

6b. Wähle 2 Seiten aus der zurückgegebenen Liste aus. Bevorzuge:

• Kürzere Pfade (/product statt /product/features/detail)
• Unterscheidbare Abschnittsnamen (Product, Community, Pricing, Docs – nicht nur verschiedene Slugs unter demselben Abschnitt)
• Vermeide die Stamm-/, wenn du sie bereits erfasst hast

6c. Für jede zusätzliche Seite führe einen leichteren Erfassungsdurchlauf durch (navigieren → 3s warten → nur Viewport-Screenshot → DOM-Extraktor). Überspringe Ganzseiten-/Mitte-/Fußzeilen-Screenshots für die Seiten 2–3 – der Viewport reicht aus, um die Designkonsistenz zu bestätigen, und der DOM-Extraktor erfasst die gesamte Seite unabhängig davon. Benenne Screenshots {domain}-viewport-2.jpeg, {domain}-viewport-3.jpeg. Speichere die Daten jeder Seite als pages[1], pages[2] (wobei pages[0] die primäre URL ist).

Wenn eine verlinkte Seite nicht geladen werden kann oder blockiert ist, überspringe sie stillschweigend und vermerke es im Phase-6-Bericht.

6d. Führe Daten zusammen vor Phase 2. Kombiniere Farbkandidaten über alle Seiten hinweg (Vereinigung), Typografie über alle Seiten hinweg (Vereinigung). Wenn ein Wert auf 2+ Seiten erscheint, ist es ein Systems Signal – markiere ihn. Werte, die nur auf einer Seite erscheinen, sind lokal – erfasse sie trotzdem, aber gewichte sie niedriger.

In den Schritten 1–3 gib immer an, wie viele Seiten analysiert wurden („Über 3 Seiten hinweg: …“) und unterscheide Systemmuster von lokalen. Mehrseitige Übereinstimmung ist der stärkste verfügbare Beleg für ein Geschmacksprinzip.

Erfolgskriterium für Phase 1: Du hast mindestens einen Screenshot UND ein ausgefülltes domData-JSON (von der primären Seite) mit den Feldern colors, typography, layout, effects, cards, images, spacingSamples, sectionGaps und grid. Wenn eines dieser Felder vollständig leer ist und der Screenshot echte Inhalte zeigt, muss der Extraktor verbessert werden – vermerke es und fahre trotzdem fort.

Abweichungspfad für Daten: Wenn domData.errors nicht leer ist, ist der Extraktor teilweise fehlgeschlagen. Markiere in Schritt 1 betroffene Kategorien mit ~approx (Extraktor-Abschnitt fehlgeschlagen) und verlasse dich für diese Messungen auf den Screenshot. Liste in Phase 6 die fehlgeschlagenen Abschnitte als Einschränkung im Bericht auf.

Phase 2 – Die 4-stufige Analyse durchführen

Screenshot ist die Grundwahrheit. Bevor du eine Referenzdatei liest: Der Viewport-Screenshot zeigt, was ein Mensch tatsächlich sieht. Die DOM-Daten liefern genaue Zahlen. Wenn sie in Konflikt stehen, vertraue dem Screenshot. Eine Farbe, die im DOM erscheint, aber <5% der sichtbaren Fläche bedeckt, ist dekorativ – führe sie nicht als Markenfarbe auf. Abschnittstrenner, die nicht im Screenshot erscheinen, existieren nicht, unabhängig davon, was das DOM meldet. Nicht wahrnehmbare Schatten (≤3% Deckkraft) sind CSS-Artefakte, keine Designentscheidungen.

Die vier Referenzdateien in references/ enthalten die vollständigen Aufforderungen für jeden Schritt. Lese jede, wenn du sie erreichst (lade nicht alle vier auf einmal vor – die Schritte sind bewusst sequentiell und frühere Schritte benötigen keine späteren Anweisungen).

Für jeden Schritt:

1. Lese die entsprechende Referenzdatei.
2. Erzeuge die Ausgabe, die sie verlangt, in deiner eigenen Antwort.
3. Beginne die Ausgabe mit der in der Referenz angegebenen Markierungszeile (z. B. ### Schritt 1 Ausgabe – Messungen).
4. Der nächste Schritt erhält deine vorherigen Ausgaben als Eingabe – behalte sie im Gespräch, fasse sie nicht zusammen.

Schritt 1 – Messen

• Lese references/step1-measure.md
• Eingaben: domData (das JSON von browser_evaluate) + der Screenshot
• Erzeuge: 20 Kategorien von Messungen, jeder Wert mit einem spezifischen px / hex / Verhältnis zitiert

Schritt 2 – Muster

• Lese references/step2-pattern.md
• Eingaben: Schritt 1 Ausgabe
• Erzeuge: 5–8 systematische Muster, jedes mit Muster / Beleg / Designziel

Schritt 3 – Geschmack

• Lese references/step3-taste.md
• Eingaben: Schritt 1 + Schritt 2 Ausgaben
• Erzeuge: 4 Geschmacksprinzipien (jeweils Auslöser / Entscheidung / Grund / Beleg), mindestens eine Zurückhaltungs-Trade-off

Schritt 4 – Beobachter

• Lese references/step4-observer.md
• Eingaben: Schritt 1 + 2 + 3 Ausgaben + die ursprüngliche URL

…

[aufgrund der Kürzung abgeschnitten – die vollständige Anleitung ist im Original vorhanden]