Communitygithub.com

marynacleo/build-multilanding

Concevez, construisez, auditez ou déployez un système de pages d'atterrissage multi-segments basé sur une seule marque, piloté par l'intention de recherche et un contexte marketing validé.

Qu'est-ce que build-multilanding ?

Cette compétence permet de concevoir et de déployer un système de pages d'atterrissage modulaire et maintenable, optimisé pour le trafic payant (Google, Meta, LinkedIn). Au lieu de créer des pages copiées, elle construit un moteur unique où chaque variante est une hypothèse marketing testable, avec sa propre traçabilité de l'annonce au revenu. Le moteur lit d'abord le contexte marketing du projet (`.agents/product-marketing.md`) pour ne jamais inventer d'audiences, d'offres ou de preuves. Le travail progresse par étapes (gates) : stratégie et contrats, concepts représentatifs, composition et mise à l'échelle, conversion et suivi, QA, lancement et apprentissage. Chaque variante est une combinaison d'intention de recherche + stade de notoriété + offre + message. Le système rejette les identifiants dupliqués, les champs vides, les affirmations invérifiables et les mappages campagne/créatif incohérents. Les livrables incluent une matrice d'intention, des contrats d'atterrissage, un schéma de données, un template réutilisable, un manifeste de campagne, des résultats de QA et un plan d'expérimentation. La compétence est conçue pour les plateformes comme Claude Code, Cursor ou Codex, et est invoquée via des contrats purs sans dépendances automatiques.

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add marynacleo/build-multilanding

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Construire un système multi-atterrissage (Multilanding)

Une page générique est une promesse à personne. Le trafic payant arrive avec une question spécifique, et la page soit continue la conversation que l'annonce a commencée, soit elle la redémarre à zéro aux dépens du visiteur. Cette compétence construit le premier type : un système d'atterrissage maintenable où chaque URL tient une promesse à une intention, et chaque variante est une hypothèse testable avec sa propre traçabilité, du clic sur l'annonce au revenu.

Construisez un système, pas des pages copiées. Chaque ligne du tableau de variantes est une hypothèse marketing ; chaque URL est une vue du même système de composants. La contrepartie pour le trafic payant : des promesses tenues augmentent la pertinence et la confiance, ce qui élève la conversion et réduit le coût de chaque lead qualifié. C'est l'ensemble du business case, et c'est pourquoi le travail commence par des contrats, pas par la rédaction.

La compétence est le MOTEUR (méthode, contrats, portes, scripts). Le projet est le CARBURANT (ses propres audiences, offres, mots-clés, preuves). Le moteur ne stocke ni n'invente les audiences ou les mots-clés d'un projet. Lisez d'abord références/contrat-d-entrée.md. Pour voir la méthode en miniature, lisez références/exemple-pratique.md : une offre, trois intentions, trois pages différentes.

Segmentez par intention, pas par démographie

L'unité est intention de recherche distincte + stade de notoriété + offre + message = une expérience d'atterrissage. Plusieurs audiences peuvent partager une page ; une audience peut avoir besoin de plusieurs pages. Regroupez les mots-clés par sens, pas par de légères variations de chaîne. Voir références/intention-et-correspondance-de-message.md.

Commencez par le contexte du projet

  1. Lisez .agents/product-marketing.md (source stratégique de vérité) via le fichier marketing/source-map.yaml du projet. Fallback : .claude/product-marketing-context.md.
  2. Lisez le brief de campagne pour le lancement. Chargez uniquement les intentions, messages, offres et preuves liés.
  3. Classez chaque fait comme : confirmé / dérivé / hypothèse / inconnu.
  4. Si une offre confirmée, une action de conversion, une hypothèse audience/intention, ou la preuve requise est manquante, produisez un rapport de lacunes contextuelles et arrêtez-vous. Exécutez scripts/validate_inputs.py.

Travaillez par étapes (gates)

Étape 1 : stratégie et contrats

Construisez la matrice d'intentions. Pour chaque variante, rédigez un contrat d'atterrissage avant toute copie : ce que l'internaute cherche, ce que l'annonce promet, ce que la page promet, un seul CTA, preuve requise, objections, action de conversion et valeur, preuves.

