Aston1690/landing-page-skill

Constructeur de Page d'Atterrissage

Construisez la page finie, pas une invite, un wireframe, un moodboard ou un échantillon partiel. Livrez du code fonctionnel soutenu par une QA réelle dans un navigateur. La qualité premium signifie des décisions propres à la marque, une excellente typographie/composition/imagerie, une clarté de conversion, un savoir-faire responsive, un mouvement intentionnel, l'accessibilité, la performance et l'intégrité factuelle.

À l'invocation, lisez metadata.version ci-dessus et enregistrez landing-page v<version> dans le brief du projet. Répétez cette version exacte dans le rapport d'achèvement afin que chaque page générée reste traçable jusqu'à la version du skill qui l'a produite.

Contrat de livraison strict

Livrez :

• une implémentation responsive complète dans un projet nouveau ou explicitement approuvé ;
• le texte exact fourni par l'utilisateur, préservé mot pour mot ; n'écrivez, ne modifiez et ne restructurez le texte que lorsque l'utilisateur le demande explicitement ;
• un système de marque fonctionnel, un manifeste des actifs/notes de provenance et des notes d'intégration ;
• des images de production plutôt que des espaces réservés lorsque la génération d'images ou des actifs approuvés sont disponibles ;
• une chorégraphie GSAP intentionnelle, un mouvement de section déclenché par le défilement et des micro-interactions de contrôle par défaut pour les constructions complètes, sous réserve des exceptions de mode documentées ;
• des métadonnées SEO/OG, une structure sémantique, des états d'accessibilité et des médias optimisés ;
• la fenêtre d'affichage de l'utilisateur testée dans le navigateur, les limites des points de rupture, la tablette, le mobile étroit et les états mobiles courants ;
• un déploiement Vercel par défaut, suivi d'une vérification en direct sur desktop/mobile ; ne demandez que lorsque l'authentification ou un autre blocage réel empêche le déploiement.

N'inventez jamais d'affirmations, de métriques, de références, de témoignages, de logos clients, de formulations réglementées, de produits, de captures d'écran, de coordonnées ou de succès de formulaire.

Routage de compétence requis

Chargez avant de construire :

1. frontend-design pour la direction artistique et la thèse visuelle spécifique à la marque.
2. design-taste-frontend pour une implémentation anti-médiocre et une pré-vérification responsive.
3. imagegen-frontend-web uniquement lorsque la matrice de mode autoritaire la résout sur : ambiguïté visuelle, direction dominée par l'image, concepts demandés ou actifs approuvés insuffisants.
4. Ce skill landing-page pour l'orchestration, la construction, la QA et la livraison.
5. La capacité de génération d'images de production disponible ou media-use lorsque l'inventaire des actifs officiels/fournis ne peut pas soutenir la direction visuelle approuvée.
6. imagegen-frontend-mobile uniquement pour des écrans d'application conceptuels clairement étiquetés ou des concepts d'écran de produit approuvés sur une page marketing d'application mobile. Ne l'utilisez jamais pour concevoir un web mobile responsive ou pour suggérer que des écrans générés sont des fonctionnalités de produit vérifiées.

Lisez references/frontend-skill-stack.md pour les règles de conflit de pile.

Décision du mode de projet

Lisez references/policy-matrix.md. C'est la seule source autoritaire pour le routage d'Imagegen, GSAP, la préservation, l'approbation, la sécurité d'intégration, la couverture de la fenêtre d'affichage et les portes de qualité. Sélectionnez exactement un de ses six modes et enregistrez les décisions résolues ainsi que la justification. Aucune prose ailleurs ne peut remplacer la matrice.

Lorsque l'utilisateur dit « from scratch » ou « ne touchez pas aux constructions précédentes », créez un projet nommé de manière unique et ne modifiez jamais les travaux antérieurs.

Phase 1 : Collecte des informations d'invocation

Posez une question courte à la fois. Ne combinez jamais plusieurs champs dans un paragraphe ou un questionnaire. Attendez la réponse avant de poser la question suivante réellement nécessaire.

Utilisez cet ordre, en sautant tout ce qui a déjà été fourni ou peut être déduit en toute sécurité :

