Communitygithub.com

nexu-club/waitlist-page

Minimale Landingpage vor dem Launch mit E-Mail-Erfassung, Markenlogo und optionaler dekorativer Ebene. Liest DESIGN.md für Farben, Typografie und Layoutregeln. Am besten geeignet für: Produkteinführungen, Beta-Anmeldungen, Early-Access-Programme, Indie-Projekte.

Was ist waitlist-page?

Diese Skill-Anweisung beschreibt die Erstellung einer fokussierten, ehrlichen Wartelistenseite nach Markenvorgaben. Sie dient als erste professionelle Kontaktaufnahme mit zukünftigen Nutzern und vermittelt die Markenidentität sowie ein klares Wertversprechen, ohne auf künstliche Knappheit oder gefälschte Social-Proof-Taktiken zurückzugreifen. Der Workflow ist strikt templatebasiert und sicherheitsorientiert. Er beginnt mit dem Einlesen einer DESIGN.md für Farben und Schriftarten, dem Kopieren einer gehärteten Vorlage (assets/template.html) und dem schrittweisen Ersetzen von Platzhaltern mit validierten und in vielen Fällen HTML-escapten oder streng geprüften Werten – insbesondere bei Farbausdrücken und SVG-Inhalten, um CSS- und XSS-Injektionen zu verhindern. Es wird eine umfangreiche Checkliste mit zwei Härtungsstufen (P0 = Muss und P1 = Soll) durchlaufen, um sicherzustellen, dass die Seite mobilfreundlich, barrierefrei (WCAG AA) und konsistent mit der Marke ist. Das Endprodukt ist eine einzige, in sich geschlossene HTML-Datei mit inline-CSS und SVG-Grafiken, die über data-od-id-Attribute für nachfolgende Agenten-Anpassungen markiert ist. Die Plattformunterstützung wird nicht explizit genannt, aber der strukturierte Code und die Standards (HTML, CSS, Barrierefreiheit) zielen auf gängige Browser und Entwicklungsumgebungen ab.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/nexu-club/open-design/tree/HEAD/plugins/_official/examples/waitlist-page

In Ihrer bevorzugten KI fragen

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

Dokumentation

Skill für Wartelistenseite

Vor-Launch-Seiten sind der erste Händedruck mit zukünftigen Nutzern. Dieser Skill erstellt einen fokussierten, ehrlichen Auftritt: Ihre Markenidentität, das, was Sie machen, und einen klaren Weg, um sich auf die frühe Liste zu setzen. Keine künstliche Verknappung, kein gefälschter Countdown, keine Inflations-Taktiken – nur ein sauberes, mobile-erstes Gefäß für echtes Interesse.

Arbeitsablauf

Vorbereitung: Gehärtetes Template und Markenfundament laden

  1. Die Markenidentität laden – Lesen Sie DESIGN.md für das Farbsystem, die Schriftkombination und die räumlichen Regeln. Dies ist Ihr Fundament. Eine Wartelistenseite lebt oder stirbt durch die Konsistenz mit der Marke, die sie repräsentiert. Wenn DESIGN.md fehlt, bitten Sie den Nutzer, eine bereitzustellen, bevor Sie fortfahren.
  2. Das wiederverwendbare Template lesen und kopieren – Lesen Sie assets/template.html. Dieses Template ist der gehärtete Keim für alle Ausgaben. Kopieren Sie es als Basis in index.html. Schreiben Sie kein HTML von Grund auf oder weichen Sie von dieser Struktur ab. Das Template enthält alle erforderlichen Layout-, Formularstruktur-, Dekorations-, Fokus-Stile und Barrierefreiheits-Grundgerüste.