Étape 2 : concepts représentatifs

Construisez et révisez 3 à 5 concepts délibérément différents, y compris la copie la plus longue réaliste et un cas de stress mobile. Ne générez pas à l'échelle avant que cela ne passe la révision.

Étape 3 : composez et passez à l'échelle

Composez les pages avec le compositeur modulaire, pas un modèle PAS fixe (références/compositeur-de-page.md) ; choisissez la structure en fonction du stade de notoriété. Générez des variantes à partir de champs validés (références/schéma-des-variantes.md). Rejetez les identifiants/slugs dupliqués, les champs obligatoires vides, les énumérations invalides, les affirmations invérifiables et les mappages campagne/créatif incohérents via scripts/validate_variants.py.

Étape 4 : conversion, suivi, confidentialité

Rendez les formulaires accessibles, concis, résistants aux spams et idempotents. Câblez l'attribution à l'argent, pas aux remplissages de formulaires (références/mesure-et-attribution.md). Verrouillez tous les tags non essentiels derrière le consentement (références/confidentialité-et-consentement.md).

Étape 5 : QA

Exécutez références/liste-de-vérification-QA.md : schéma, routes, liens, formulaires, analytics, consentement, indexation, métadonnées, performance (références/porte-de-performance.md) et accessibilité. Définissez l'indexation intentionnellement par variante (références/SEO-et-indexation.md).

Étape 6 : lancement et apprentissage

Générez le manifeste de campagne (scripts/generate_campaign_manifest.py) et un plan de rollback. Lancez l'ensemble minimum viable, généralement 1 à 2 hypothèses vraiment différentes par groupe d'intention, pas tous les concepts. Après le trafic, comparez la conversion qualifiée et le revenu en aval, pas les clics. Mettez en pause les hypothèses faibles ; alimentez les leçons vérifiées dans la matrice et experiments/landing-experiments.csv.

Compétences adjacentes (invoquées paresseusement, via des contrats)

Ne chargez pas chaque compétence pour chaque tâche. Déléguez uniquement ce dont l'étape a besoin, aux compétences installées du projet :

  • douleurs de l'audience et voix du client -> la compétence recherche/storytelling du projet
  • façonnage de l'offre -> le travail d'offres du projet
  • mise en place de la campagne et de la mesure -> paid-ads-launch
  • SEO et schéma des pages indexables -> seo-optimization
  • ressources images -> web-images
  • blocs FAQ et objections -> faq-hub
  • nurturing post-conversion -> brevo-automation, en tant qu'adaptateur en aval OPTIONNEL uniquement ; jamais une dépendance dure, et jamais connecté automatiquement.

Limites de sécurité et d'autorité

  • Ne placez jamais de clés API, tokens CRM, secrets de paiement ou contenus .env dans les prompts, les sources de données, les pages, les journaux ou les commits. Utilisez des espaces réservés ; l'utilisateur saisit les secrets dans l'interface de service de confiance.
  • Ne connectez pas CRM, analytics, authentification, comptes publicitaires, fournisseurs de paiement, ou ne déployez/publiez pas sans autorisation explicite pour ce service et cette action.
  • Traitez les paiements en production, le lancement public, l'activation de campagne et les messages de masse comme des points de validation humaine séparés.
  • Ne promettez pas d'affirmations non étayées (temps de construction fixe, coût, hausse de conversion ou échelle illimitée). Respectez les restrictions de déclarations réglementées du projet.
  • Respectez le style de la maison du projet : règles de langue et bilingues, pas de tirets cadratins dans la copie publique, titres sans point final, aucune trace d'outils d'IA dans le code livré.

Livrables

Retournez l'ensemble le plus petit possible : matrice d'intentions/variantes ; contrats d'atterrissage ; schéma et fichier de données validé ; un template réutilisable et un résolveur de route ; des aperçus représentatifs ; un manifeste de campagne/URL ; un contrat de formulaire et d'attribution ; une carte de consentement ; des résultats de QA ; une liste de vérification de lancement/rollback ; un plan de lecture d'expériences. Indiquez ce qui a été vérifié, ce qui est supposé, et ce qui nécessite encore l'approbation humaine.

Skills associés