1. Pour quelle entreprise/produit et site web officiel est-ce ?
2. Où se trouve le texte final approuvé par l'utilisateur ? Le texte est requis et préservé exactement.
3. Où se trouvent le guide de marque, le logo et les actifs approuvés, s'ils existent ?
4. S'agit-il d'une nouvelle construction séparée ou d'une modification de projet existant ?
5. Renseignez-vous sur le public, la destination du CTA, l'intégration ou la conformité uniquement si le site/texte fourni n'y répond pas et que cela bloque matériellement la mise en œuvre.

Ne demandez pas si le texte peut être réécrit. N'offrez pas d'écrire ou de modifier le texte. L'écriture, la modification ou la restructuration n'est activée que par une demande explicite de l'utilisateur. Ne demandez pas s'il faut déployer ; le déploiement Vercel est la valeur par défaut.

Lisez references/intake-brand-assets.md et suivez sa hiérarchie de sources, sa récupération de logo, son repli sur le guide de marque, sa conformité, son intégration et ses règles de provenance.

Phase 2 : Preuve et audit de marque

Après la collecte :

1. Lisez les instructions du projet, le brief/contenu approuvé, les approbations antérieures et les références fournies.
2. Ouvrez le site web officiel dans un vrai navigateur lorsqu'il existe ; sinon, enregistrez la condition de nouvelle marque/absence de site et continuez à partir du contexte fourni.
3. Extrayez les polices/couleurs calculées, les variantes de logo, l'espacement, la grille, les rayons, les boutons, les icônes, l'imagerie, la navigation, les formulaires, le pied de page, le comportement responsive et le mouvement.
4. Récupérez et vérifiez visuellement un logo SVG officiel ou un PNG haute résolution transparent. Si un logo existant n'est pas disponible, demandez-le à l'utilisateur. Si aucun logo n'existe, confirmez si un traitement de nom de produit en texte brut est acceptable et enregistrez que la conception du logo est hors de portée. Ne redessinez jamais et ne générez jamais un logo client.
5. Extrayez le texte du document et les images ensemble ; préservez les relations image-texte.
6. Créez un manifeste d'actifs vérifié.
7. Si aucun guide de marque n'existe, créez un guide de projet compact rédigé par l'agent et étiquetez-le honnêtement.

Pour les travaux réglementés/sensibles à la confiance, préservez les avis de non-responsabilité, licences, formulations de récompenses, éligibilité, consentement et qualifications fournis, sauf si des modifications sont explicitement autorisées.

Phase 3 : Architecture du contenu et de la conversion

Créez un manifeste de contenu avant la conception :

• titre/corps/CTA/affirmation basés sur la source pour chaque section ;
• fonction de la section : accrocher, expliquer, prouver, différencier, répondre ou convertir ;
• source de preuve ou espace réservé non résolu ;
• visuel/média prévu et statut de l'actif ;
• chemin de conversion principal et destination du CTA.
• approval_status et verification_status suivis séparément pour les affirmations factuelles, les témoignages, les métriques, les références et les formulations réglementées.

La politique de contenu par défaut est la préservation exacte du texte fourni par l'utilisateur. authorized_editing ou agent_draft_unapproved ne peut être sélectionné que lorsque l'utilisateur demande explicitement une édition ou une rédaction. Les brouillons d'agent restent non approuvés et ne peuvent pas contenir d'affirmations non étayées.

N'utilisez que les sections qui répondent à une véritable question de conversion. N'incluez pas mécaniquement héros + confiance + trois cartes + témoignages + FAQ. Une idée principale par section. Préservez l'architecture de l'information approuvée dans les projets existants, sauf autorisation de la modifier.

Phase 4 : Brief de conception et Imagegen

Rédigez le brief pré-code :

• public, objectif de conversion, source de vérité, mode de projet ;
• une thèse visuelle spécifique au sujet et une colonne vertébrale narrative ;
• palette, rôles typographiques, grille/espacement, grammaire des formes/composants ;
• qualité d'image, carte des actifs, plan de génération d'images, élément signature ;
• comportement au premier pli et des sections complexes sur desktop/tablet/mobile ;
• storyboard de mouvement avec un objectif pour chaque séquence ;
• liste d'évitement explicite et critères d'acceptation.

Rejetez la direction si elle pourrait être réutilisée sans changement pour une marque sans rapport.

Lorsque la matrice de politique active Imagegen, lisez references/imagegen-production.md :

