Communitygithub.com

Öffnungslisten-Seite (Waitlist Page)

Minimale Pre-Launch-Landingpage mit E-Mail-Erfassung, Markenlogo und optionaler dekorativer Ebene. Liest DESIGN.md für Farben, Typografie und Layout-Regeln. Ideal für: Produkteinführungen, Beta-Anmeldungen, Early-Access-Programme, Indie-Projekte.

Was ist Öffnungslisten-Seite (Waitlist Page)?

Diese Fähigkeit (Skill) erstellt eine fokussierte, minimalistische Wartelistenseite für Produkteinführungen, Beta-Anmeldungen und Early-Access-Programme. Sie arbeitet streng templatebasiert: Aus einer gehärteten Vorlage (`assets/template.html`) wird eine `index.html` erzeugt, in die nur validierte und escapede Token eingesetzt werden. Der Skill liest zwingend eine `DESIGN.md` für das gesamte visuelle System (Farben, Schriften, Layout), ersetzt Platzhalter wie `{{PRODUCT_NAME}}` oder `{{BG_EXPRESSION}}` und validiert das Ergebnis gegen eine rigorose Qualitäts-Checkliste, bevor die Seite ausgegeben wird. Dabei werden CSS-Injection und HTML-Injection durch strenge Grammatik- und Sanitization-Regeln verhindert. Die Seite ist ein responsives, zugängliches Single-File-HTML mit mobilem First-Ansatz, eingebetteten SVGs, einer E-Mail-Erfassung als einziger Handlungsaufforderung und dekorativen Animationen, die sich an `prefers-reduced-motion` anpassen. Der Skill eignet sich für Developer-Tools wie Claude Code, Cursor oder Codex, die eine konsistente, qualitätsgesicherte Landingpage ohne manuellen HTML-Code generieren sollen.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/saikirantechy/open-design-ai/tree/HEAD/skills/waitlist-page

In Ihrer bevorzugten KI fragen

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

Dokumentation

Skill: Wartelistenseite

Pre-Launch-Seiten sind der erste Händedruck mit zukünftigen Nutzern. Dieser Skill baut einen fokussierten, ehrlichen Einstieg: Ihre Markenidentität, das, was Sie entwickeln, und einen klaren Weg, sich auf die frühe Liste zu setzen. Keine künstliche Verknappung, keine gefakten Countdowns, keine Inflations-Taktiken – nur ein sauberes, mobiles erstes Gefäß für echtes Interesse.

Arbeitsablauf

Vorbereitung: Gehärtete Vorlage und Markenfundament laden

  1. Markenidentität laden – Lesen Sie DESIGN.md für das Farbsystem, die Schriftkombination und die räumlichen Regeln. Dies ist Ihr Fundament. Eine Wartelistenseite steht und fällt mit der Konsistenz zur Marke, die sie repräsentiert. Wenn DESIGN.md fehlt, bitten Sie den Benutzer, eine bereitzustellen, bevor Sie fortfahren.
  2. Wiederverwendbare Vorlage lesen und kopieren – Lesen Sie assets/template.html. Diese Vorlage ist der gehärtete Keim für alle Ausgaben. Kopieren Sie sie als index.html – Ihre Basis. Schreiben Sie kein HTML von Grund auf und weichen Sie nicht von dieser Struktur ab. Die Vorlage enthält das gesamte erforderliche Layout, die Formularstruktur, Dekorationen, Fokus-Stile und das Barrierefreiheitsgerüst (Scaffolding).

