Communitygithub.com

williamsnieves/landing-factory

Das Anti-Slop-Frontend-Skill für Websites. Bietet kuratierte Design-Richtungen aus einer Studie von 247 Galerie-Websites, durchgesetzt durch einen strikten House-Style mit einem echten Browser-Inspektor und einem Look-and-Fix-Zyklus.

Was ist landing-factory?

Dieses Skill, "tasteskill v2", wurde entwickelt, um die typischen, generischen KI-Designmuster zu durchbrechen und stattdessen fundierte, konzeptionelle Entscheidungen für die Frontend-Entwicklung zu treffen. Basierend auf einer Analyse von 247 kuratierten Websites (One Page Love, Awwwards Sites of the Day) bietet es eine Bibliothek mit erforschten Design-Richtungen. Der Workflow beginnt mit der Analyse des Briefings und des Projekts, um das Wesentliche des Kunden (Subjekt, Zielgruppe, existierende Bilder) zu verstehen. Anschließend wird ein Argument für die Seitenstruktur entwickelt, bevor `draw.mjs` drei Richtungen ausspielt, aus denen der Entwickler die passendste auswählt. Diese Richtung beinhaltet dann ein komplettes System aus Typografie, Farbpalette, Hero-Bereich und Abschnitts-Kompositionen. Ein integraler Bestandteil ist die Durchsetzung eines strikten, ornamentlosen House-Styles. Das `inspect.mjs`-Skript prüft die Einhaltung der Regeln in einem echten Browser. Der Prozess endet mit einer visuellen Qualitätskontrolle: Screenshots in drei Breiten werden erstellt und mit einer Bewertungsmatrix überprüft, um sicherzustellen, dass die Seite substanziell und nicht nur reduziert wirkt. Das Skill ist ideal für den Bau, das Redesign oder die Überarbeitung von Landing Pages, Marketing-Websites, Portfolios, Produktseiten und Heldenbereichen in allen gängigen Stacks (HTML/CSS, React, Next.js, Vue, Svelte, Astro, Tailwind). Es ist nicht für Dashboards oder App-Bildschirme gedacht, sondern für öffentlichkeitswirksame Webseiten, die professionell und einzigartig wirken sollen.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/williamsnieves/landing-factory/tree/HEAD/.claude/skills/design-taste-frontend

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

tasteskill v2

Eine von einem Modell erstellte Seite sieht meist aus wie der Durchschnitt aller Seiten, die das Modell gesehen hat: eine zentrierte Überschrift über drei Zeilen, ein kleines Label darüber, eine Reihe von Icon-Karten, ein sanfter Verlauf, ein paar dünne Linien und eine monospace Beschriftung. Nichts daran ist falsch und nichts daran ist entschieden.

Dieses Skill ersetzt diese Standardeinstellungen durch Entscheidungen, und zwar auf vier Arten:

  1. Ein Skript legt die Richtungen vor, du wählst daraus. Wenn ein Modell gebeten wird, ein Aussehen zu erfinden, wählt es jedes Mal die Kategorievorgabe. scripts/draw.mjs legt drei von zwanzig recherchierten Richtungen vor; du wählst diejenige, die die Idee des Themas trägt, und das Skript legt dann dessen Typensystem, Palette, Hero- und Abschnittskompositionen aus einer Bibliothek fest, die aus 247 echten Websites destilliert wurde.
  2. Die Idee kommt vom Thema. In der Studie unterschied das, was die besten Websites von den vergessenswerten trennte, ein Konzept, das von der Sache selbst stammt, nicht von der Gestaltung.
  3. Ein Hausstil ohne Verzierungen, gemessen in einem echten Browser durch scripts/inspect.mjs, sodass die Regeln überprüft statt erhofft werden.
  4. Du siehst dir an, was du gemacht hast. Screenshots in drei Breiten, eine Bewertungsmatrix der Jury, korrigieren, nochmal ansehen.

Eine beim Testen gelernte Warnung. Die Verzierungen wegzunehmen ist nur die Hälfte der Arbeit; eine Seite, die ihre Labels, Linien und Karten verloren hat und nichts an ihrer Stelle bekommen hat, wirkt dünn, und blinde Juroren bevorzugen zu Recht eine reichhaltigere Seite mit Hinweisen gegenüber einer leeren Seite ohne sie. Die andere Hälfte ist Substanz: größer gesetzter Text, ganze Farbflächen, echte Bilder aus der Welt dieses Themas (gefunden oder gezeichnet), und jeder Abschnitt, der seinen vollständigen Inhalt trägt. Das Skill ist darauf ausgelegt, dir das zu geben; tausche es nicht gegen Zurückhaltung ein.