1. Utilisez imagegen-frontend-web et annoncez le nombre de références sélectionné.
2. Générez et inspectez une référence horizontale séparée pour chaque section sélectionnée.
3. Gardez un univers de marque tout en faisant varier la composition et la densité.
4. Verrouillez la direction via soit un point de contrôle utilisateur (compromis demandé/conséquentiel) soit une porte d'acceptation d'agent (autonome, réversible, basé sur la source). Enregistrez quel mode d'approbation a été utilisé.
5. Générez/résolvez les actifs de production séparément aux rapports d'aspect réels, sans texte, logos, affirmations ou filigranes intégrés. L'interface utilisateur est exclue sauf pour les écrans d'application conceptuels clairement étiquetés et acheminés par la politique.
6. Inspectez, recadrez, optimisez, ajoutez du texte alternatif et enregistrez la provenance.

Jugez l'imagerie par son utilité narrative, sa répétition visible, sa spécificité à la marque et la qualité des actifs plutôt que par des quotas. Une page délibérément dominée par la typographie ou riche en actifs peut sauter la génération avec une justification enregistrée ; une page accidentellement lourde en texte ou générique de stock échoue.

Phase 5 : Implémentation statique et approbation

Choisissez la pile la plus simple qui satisfait le brief :

• préservez le framework, le style, le routage, les composants, l'analytique et le pipeline d'actifs d'un dépôt existant ;
• utilisez du HTML sémantique, du CSS externe et du JS externe pour les pages véritablement statiques ;
• utilisez React/Vite/Next uniquement lorsque l'architecture existante, les composants réutilisables, les intégrations, l'état ou l'interaction complexe le justifient ;
• vérifiez les dépendances avant de les importer.

Terminez la page statique avant le mouvement. Elle doit déjà avoir :

• un texte correct, un logo/actifs vérifiés, des destinations CTA réelles ;
• des jetons cohérents et une grammaire des composants ;
• une typographie contrôlée et des sauts de ligne à la fenêtre d'affichage de l'utilisateur ;
• une variété de composition suffisante pour éviter la répétition visible, sans quotas de disposition numériques ;
• des recadrages d'images intentionnels et des dimensions réservées ;
• une navigation fonctionnelle, des formulaires/liens, des états de focus et d'interaction ;
• un ré-écoulement responsive délibéré plutôt qu'un empilement accidentel ;
• aucun média cassé, débordement, coupure, fausse UI, espaces réservés ou vestiges de source.

Faites une QA par capture d'écran et corrigez la composition statique avant de commencer GSAP.

Phase 6 : Passe de production GSAP

Lisez references/gsap-motion.md pour chaque construction complète et refonte substantielle ; planifiez le mouvement dans le brief et implémentez-le après la QA de composition statique.

Le mouvement est activé par défaut pour les constructions complètes sous la matrice de politique. Livrez une chorégraphie de héros, un mouvement de section spécifique au contenu et un retour pour les contrôles interactifs existants. Adaptez l'intensité à la marque. Une contrainte statique/d'exécution/de préservation valide peut modifier cela ; l'absence de demande d'animation explicite n'est pas une raison pour sauter. Enregistrez les observations d'exécution dans QA/motion-review.md ; les captures d'écran seules ne peuvent pas passer l'acceptation du mouvement.

Gardez le contenu critique visible si les scripts échouent ou se chargent lentement. N'utilisez pas d'écouteurs de défilement de fenêtre bruts. Vérifiez l'animation sous un onglet actif car les onglets en arrière-plan limitent les temporisateurs.

Phase 7 : QA du navigateur

Exécutez la page localement et inspectez les captures d'écran et les états réels :

• la fenêtre d'affichage réelle de l'utilisateur, chaque limite de point de rupture de mise en page, une tablette, un mobile étroit et un mobile courant ; 375px/390px sont les valeurs par défaut plutôt que des exigences universelles ;
• le premier pli, plusieurs sections en milieu de page, le CTA/pied de page final ;
• les états de mouvement actifs et au repos plus le mouvement réduit ;
• les menus, les ancres, les formulaires, les accordéons, les onglets, les carrousels et l'utilisation du clavier ;
• les familles/épaisseurs de polices calculées là où la typographie est importante ;
• le chargement/dimensions naturelles des images, le recadrage, le texte alternatif ;
• le débordement horizontal, le clipping, les erreurs de console/réseau, les risques CLS ;
• la destination du formulaire/CTA et le comportement de succès/erreur. Utilisez des points de terminaison sandbox/test et des données synthétiques. Ne soumettez jamais de prospects en direct, d'enregistrements CRM, de paiements, d'e-mails ou d'événements analytiques sans approbation explicite.

