Communitygithub.com

marynacleo/build-multilanding

Entwerfen, bauen, prüfen oder skalieren Sie ein datengesteuertes Multi-Segment-Landingpage-System aus einer einzigen Markenvorlage, angetrieben durch Suchintention und einen validierten Marketingkontext.

Was ist build-multilanding?

Dieses Skill ermöglicht es Entwicklern und Agenten, ein einheitliches, wartbares Landingpage-System für bezahlte Werbekampagnen zu erstellen, das auf mehreren Segmenten basiert. Der Schlüssel liegt darin, nicht einfach Kopien einer Seite zu duplizieren, sondern jede URL als eine spezifische Hypothese zu behandeln, die ein Versprechen an eine bestimmte Suchintention hält. Das System arbeitet in klar definierten Phasen (Gates) – von der Strategie und Vertragsdefinition über die repräsentative Konzepterstellung, die Komposition und Skalierung bis hin zu Conversion-Tracking, QA, Launch und Lernschleifen. Es unterstützt Plattformen wie Claude Code und legt großen Wert auf Datenintegrität, indem es zuerst den Projektkontext (z.B. `.agents/product-marketing.md`) liest und niemals eigene Zielgruppen oder Angebote erfindet. Der Skill liefert fertige Deliverables wie Intent-Matrizen, Landing-Verträge, Kampagnen-Manifeste und QA-Ergebnisse und definiert klare Sicherheitsgrenzen, z.B. keine API-Keys in Prompts oder automatische Verbindungen zu Drittsystemen ohne Erlaubnis.

Funktioniert mit✓Claude Code~Codex CLI~Cursor
npx skills add marynacleo/build-multilanding

In Ihrer bevorzugten KI fragen

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

Dokumentation

Build Multilanding

Eine generische Seite ist ein Versprechen an niemanden. Bezahlter Traffic kommt mit einer spezifischen Frage, und die Seite setzt entweder das Gespräch fort, das die Anzeige begonnen hat, oder startet es auf Kosten des Besuchers von Null. Dieses Skill baut die erste Variante: ein wartbares Landing-System, bei dem jede URL ein Versprechen an eine Intention hält und jede Variante eine testbare Hypothese mit einer eigenen Papierspur vom Anzeigenklick bis zum Umsatz ist.

Baue ein System, keine kopierten Seiten. Jede Zeile der Variantentabelle ist eine Marketinghypothese; jede URL ist eine Ansicht desselben Komponentensystems. Der Vorteil für bezahlten Traffic: gehaltene Versprechen erhöhen Relevanz und Vertrauen, was die Conversion steigert und die Kosten pro qualifiziertem Lead senkt. Das ist das gesamte Geschäftsargument, und deshalb beginnt die Arbeit mit Verträgen, nicht mit Text.

Das Skill ist der MOTOR (Methode, Verträge, Tore, Skripte). Das Projekt ist der KRAFTSTOFF (seine eigenen Zielgruppen, Angebote, Keywords, Beweise). Der Motor speichert oder erfindet niemals die Zielgruppen oder Keywords eines Projekts. Lies zuerst references/input-contract.md. Um die gesamte Methode im Kleinen zu sehen, lies references/worked-example.md: ein Angebot, drei Intentionen, drei verschiedene Seiten.

Segmentiere nach Intention, nicht nach Demografie

Die Einheit ist distinkte Suchintention + Bekanntheitsgrad + Angebot + Botschaft = eine Landing-Erfahrung. Mehrere Zielgruppen können sich eine Seite teilen; eine Zielgruppe kann mehrere Seiten benötigen. Gruppiere Keywords nach Bedeutung, nicht nach kleinen String-Varianten. Siehe references/intent-and-message-match.md.

Beginne mit dem Projektkontext

  1. Lies .agents/product-marketing.md (strategische Quelle der Wahrheit) über das Projekt-marketing/source-map.yaml. Fallback: .claude/product-marketing-context.md.
  2. Lies den Kampagnen-Brief für den Launch. Lade nur die verlinkten Intentionen, Botschaften, Angebote und Beweise.
  3. Klassifiziere jede Tatsache als bestätigt / abgeleitet / Hypothese / unbekannt.
  4. Falls ein bestätigtes Angebot, eine Conversion-Aktion, eine Zielgruppen-/Intentions-Hypothese oder der erforderliche Beweis fehlt, erstelle einen Kontextlücken-Bericht und stoppe. Führe scripts/validate_inputs.py aus.

Arbeite in Toren (Gates)

Gate 1: Strategie und Verträge

Erstelle die Intent-Matrix. Schreibe für jede Variante einen Landing-Vertrag, bevor ein Text erstellt wird: was der Suchende will, was die Anzeige verspricht, was die Seite verspricht, ein CTA, erforderlicher Beweis, Einwände, Conversion-Aktion und Wert, Belege.