In den folgenden Befehlen ist <skill> der Ordner dieses Skills. Führe sie vom Stammverzeichnis des Projekts aus aus, sodass die Arbeitsdateien dort in .taste-skill/ landen. Die Skripte benötigen Node 22+ und ein installiertes Chrome, Edge oder Chromium und installieren nichts. assets.mjs benötigt außerdem Netzwerkzugriff; es verwendet keine API-Schlüssel.

Der Ablauf

Führe diese in der richtigen Reihenfolge aus. Die Schritte 1–5 dauern ein paar Minuten und entscheiden, ob die Seite gut wird.

1. Lies das Briefing und das Projekt

Finde heraus, was real ist: das Thema, die Zielgruppe, die eine Sache, die die Seite jemanden tun lassen soll, der Tech-Stack, etwaige bestehende Marken (Farben, Schriften, Logo) und vor allem welche Bilder wirklich existieren: die eigenen Fotos oder Produktaufnahmen des Projekts, eine echte Benutzeroberfläche, die gezeigt werden kann, ein Bildgenerierungstool, das du nutzen kannst, oder nichts. Plane nicht um Bilder herum, die du nicht hast. Nichts Eigenes ist selten gar nichts: das Stadtviertel des Themas, die Straße, Materialien und Geschichte sind in offenen Archiven und Museen zu finden, kostenlos nutzbar mit einer Quellenangabe (Schritt 6, scripts/assets.mjs).

Wenn die Anfrage vage ist, entscheide und formuliere deine Lesart in einem Satz, anstatt nachzufragen. Frage nur, wenn eine fehlende Tatsache die Arbeit blockiert (z. B. kein Produktname).

Erstelle dann ein Inventar des Themas in deinen Notizen: acht bis zwölf Dinge, die zu diesem Kunden und zu keinem Wettbewerber gehören. Suche nach seinem Namen und was der Name bedeutet; seiner Adresse, Hausnummer, Straße und Nachbarschaft und wie dieser Ort aussieht (seine Fliesen, Schilder, Farben, Schriftarten an den Ladeneingängen, sein Licht, sein Wetter); den Zahlen im Briefing (Sitze, Zimmer, Minuten zum Meer, der Preis, das Jahr); der Einschränkung, mit der es lebt (nur eine Charge pro Monat, im Winter geschlossen, nur nach Vereinbarung); seinen Materialien und Farben; seinen Ritualen und Öffnungszeiten (der Ofen, der um fünf angezündet wird, die Fähre um sieben); den gedruckten Dingen seiner Welt (ein Fahrplan, ein Etikett, eine Eintrittskarte, ein Schild). Diese Liste ist die Quelle der Idee in Schritt 4. In Blindtests wurde die Seite, die jedes Briefing gewann, aus einem Element einer solchen Liste gebaut (der Name des Kunden und seine Bedeutung, die Straße, in der er steht, die eine Einschränkung, die ihn zu dem macht, was er ist), und die Seiten, die verloren, hatten eine gute Komposition mit einer Kategorieidee. Die Liste ist auch deine Bildersuche: jeder Ort, jedes Material und jedes gedruckte Ding darauf ist eine Suchanfrage für Schritt 6.

2. Schreibe das Argument

Vor jedem Design liste die Seite als Behauptungen mit ihrem Beweis auf, eine Zeile pro Abschnitt, so wie es references/copy.md §1 zeigt. Die Behauptungen entscheiden, welche Abschnitte existieren und in welcher Reihenfolge. Lösche jeden Abschnitt, der keine Behauptung hat. So vermeidest du die Standardsequenz aus Hero, Logos, drei Funktionen, Testimonial, Preise, Call-to-Action.

3. Zeichne die Richtung

node <skill>/scripts/draw.mjs --sector <Sektor> --brief "<eine Zeile über das Thema>" \
  --sections <Rollen in der Reihenfolge deines Arguments> [--tone <Ton>] [--have <Assets>] [--keep palette,type] \
  --options 3

Dies wählt drei Richtungen aus und gibt eine kurze Zusammenfassung jeder aus. Halte jede gegen dein Inventar: welche Art zu komponieren kann etwas tragen, das nur dieser Kunde hat? Wähle diese, nicht die vertrauteste, und schreibe eine Zeile in deinen Notizen, warum. Beim Testen war eine einzelne zufällige Richtung, die nicht zum Thema passte, die häufigste Ursache für eine schwache Seite. Dann wähle das vollständige Blatt:

