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
- Lies
.agents/product-marketing.md(strategische Quelle der Wahrheit) über das Projekt-marketing/source-map.yaml. Fallback:.claude/product-marketing-context.md. - Lies den Kampagnen-Brief für den Launch. Lade nur die verlinkten Intentionen, Botschaften, Angebote und Beweise.
- Klassifiziere jede Tatsache als bestätigt / abgeleitet / Hypothese / unbekannt.
- 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.pyaus.
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.