Gate 2: Repräsentative Konzepte

Erstelle und prüfe 3-5 bewusst unterschiedliche Konzepte, einschließlich des längsten realistischen Texts und eines mobilen Stressfalls. Generiere nicht im großen Stil, bevor dies die Prüfung bestanden hat.

Gate 3: Komponieren und skalieren

Komponiere Seiten mit dem modularen Komponisten, nicht einer festen PAS-Vorlage (references/page-composer.md); wähle die Struktur nach Bekanntheitsgrad. Generiere Varianten aus validierten Feldern (references/variant-schema.md). Lehne doppelte IDs/Slugs, leere Pflichtfelder, ungültige Enums, nicht überprüfbare Behauptungen und nicht übereinstimmende Kampagnen-/Creative-Zuordnungen über scripts/validate_variants.py ab.

Gate 4: Conversion, Tracking, Datenschutz

Mache Formulare zugänglich, prägnant, spamresistent und idempotent. Verkable Attribution mit Geld, nicht mit Formularausfüllungen (references/measurement-and-attribution.md). Sperre alle nicht essentiellen Tags hinter Einwilligung (references/privacy-and-consent.md).

Gate 5: Qualitätssicherung (QA)

Führe references/qa-checklist.md aus: Schema, Routen, Links, Formulare, Analysen, Einwilligung, Indexierung, Metadaten, Leistung (references/performance-gate.md) und Barrierefreiheit. Setze die Indexierung absichtlich pro Variante (references/seo-and-indexation.md).

Gate 6: Launch und Lernen

Generiere das Kampagnen-Manifest (scripts/generate_campaign_manifest.py) und einen Rollback-Plan. Starte das minimal realisierbare Set, in der Regel 1-2 wirklich unterschiedliche Hypothesen pro Intent-Cluster, nicht alle Konzepte. Nach Traffic vergleiche qualifizierte Conversions und nachgelagerten Umsatz, nicht Klicks. Pausiere schwache Hypothesen; speise validierte Erkenntnisse zurück in die Matrix und experiments/landing-experiments.csv.

Angrenzende Skills (träge aufrufen, über Verträge)

Lade nicht jedes Skill für jede Aufgabe. Gib nur das weiter, was der Schritt benötigt, an die eigenen installierten Skills des Projekts:

  • Schmerzpunkte der Zielgruppe und Kundenstimme -> das Forschungs-/Storytelling-Skill des Projekts
  • Angebotsformung -> die Angebotsarbeit des Projekts
  • Kampagnen- und Messaufbau -> paid-ads-launch
  • SEO und Schema für indizierbare Seiten -> seo-optimization
  • Bild-Assets -> web-images
  • FAQ-Blöcke und Einwände -> faq-hub
  • Post-Conversion-Nurture -> brevo-automation, nur als OPTIONALER nachgelagerter Adapter; niemals als harte Abhängigkeit und niemals automatisch verbunden.

Sicherheits- und Autoritätsgrenzen

  • Platziere niemals API-Keys, CRM-Tokens, Zahlungsgeheimnisse oder .env-Inhalte in Prompts, Quelldaten, Seiten, Logs oder Commits. Verwende Platzhalter; der Benutzer gibt Geheimnisse in der vertrauenswürdigen Dienstoberfläche ein.
  • Verbinde CRM, Analysen, Authentifizierung, Anzeigenkonten, Zahlungsanbieter oder deploye/publiziere nicht ohne ausdrückliche Erlaubnis für diesen Dienst und diese Aktion.
  • Behandle Produktionszahlungen, öffentlichen Launch, Kampagnenaktivierung und Bulk-Messaging als separate menschliche Genehmigungstore.
  • Versprichkeine nicht unterstützten Behauptungen (feste Build-Zeit, Kosten, Conversion-Steigerung oder unbegrenzter Maßstab). Respektiere die Einschränkungen des Projekts bezüglich regulierter Behauptungen.
  • Respektiere den Hausstil des Projekts: Sprach- und Zweisprachigkeitsregeln, keine Gedankenstriche in öffentlichen Texten, Überschriften ohne abschließenden Punkt, keine KI-Tool-Spuren in ausgeliefertem Code.

Liefergegenstände

Gib die kleinste nützliche Menge zurück: Intent-/Variant-Matrix; Landing-Verträge; Schema und validierte Datendatei; eine wiederverwendbare Vorlage und Routen-Auflöser; repräsentative Vorschauen; Kampagnen-/URL-Manifest; Formular- und Attributionsvertrag; Einwilligungs-Karte; QA-Ergebnisse; Launch-/Rollback-Checkliste; Experiment-Readout-Plan. Gib an, was verifiziert wurde, was angenommen wird und was noch menschliche Genehmigung benötigt.

Verwandte Skills