Schritte: Token-Ersetzung mit Validierung und Escaping

  1. Token aus Eingaben zuordnen – Für jeden Platzhalter in der Vorlage (z. B. {{PRODUCT_NAME}}, {{BG_EXPRESSION}}, {{BORDER_EXPRESSION}}, {{LOGO_MARK}}) befolgen Sie die folgenden Ersetzungsregeln:
    • Text-Token ({{PRODUCT_NAME}}, {{TAGLINE}}): HTML-escaped <, >, &, ", ' vor der Einfügung in HTML-Textknoten oder Attributwerte.
    • HTML-Token ({{LOGO_MARK}}): Wenn Textinitialen verwendet werden, standardmäßig HTML-escaped. Bei Verwendung von Inline-SVG müssen Sie dieses streng mit einer Erlaubnisliste (Allowlist) bereinigen: Entfernen Sie <script>-Tags, Ereignis-Handler (on*), <foreignObject>, externe Referenzen (href, xlink:href, url()) und alle nicht erlaubten Attribute/Elemente vor der Einfügung. Wenn das SVG nicht sicher bereinigt werden kann, verwenden Sie als Fallback escapede Textinitialen. Geben Sie niemals rohes, unsanitized, arbiträres 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}}): Müssen strikt einer expliziten Farbgrammatik folgen (#hex, rgb/rgba, hsl/hsla, oklch oder color-mix() unter ausschließlicher Verwendung lokaler Variablen). Lehnen Sie Eingaben, die ;, {}, <, >, Kommentare (/*), @, url( oder externe Referenzen enthalten, hart ab, um CSS-Injection 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. Fügen Sie sie unverändert in CSS-Variablen des :root-Selektors ein. Leiten Sie --success aus DESIGN.md ab, falls vorhanden; andernfalls verwenden Sie nur den erlaubten Fallback #2D6A4F.
    • Schriftnamen-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). Fügen Sie sie unverändert in die Deklarationen --font-display und --font-body ein; fügen Sie KEINE zusätzlichen Anführungszeichen hinzu.
    • Schrift-URL-Token ({{DISPLAY_FONT_URL}}, {{BODY_FONT_URL}}): Leerzeichen müssen für die Google Fonts URL als + codiert werden (z. B. DM+Sans, IBM+Plex+Serif). Validieren Sie vor der Einfügung, dass die URL wohlgeformt ist.
  2. Token-Zuordnungsregeln überprüfen – Alle Farb-Token befinden sich nun in CSS-Variablen:
    • --bg = {{BG_EXPRESSION}} (z. B. #FDE8DF)
    • --fg = {{FG_EXPRESSION}} (z. B. #1A1410)
    • --accent = {{ACCENT_EXPRESSION}} (Markenbadge)
    • --deco = {{DECO_EXPRESSION}} (primäre Dekoration)
    • --deco-stripe = {{STRIPE_EXPRESSION}} (Akzentstreifen)
    • --input-border = {{BORDER_EXPRESSION}} (vollständiger CSS-Ausdruck mit Transparenz)
    • --success = {{SUCCESS_EXPRESSION}} oder Fallback #2D6A4F
    • --btn-label = {{BTN_LABEL_EXPRESSION}} (Schriftfarbe des Buttons 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 dezent mit 12–15 % Deckkraft)
    • --logo-shadow = {{LOGO_SHADOW_EXPRESSION}} (Schatten des Logo-Containers, dezenter Vordergrundton)
    • --logo-fg = {{LOGO_FG_EXPRESSION}} (kontrastierende Textfarbe für Logo-Initialen)
  3. Responsives Layout – Die Vorlage enthält mobile-first Skalierung:
    • 375px: Formular stapelt sich in einer Spalte, Logo schrumpft auf 40px, Dekoration komprimiert sich, kein horizontaler Scrollbalken.
    • 768px: Bequeme Zweispalten-Luft.
    • 1440px+: Zentriertes Layout mit großzügigem Weißraum.
    • Überprüfen Sie, ob der gesamte Text lesbar bleibt und die E-Mail-Eingabe sowie der Button bei 375×667 und 390×844 vollständig sichtbar (nicht abgeschnitten) sind.

Validierung: Gehärtete Qualitätstore vor der Ausgabe durchlaufen

  1. Qualitätscheckliste durchgehen – Lesen Sie references/checklist.md. Validieren Sie jedes P0-Tor vor der Ausgabe:
    • Genau ein CTA (E-Mail-Formular)
    • Kein Countdown-Timer, keine gefälschte soziale Bestätigung, 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()-Wächter
    • Erfolgsmeldung hat role="status" oder aria-live="polite"
    • Alle Farben aus DESIGN.md oder erlaubtem Fallback; keine erfundenen Hex-Werte
    • Jeglicher Benutzertext ist HTML-escaped; Farb-Token entsprechen strikter Grammatik; Schriftarten sind URL-codiert
    • P0 bestehen, sonst nicht ausgeben. Wenn ein P0-Tor fehlschlägt, fragen Sie den Benutzer oder korrigieren Sie die Token-Zuordnungen und versuchen Sie es erneut.
  2. P1-Tore für Qualitätseinreichung überprüfen (empfohlen):
    • Hover- und aktive Zustände auf dem Absende-Button
    • Formularvalidierung mit klarem Feedback
    • Ticker-Animation respektiert prefers-reduced-motion: reduce
    • Alle interaktiven Elemente haben sichtbare Fokus-Stile (input:focus beinhaltet outline)
    • Tastaturunterstützung für Tab/Enter
    • WCAG-AA-Kontrast für Fließtext (≥4,5:1) und Button-Beschriftung (≥4,5:1)
    • Logo-alt/aria-label vorhanden; Ticker hat aria-hidden="true"
    • <html lang=""> ist gesetzt

Ausgabe

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

Qualitätstore

Dieser Skill erzwingt einen gehärteten, templatebasierten Arbeitsablauf zur Sicherstellung der Compliance. Sie müssen diesem Ausführungspfad folgen; Abweichungen von der Vorlage disqualifizieren die Ausgabe.

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):

  • Ein CTA: Das E-Mail-Formular ist das einzige interaktive Element. Keine Navigation, keine sekundären Buttons, keine Social-Links.
  • Logo-Platzierung: Fixiert oben links, entspricht der Akzentfarbe aus DESIGN.md, skaliert auf mobilen Geräten herunter (50px → 40px).
  • Farbkonsistenz: Jede Farbe aus der DESIGN.md-Palette. Einzige erlaubte hartcodierte Ausnahme: #2D6A4F für --success.
  • Keine Anti-Patterns: Kein Countdown-Timer, keine gefälschte soziale Bestätigung, keine Emoji-Symbole, kein Lorem Ipsum.
  • Inhaltsintegrität: Überschrift und Text beziehen sich direkt auf die Eingaben product_name und tagline – kein Fülltext.
  • Mobile-Passform: Kein horizontaler Scrollbalken bei 375px. E-Mail-Eingabe und Absende-Button sind vollständig sichtbar (nicht abgeschnitten) bei 375×667 und 390×844. Vertikaler Überlauf ist scrollbar, nicht versteckt.
  • Typografische Disziplin: Nur Display- + Body-Schriften (2-Schrift-Regel). Einheitliche Größen über Abschnitte hinweg.
  • Formularstruktur: Zwei Felder (Vorname optional, E-Mail erforderlich), checkValidity()-Wächter, Erfolgsmeldung mit role="status".
  • Token-Escaping: Jeglicher vom Benutzer bereitgestellter Text ist HTML-escaped; Farb-Token entsprechen strikter Grammatik und enthalten keine unsicheren Zeichen (;, {}, <, >, /*, @, url(); Schriftnamen sind URL-codiert; {{LOGO_MARK}} sind escapede Textinitialen oder streng bereinigtes Inline-SVG (keine Skripte, keine Ereignis-Handler, kein foreignObject, keine externen hrefs).

P1-Tore (sollten für Qualitätseinreichung bestehen):

  • Hero-Bereich visuell abgegrenzt und oberhalb der Falz.
  • E-Mail-Absende-Button hat Hover- und aktive Zustände.
  • Formularvalidierung gibt klares Feedback.
  • Seite scrollbar (nicht abgeschnitten) bei allen mobilen Viewports; CTA ohne Scrollen sichtbar.
  • Ticker-Animation unter prefers-reduced-motion: reduce pausiert/entfernt.
  • 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, Button-Beschriftung ≥4,5:1.
  • Logo-alt/aria-label vorhanden; Ticker hat aria-hidden="true".
  • <html lang=""> auf den korrekten Sprachcode gesetzt.

Zurückhaltung bei Dekorationen:

  • Unterer Bereich verbessert, ohne abzulenken. Transparenz, dezente Striche, zurückhaltende Animation.
  • Kein Farbverlauf, der mehr als 20 % der Viewport-Höhe einnimmt.
  • Spirale, Streifen, Raster oder Ticker verwenden nur Farben aus DESIGN.md.

Ausgabe

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

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 Beschreibungszeile über dem Artefakt; nichts darunter.

Nach der Ausgabe: Wenn der Benutzer Änderungen wünscht, aktualisieren Sie die index.html direkt und durchlaufen Sie die P0-Checkliste erneut, bevor Sie die nächste Version ausgeben. Überspringen Sie die Validierung bei Iterationen nicht.

Verwandte Skills