node <skill>/scripts/draw.mjs <dieselben Argumente, ohne --options> --direction <gewählte ID>
  • --sector: node <skill>/scripts/draw.mjs --list sectors. Wähle den nächsten.
  • --sections: Rollen aus --list roles (features, showcase, how-it-works, testimonial, proof, stats, pricing, faq, cta, footer, intro, about, work, gallery, list, contact). Der Hero ist impliziert.
  • --tone (optional): quiet, bold, warm, technical, playful, luxury, editorial. Gib es nur an, wenn das Briefing klar danach fragt.
  • --have: Assets, die wirklich existieren, kommagetrennt: photography (die eigenen Fotos des Projekts vom Ort, den Leuten oder der Arbeit), product-photo (Fotos des spezifischen Produkts oder ein Bildtool, das sie erstellen kann), product-ui (echte Screenshots), illustration, video. Lass es weg, wenn du keine hast: Der Draw vermeidet dann Kompositionen, die darauf angewiesen sind, und das Blatt sagt, wie man Bildplätze ehrlich füllt (Software zeigt ihre eigene, in HTML gebaute Oberfläche; ein Produkt ohne Fotos wird gezeichnet und unter echte Bilder seiner Welt gesetzt, niemals eine gefälschte Produktaufnahme). Bilder, die du in den offenen Sammlungen findest, sind nicht die eigenen des Projekts; lass sie aus --have heraus.
  • --keep palette,type: wenn die Marke bereits Farben oder Schriftarten festlegt. Der Draw wählt dann nur die Komposition aus, und du ordnest die Markenwerte den Rollen zu.

Der Befehl gibt ein Richtungsblatt aus. Es ist die Art Direction für diesen Build:

  • Übernimm es. Vermische es nicht mit dem Layout, das du ohnehin gemacht hättest. Wenn es sich unvertraut anfühlt, gut: Das vertraute Layout ist das, das dieses Skill verhindern soll.
  • Zeichne einen Slot nur aus einem Grund neu (--redraw hero | type | palette | photos | section:<Rolle> | direction), den du benennen kannst: es widerspricht einer genannten Markeneinschränkung oder benötigt ein Asset, das nicht existiert. Zeichne niemals neu, um etwas Bequemeres zu bekommen. Dokumentiere jede Neuziehung in deinem Bericht.
  • Wenn ein gewählter Abschnitt den echten Inhalt nicht fassen kann (er vergleicht drei Pläne und es gibt einen Preis; er will fünf Zitate und es gibt keine), passe den Inhalt nicht an. Liste die anderen mit --alternatives <Rolle> auf, wähle den, dessen Annahmen zum Inhalt passen, und übernimm ihn mit --redraw section:<Rolle>=<ID>.
  • Überprüfe die Palette am Thema. Eine gewählte Palette ist ein Satz von Proportionen (ein Hintergrund, eine Tinte, ein Akzent, Flächen) ebenso wie ein Satz von Farben. Wenn ihre Farben mit den eigenen Materialien des Themas kämpfen (Bonbonpastelle für einen Torfwhisky, Neon für eine Berghütte), zeichne die Palette einmal neu; wenn das Thema unverkennbare eigene Farben hat (sein Material, die Farbe seiner Straße, die Landschaft vor seinen Fenstern), behalte die gewählten Proportionen und nimm die Farben stattdessen vom Thema, und sage das im Bericht.
  • Gib es jederzeit mit node <skill>/scripts/draw.mjs --show erneut aus. Lies es in einer langen Sitzung vor jedem Abschnitt, den du baust, noch einmal.

4. Finde die Idee

Die Richtung ist eine Art zu komponieren. Die Idee ist das, was die Seite zu diesem Thema und zu keinem anderen gehören lässt. Schreibe diesen Satz in deinen Notizen und beginne nicht mit dem Bauen, bis beide Lücken aus dem Thema selbst gefüllt sind:

Auf dieser Seite wird [etwas, das zum Thema gehört] zu [dem Mittel, das die Richtung verlangt].

