Compétence Page d'Atterrissage SaaS
Produire une page d'atterrissage SaaS en une seule page. Agent, suis ce flux de travail précisément.
1. Lire le contexte
Avant d'écrire quoi que ce soit :
- Lis
DESIGN.mddans le répertoire de travail actuel. S'il est absent, arrête-toi et demande-en un. - Identifie la palette de couleurs, les tokens de typographie et les principes de mise en page.
- Note la section "Guide du Prompt Agent" — elle remplace toute instruction ici en cas de conflit.
2. Planifier les sections
Sections obligatoires, dans l'ordre :
- Hero — logo ou mot-symbole, titre (saisie du slogan), sous-titre (1 à 2 phrases), CTA principal, CTA secondaire. Utilise le paramètre
hero_densitycomme espacement vertical en px. - Fonctionnalités — 3 à 6 tuiles de fonctionnalités. Chacune : icône, titre court, corps de 1 à 2 phrases.
- Preuve sociale —
proof_countlogos ou témoignages. Si 0, ignore cette section. - Tarifs — 2 à 3 paliers. Inclus uniquement si
has_pricingest vrai. - CTA de pied de page — large bande colorée avec un bouton d'appel à l'action.
- Pied de page — minimal : liens + copyright.
3. Appliquer le système de design
- Toutes les couleurs doivent provenir des tokens de DESIGN.md. N'invente pas de valeurs hexadécimales.
- Typographie : utilise la police de titre déclarée pour les titres, la police de corps pour tout le reste.
- Mise en page : respecte la grille, la largeur maximale et les règles d'espacement des sections.
- Composants : utilise les motifs de boutons/cartes/champs déclarés. N'ajoute pas d'ombres si la section Profondeur et Élévation de DESIGN.md dit minimal.
- Accent : utilise la couleur d'accent une seule fois dans le hero, une fois dans le CTA du pied de page, et pour tous les liens. Ne sature pas la page.
4. Écrire le fichier
Génère un seul fichier index.html autonome avec :
- Tout le CSS intégré dans un bloc
<style>dans<head>. - Des polices de secours système si les polices de DESIGN.md ne peuvent pas être chargées depuis Google Fonts, etc.
- Aucun JS externe.
- HTML sémantique (
<header>,<main>,<section>,<footer>). - Chaque élément éditable balisé avec
data-od-id="<slug-unique>"afin que le mode commentaire de l'application hôte puisse le cibler.
5. Auto-vérification
Avant de terminer, vérifie :
- Tout le texte est significatif et non pas du lorem ipsum (utilise les entrées
product_nameettagline; génère un texte spécifique plausible pour le reste). - Aucune référence de couleur cassée (chaque valeur de couleur CSS se trouve dans la palette de DESIGN.md ou est une variante alpha/fallback valide).
- Les points de rupture responsive correspondent à la section Comportement Responsive de DESIGN.md.
- La page a un bon rendu à 1440w, 768w et 375w (simule mentalement).
- La couleur d'accent n'est pas utilisée plus de deux fois au total.
6. Terminé
Écris uniquement index.html. Ne génère pas de fichier CSS, JS ou README séparé.
Pour les auteurs de compétences qui lisent ceci comme référence
C'est une compétence minimale mais complète. Structure :
saas-landing-skill/
├── SKILL.md ← vous êtes ici
└── assets/
└── base.html (modèle de démarrage optionnel ; cette compétence n'en utilise pas)
Points à noter :
- Le bloc front-matter
od:est des métadonnées de compatibilité conservées. Clean Design lit ses entrées typées, ses curseurs, ses métadonnées d'aperçu et ses indices de capacité. - Le flux de travail après le front-matter est du Markdown simple que l'agent lit comme son prompt système.
- DESIGN.md est traité comme un collaborateur, pas comme une surcharge. La compétence donne à l'agent l'autorité de passer outre lorsque le brief est en conflit, mais jamais d'inventer de nouveaux tokens.
- Le balisage
data-od-idconnecte les éléments au mode commentaire local. Les compétences qui souhaitent la compatibilité avec le mode commentaire doivent annoter leur sortie.
Voir ../../skills-protocol.md pour le protocole complet.