Corrigez les défauts avant la remise. Une construction qui passe n'est pas une QA de conception.

Phase 8 : Porte de qualité premium

Lisez references/premium-quality-gate.md et évaluez avec des preuves :

1. Spécificité de la marque
2. Conversion et récit
3. Typographie
4. Composition et espacement
5. Imagerie et direction artistique
6. Artisanat des composants
7. Conception responsive
8. Mouvement
9. Accessibilité et intégrité
10. Performance et préparation à la production

Utilisez des vérifications critiques binaires plus des ancres 0/5/8/10 étayées par des preuves. Aucune catégorie applicable ne peut obtenir un score inférieur à 8/10 ; visez 9+ au total. N/A est autorisé uniquement avec une justification écrite, y compris le mouvement sur une page délibérément statique. Citez des preuves de capture d'écran, DOM, audit ou test pour chaque score. Tout critère de rejet critique fait échouer la page, quelle que soit la moyenne. Corrigez la catégorie applicable la plus faible, réexécutez les preuves et réévaluez.

Si l'utilisateur qualifie le travail de basique, générique ou mauvais, invalidez la direction artistique actuelle. Arrêtez les micro-ajustements, identifiez la cause systémique, réinitialisez la thèse/référence/premier pli, reconstruisez et refaites la QA.

Phase 9 : SEO, performance et déploiement

Avant la livraison :

• un H1, une structure de titres logique, un titre, une description, un canonical, des métadonnées OG et une favicon ;
• des images responsive optimisées, une priorité/préchargement du héros si approprié, un chargement différé des médias sous le pli ;
• maximum deux familles de polices justifiées et seulement les épaisseurs requises ;
• des éléments sémantiques, des étiquettes, du texte alternatif, du contraste, du focus, un support clavier et de mouvement réduit ;
• aucune fausse intégration, affirmation non vérifiée, erreur de console, lien brisé ou secret non résolu ;
• des notes de source avec la provenance du texte/actifs/logo/génération d'images/intégration.

Déployez chaque page d'atterrissage terminée sur Vercel par défaut en utilisant la configuration Vercel existante du projet ou un nom de projet nouveau et isolé. Si l'authentification, la propriété, les secrets ou un autre blocage réel empêche le déploiement, demandez uniquement ce blocage. Vérifiez l'alias en direct exact dans un vrai navigateur sur desktop et mobile ; vérifiez les marqueurs de titre/contenu, les actifs, la navigation, les formulaires, le débordement, la console, le mouvement et la propriété de l'alias. Le succès CLI ou le HTTP 200 seul n'est pas une preuve.

Liste de rejet anti-médiocre

Rejetez :

• les dégradés AI génériques violets/bleus, les blobs, les cartes en verre sans signification, le remplissage 3D flottant ;
• les poignées de main de stock sans rapport, les faux tableaux de bord, les graphiques/KPI inventés, les preuves sociales factices ;
• les titres surdimensionnés ou condensés sans raison de marque, le texte de corps minuscule, les sauts de ligne maladroits ;
• les rangées de trois cartes identiques, les familles de mise en page répétées, les pilules/rayons/ombres excessifs ;
• le texte comme « révolutionner », « libérer », « nouvelle génération », « sans couture » ou les étiquettes CTA vagues ;
• les mots/logos/UI générés à l'intérieur des images de production ;
• le mobile qui n'est qu'un desktop empilé verticalement ;
• l'animation utilisée pour cacher une conception statique faible ;
• les éléments décoratifs dont le seul travail est de remplir l'espace.

Préférez les actifs de marque vérifiés, l'imagerie spécifique au sujet, la typographie contrôlée, la composition variée mais cohérente, une signature mémorable, un espace négatif intentionnel, une preuve claire et un chemin de conversion décisif.

Carte de référence

Besoin	Lire
Routage des modes de projet autoritaire	references/policy-matrix.md
Collecte, site/marque/logo/contenu/actifs/intégrations	references/intake-brand-assets.md
Routage/conflits de pile frontend	references/frontend-skill-stack.md