Orte, an denen du nach der ersten Lücke suchen kannst:

  • Seine Ausgabe. Was produziert das Ding? Setze die echte Ausgabe als Material auf die Seite. (Eine Kamera, die Gedichte druckt, lieferte ihren Text als Papierstreifen.)
  • Sein Objekt oder seine Form. Wie sieht es physisch aus, im Querschnitt, in Silhouette? Vergrößere es, beschneide es, mache es zum Rahmen oder zum einzigen Motiv.
  • Sein Name. Können die Buchstaben ein Foto halten, sich zu einer Wand stapeln, sich auf zwei Ecken aufteilen?
  • Sein Ort. Gibt es eine Aussicht, die jemanden dazu bringt, dort sein zu wollen?
  • Sein Ritual. Gibt es eine Abfolge, die die Seite beim Scrollen aufführen kann?
  • Sein Artefakt. Welches gedruckte Ding existiert bereits in seiner Welt: Fahrkarte, Speisekarte, Etikett, Quittung, Einladung, Ordner, Handbuch?
  • Sein Gegenteil. Welche andere Kategorie besitzt das Gefühl, das dieser einen fehlt?

Fülle die erste Lücke aus deinem Inventar (Schritt 1), nicht aus der Kategorie. Der Wettbewerbertest: Setze den nächsten echten Wettbewerber in den Satz (die Bäckerei zwei Straßen weiter, ein anderer Eichenmöbelhersteller, eine andere Hütte auf demselben Berg). Wenn der Satz immer noch funktioniert, gehört die Idee zur Kategorie: ein Laib Brot ist jede Bäckerei; die sieben Türen der Straße, nach der diese benannt ist, sind nur diese eine. „Sauber und modern" ist keine Idee. Die Websites, die das Gremium der Studie am niedrigsten bewertete, waren diejenigen, deren Idee als „keine über die Standardformel hinaus" verzeichnet war.

Eine lebendige Sache. Gib der Seite eine Sache, die der Besucher tun kann, oder die bei jedem Besuch anders ist, aus der Idee gemacht: Wähle ein Holz und sieh den Stuhl darin; tippe deinen Namen ein und sieh ihn in den Buchstaben der Gießerei geschnitten; stelle den Kredit ein und lies den echten monatlichen Betrag; sieh, ob der Ofen der Hütte gerade brennt und wie lange bis zur letzten Fähre; wähle eine Größe und sieh sie gegen den Raum. In Blindtests hatte jede Gewinnerseite eine, und die Juroren nannten sie zuerst. Regeln: Sie verwendet die echten Inhalte des Themas, sie funktioniert auf einem Telefon mit dem Daumen, sie hat einen einfachen Fallback ohne Skript, sie blockiert nie das Lesen, und sie ist eine Sache, kein Spielplatz. Sie wird in Schritt 6 als Teil der Seite gebaut, nicht als Bewegung in Schritt 9 hinzugefügt.

5. Schreibe die Wörter

Schreibe die gesamte Seite als Textentwurf (Klartext) vor dem Markup, gemäß references/copy.md:

  • Jede Überschrift passt in zwei Zeilen oder weniger bei jeder Breite. Mache die Rechnung in copy.md §2, bevor du dich für einen Satz entscheidest: Etwa 32 Zeichen sind überall in einer selbstbewussten Größe sicher. Die untersuchten Galerie-Heros haben einen Median von 5 Wörtern und 32 Zeichen.
  • Ein unterstützender Satz. Eine primäre Handlung, benannt nach dem, was sie tut, als echter Button auf dem ersten Bildschirm.
  • Der erste Bildschirm beantwortet die erste Frage des Besuchers in großer Schrift. Für ein Event: was es ist, wann und wo (die Daten gehören in die Überschrift oder in die zweite Größe, niemals nur in kleinen Text). Für ein Produkt: was es ist und was es kostet oder tut. Für eine Person: wer und was sie tun. Jeder Abschnitt, zu dem der Besucher gekommen ist (das Line-up, die Speisekarte, die Zimmer, der Preis), hat seine eigene Überschrift und seinen eigenen Platz in der Navigation.
  • Schreibe den vollständigen Inhalt. Jeder Abschnitt, nach dem das Briefing fragt, liefert seine Informationen vollständig: die gesamte Speisekarte mit Preisen, jedes Zimmer mit seinen eigenen Details, jeder Redner und Vortrag, der Preis mit dem, was er beinhaltet, eine Antwort auf jede echte Frage. Dünne Abschnitte sind der häufigste Grund, warum eine saubere Seite gegen eine geschäftigere verliert.
  • Beispieldetails werden erwartet, wo das Briefing Lücken lässt (Gerichtenamen, Zimmermamen und -preise, Projekttitel), damit das Design in voller Dichte gesehen wird; liste sie im Bericht zur Bestätigung durch den Kunden auf. Beweise werden nie erfunden: keine Kunden, Zitate, Bewertungen, Presse, Logos oder Geschäftszahlen.