Schritte: Token-Ersetzung mit Validierung und Escaping

  1. Token aus den Eingaben zuordnen – Für jeden Platzhalter im Template (z.B. {{PRODUCT_NAME}}, {{BG_EXPRESSION}}, {{BORDER_EXPRESSION}}, {{LOGO_MARK}}) befolgen Sie die folgenden Ersetzungsregeln:
    • Text-Token ({{PRODUCT_NAME}}, {{TAGLINE}}): HTML-escaped für <, >, &, ", ' vor dem Einfügen in HTML-Textknoten oder Attributwerte.
    • HTML-Token ({{LOGO_MARK}}): Wenn Textinitialen verwendet werden, standardmäßig HTML-escaped. Wenn Inline-SVG verwendet wird, muss dieses streng mit einer Positivliste bereinigt werden: Entfernen Sie <script>-Tags, Ereignisbehandler (on*), <foreignObject>, externe Referenzen (href, xlink:href, url()) und alle nicht erlaubten Attribute/Elemente vor dem Einfügen. Wenn das SVG nicht sicher bereinigt werden kann, verwenden Sie als Fallback escapede Textinitialen. Geben Sie niemals rohes, nicht bereinigtes, beliebiges HTML aus. Stellen Sie sicher, dass jedes SVG sauber innerhalb seines Containers skaliert.
    • Farbausdruck-Token ({{BG_EXPRESSION}}, {{FG_EXPRESSION}}, {{ACCENT_EXPRESSION}}, {{DECO_EXPRESSION}}, {{STRIPE_EXPRESSION}}, {{SUCCESS_EXPRESSION}}, {{BORDER_EXPRESSION}}, {{BTN_LABEL_EXPRESSION}}, {{TICKER_BG_EXPRESSION}}, {{TICKER_FG_EXPRESSION}}, {{DECO_STROKE_EXPRESSION}}, {{LOGO_SHADOW_EXPRESSION}}, {{LOGO_FG_EXPRESSION}}): Muss strikt einer expliziten Farbgrammatik folgen (#hex, rgb/rgba, hsl/hsla, oklch oder color-mix() nur mit lokalen Variablen). Weisen Sie jede Eingabe mit ;, {}, <, >, Kommentaren (/*), @, url( oder externen Referenzen strikt zurück, um CSS-Injektionen zu verhindern. Nicht mit # umschließen oder zusätzliche Anführungszeichen hinzufügen. Beispiele: rgba(196, 169, 154, 0.38), color-mix(in srgb, var(--fg) 38%, transparent), #FDE8DF. Unverändert in :root CSS-Variablen einfügen. Leiten Sie --success aus DESIGN.md ab, falls vorhanden; ansonsten nur den erlaubten Fallback #2D6A4F verwenden.
    • Schriftname-Token ({{DISPLAY_FONT_CSS}}, {{BODY_FONT_CSS}}): Dies sind CSS font-family-Werte, die bei Leerzeichen bereits in Anführungszeichen gesetzt sind (z.B. 'DM Sans', Syne). Unverändert in die --font-display und --font-body-Deklarationen einfügen; KEINE zusätzlichen Anführungszeichen hinzufügen.
    • Schrift-URL-Token ({{DISPLAY_FONT_URL}}, {{BODY_FONT_URL}}): Leerzeichen müssen für die Google Fonts-URL als + kodiert werden (z.B. DM+Sans, IBM+Plex+Serif). Validieren Sie die URL auf Wohlgeformtheit vor dem Einfügen.
  2. Token-Zuordnungsregeln überprüfen – Alle Farb-Token sind jetzt in CSS-Variablen:
    • --bg = {{BG_EXPRESSION}} (z.B. #FDE8DF)
    • --fg = {{FG_EXPRESSION}} (z.B. #1A1410)
    • --accent = {{ACCENT_EXPRESSION}} (Marken-Akzent)
    • --deco = {{DECO_EXPRESSION}} (primäre Dekoration)
    • --deco-stripe = {{STRIPE_EXPRESSION}} (Akzent-Streifen)
    • --input-border = {{BORDER_EXPRESSION}} (CSS-Ausdruck mit Deckkraft)
    • --success = {{SUCCESS_EXPRESSION}} oder #2D6A4F Fallback
    • --btn-label = {{BTN_LABEL_EXPRESSION}} (Schaltflächentextfarbe für Kontrast)
    • --ticker-bg = {{TICKER_BG_EXPRESSION}} (Hintergrund des animierten Tickers)
    • --ticker-fg = {{TICKER_FG_EXPRESSION}} (Text des animierten Tickers)
    • --deco-stroke = {{DECO_STROKE_EXPRESSION}} (SVG-Striche, typischerweise gedämpft mit 12–15 % Deckkraft)
    • --logo-shadow = {{LOGO_SHADOW_EXPRESSION}} (Logocontainer-Schatten, subtiler Vordergrundton)
    • --logo-fg = {{LOGO_FG_EXPRESSION}} (kontrastreiche Textfarbe für Logo-Initialen)
  3. Responsives Layout – Das Template beinhaltet mobile-first Skalierung:
    • 375px: Formular stapelt sich einspaltig, Logo schrumpft auf 40px, Dekoration komprimiert sich, kein horizontaler Scrollbalken.
    • 768px: Spürbarer zweispaltiger Freiraum.
    • 1440px+: Zentriertes Layout mit großzügigem Weißraum.
    • Überprüfen Sie, ob der gesamte Text lesbar bleibt und die E-Mail-Eingabe sowie die Schaltfläche bei 375×667 und 390×844 vollständig sichtbar sind (kein Abschneiden).

Validierung: Gehärtete Qualitätstore vor der Ausgabe ausführen

  1. Die Qualitätscheckliste ausführen – Lesen Sie references/checklist.md. Validieren Sie jedes P0-Tor, bevor Sie ausgeben:
    • Genau ein CTA (E-Mail-Formular)
    • Kein Countdown-Timer, keine gefälschten Social-Proof-Taktiken, kein Emoji
    • Kein horizontaler Scrollbalken bei 375px
    • E-Mail-Eingabe hat type="email" und required; Vorname hat kein required
    • Formular verwendet NICHT novalidate; JS verwendet checkValidity() Überprüfung
    • Erfolgsmeldung hat role="status" oder aria-live="polite"
    • Alle Farben aus DESIGN.md oder erlaubtem Fallback; keine erfundenen hex-Werte
    • Benutzertext ist HTML-escaped; Farb-Token folgen der strikten Grammatik; Schriften sind URL-kodiert
    • P0 bestehen oder nicht ausgeben. Wenn ein P0-Tor fehlschlägt, den Benutzer fragen oder die Token-Zuordnungen korrigieren und erneut versuchen.
  2. P1-Tore für eine qualitativ hochwertige Abgabe überprüfen (empfohlen):
    • Hover- und Aktivzustände für die Absenden-Schaltfläche
    • Formularvalidierung mit klarem Feedback
    • Ticker-Animation respektiert prefers-reduced-motion: reduce
    • Alle interaktiven Elemente haben sichtbare Fokus-Stile (input:focus beinhaltet outline)
    • Tab/Eingabetaste Tastaturunterstützung
    • WCAG AA Kontrast für Fließtext (≥4,5:1) und Schaltflächenbeschriftung (≥4,5:1)
    • Logo alt/aria-label vorhanden; Ticker hat aria-hidden="true"
    • <html lang=""> ist gesetzt

Ausgabe

  1. Sauberes HTML ausgeben – Einzelne Datei, CSS inline, SVG für Grafiken. Markieren Sie interaktive Elemente mit data-od-id (Überschrift, Formular, Logo, Ticker, Raster usw.), damit Agenten ohne Parsing anpassen können.

Qualitätstore

Dieser Skill erzwingt einen gehärteten, templatebasierten Workflow, um die Einhaltung der Vorgaben sicherzustellen. Sie müssen diesem Ausführungspfad folgen; eine Abweichung vom Template macht die Ausgabe ungültig.

Verbindliche templatebasierte Ausführung:

  • Lesen Sie assets/template.html als Ihre Basis; schreiben Sie kein HTML von Grund auf.
  • Kopieren Sie es in index.html und ersetzen Sie nur die {{PLATZHALTER}}-Token mit validierten/escapeden Werten.
  • Führen Sie jedes P0-Tor in references/checklist.md vor der Ausgabe aus; wenn eines fehlschlägt, korrigieren und erneut validieren.

P0-Tore (müssen bestehen):

  • Einzelner CTA: Das E-Mail-Formular ist das einzige interaktive Element. Keine Navigation, keine sekundären Schaltflächen, keine Social-Media-Links.
  • Logo-Platzierung: Fixiert oben links, stimmt mit der Akzentfarbe aus DESIGN.md überein, skaliert auf Mobilgeräten herunter (50px → 40px).
  • Farbkonsistenz: Jede Farbe aus der DESIGN.md-Palette. Einzige erlaubte hartkodierte Ausnahme: #2D6A4F für --success.
  • Keine Anti-Patterns: Kein Countdown-Timer, keine gefälschten Social-Proof-Taktiken, keine Emoji-Icons, kein Lorem Ipsum.
  • Inhaltsintegrität: Überschrift und Text beziehen sich direkt auf die Eingaben product_name und tagline – kein Füllertext.
  • Mobile Passform: Kein horizontaler Scrollbalken bei 375px. E-Mail-Eingabe und Absenden-Schaltfläche sind bei 375×667 und 390×844 vollständig sichtbar (kein Abschneiden). Vertikaler Überlauf ist scrollbar, nicht versteckt.
  • Typografische Disziplin: Nur Display + Body-Schriften (2-Schrift-Regel). Konsistente Größen über Abschnitte hinweg.
  • Formularstruktur: Zwei Felder (Vorname optional, E-Mail erforderlich), checkValidity() Überprüfung, Erfolgsmeldung mit role="status".
  • Token-Escaping: Der gesamte vom Benutzer bereitgestellte Text ist HTML-escaped; Farb-Token folgen der strikten Grammatik und enthalten keine unsicheren Zeichen (;, {}, <, >, /*, @, url(); Schriftnamen sind URL-kodiert; {{LOGO_MARK}} sind escapede Textinitialen oder streng bereinigtes Inline-SVG (keine Skripte, keine Ereignisbehandler, kein foreignObject, keine externen hrefs).

P1-Tore (sollten für eine qualitativ hochwertige Abgabe bestehen):

  • Hero-Abschnitt visuell abgehoben und oberhalb der Falz.
  • Absenden-Schaltfläche für E-Mail hat Hover- und Aktivzustände.
  • Formularvalidierung gibt klares Feedback.
  • Seite scrollbar (nicht abgeschnitten) auf allen mobilen Viewports; CTA ohne Scrollen sichtbar.
  • Ticker-Animation pausiert/entfernt unter prefers-reduced-motion: reduce.
  • Alle interaktiven Elemente haben sichtbare Fokus-Stile (outline, nicht nur outline:none).
  • Tastatur: Tab erreicht jedes Formularfeld; Enter sendet ab.
  • WCAG AA Kontrast: Fließtext ≥4,5:1, Schaltflächenbeschriftung ≥4,5:1.
  • Logo alt/aria-label vorhanden; Ticker hat aria-hidden="true".
  • <html lang=""> auf den korrekten Sprachcode gesetzt.

Dekorationszurückhaltung:

  • Unterer Bereich verbessert ohne Ablenkung. Deckkraft, subtile Striche, gedämpfte Animation.
  • Kein Farbverlauf, der mehr als 20 % der Viewport-Höhe einnimmt.
  • Spule, Streifen, Raster oder Ticker verwenden nur Farben aus DESIGN.md.

Ausgabe

Nur ausgeben, nachdem alle P0-Tore in references/checklist.md bestanden wurden.

Geben Sie das Artefakt zwischen Tags aus:

<artifact identifier="waitlist-id" type="text/html" title="Coming Soon — {{PRODUCT_NAME}}">
<!doctype html>
<html lang="en">
...
</html>
</artifact>

Eine Zeile Beschreibung über dem Artefakt; nichts darunter.

Nach der Ausgabe: Wenn der Benutzer Änderungen wünscht, aktualisieren Sie die index.html direkt und führen Sie die P0-Checkliste vor der Ausgabe der nächsten Version erneut aus. Überspringen Sie die Validierung bei Iterationen nicht.

Verwandte Skills