6. Baue es, immer noch

Baue die Seite mit ausgeschalteter Bewegung in deinem Kopf; eine Seite, die Animation braucht, um fertig auszusehen, ist nicht fertig. Arbeitsreihenfolge:

  1. Tokens. Farb- und Schriftrollen aus dem Blatt als CSS Custom Properties. Alles Nachgelagerte referenziert nur Tokens. <skill>/assets/base.css ist eine neutrale Grundlage, von der du ausgehen kannst (Reset, Token-Namen, flüssige Schriftgrößen, Raster, Fokus- und Auswahlstile, die Bewegungshelfer); sie hat kein eigenes Aussehen.
  2. Der Hero, genau wie der Bauplan es beschreibt, auf Desktop- und Telefonbreite. Mach das Große groß und das Kleine klein, bevor irgendetwas anderes existiert.
  3. Jeder Abschnitt gemäß seinem Bauplan, mit dem Inhalt dieses Projekts. Behalte die Geometrie, ändere das Thema. Benachbarte Abschnitte dürfen kein Layout teilen. Trage die Idee in jeden Abschnitt, einschließlich Preise, FAQ und Footer; der häufigste Fehler in der Studie, selbst bei guten Websites, ist ein unverwechselbarer erster Bildschirm, gefolgt von Standardblöcken.
  4. Bildmaterial, in dieser Reihenfolge der Präferenz:
    1. die eigenen des Projekts;
    2. generiert, falls du ein Bildtool hast;
    3. echte Bilder aus der Welt des Themas aus den offenen Sammlungen, wann immer ein ehrliches existiert. Suche sie mit node <skill>/scripts/assets.mjs "<Suchanfrage>" (Openverse, Wikimedia Commons, das Art Institute of Chicago und das Met; nur Lizenzen, die kommerzielle Nutzung erlauben, standardmäßig). Durchsuche das Inventar, nicht die Kategorie: seine Straße auf alten Postkarten, eine alte Karte der Nachbarschaft, sein Material aus der Nähe, sein Gewerbe in Gravuren, ein Museumsstück seiner Art, eine botanische Tafel, eine Sternenkarte. Verwende sie groß und mit Absicht: ein Archivfoto als Hero, eine vergrößerte Gravur als Motiv der Seite, die echte Karte der Straße als Kontaktabschnitt. Schau dir jedes an, bevor du wählst; --get <Referenz> lädt es in assets/ herunter und zeichnet seine Quelle und Lizenz auf, und --credits gibt die Quellenangabe für den Footer aus. Ein gefundenes Bild zeigt die Welt um den Kunden herum und wird niemals als das eigene Produkt, der eigene Raum, das eigene Gericht, die eigene Person oder das eigene Team des Kunden ausgegeben;
    4. gezeichnet in …

… [für die Übersetzung gekürzt]

Individual skills in this repo

This repo contains 4 individual skills — each has its own dedicated page.

williamsnieves/landing-factory

Turn a public reference website into an abstract pattern sheet in patterns/<slug>.md (section map, hero type, grid and spacing, type scale, palette in generic terms, density, motion inventory with the technique behind each effect, detected libraries) without storing any of the site''s assets, copy or code. Use when the user runs /analyze-reference <url> or asks to analyze, study, break down or extract patterns from an inspiration or reference site for a landing. Checks robots.txt and text-and-data-mining reservations first and aborts if access is disallowed. Not for cloning or rebuilding a site.

williamsnieves/landing-factory

Use when the user wants to design, redesign, shape, critique, audit, polish, simplify, harden, animate, or otherwise improve a frontend interface: websites, landing pages, dashboards, product UI, components, forms, settings, onboarding, empty states, and native iOS or Android screens. Handles UX review, hierarchy, layout, typography, color, motion, UX copy, accessibility, responsive behavior, edge cases, and capturing or documenting design systems (DESIGN.md, tokens). Also for making bland UI bolder, loud UI quieter, or ambitious visual effects. Not for backend-only or non-UI tasks.

williamsnieves/landing-factory

Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks. Also use when the user says "openspec apply", "opsx apply", or "openspec implement".

williamsnieves/landing-factory

Archive a completed OpenSpec change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete. Also use when the user says "openspec archive" or "opsx archive".

Verwandte Skills