aurora-ember-bio-lab/splatstudio

Skill Page d'Accueil SaaS

Produis une page d'accueil SaaS one-page. Agent, suis ce workflow exactement.

1. Lire le contexte

Avant d'écrire quoi que ce soit :

• Lis DESIGN.md dans le répertoire de travail courant. S'il manque, 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 "Agent Prompt Guide" — elle remplace toute instruction ici en cas de conflit.

2. Planifier les sections

Sections obligatoires, dans l'ordre :

1. Hero — logo ou marque verbale, titre (saisie du slogan), sous-titre (1–2 phrases), CTA principal, CTA secondaire. Utilise le paramètre hero_density comme padding vertical en px.
2. Fonctionnalités — 3 à 6 tuiles de fonctionnalités. Chacune : icône, titre court, corps de 1 à 2 phrases.
3. Preuve sociale — proof_count logos ou témoignages. Si 0, saute cette section.
4. Tarifs — 2 à 3 formules. Inclus uniquement si has_pricing est vrai.
5. CTA de pied de page — large bande colorée avec un bouton d'appel à l'action unique.
6. 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 d'affichage 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/saisies déclarés. N'ajoute pas d'ombres si DESIGN.md indique "Profondeur et élévation : 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

Produis un seul fichier index.html autonome avec :

• Tout le CSS embarqué dans un bloc <style> à l'intérieur de <head>.
• Polices de secours système si les polices de DESIGN.md ne sont pas chargeables 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>" pour que le mode commentaire de l'application hôte puisse le cibler.

5. Auto-vérification

Avant de terminer, vérifie :

• Tout le texte a un sens, n'est pas du lorem ipsum (utilise les saisies product_name et tagline ; génère un contenu spécifique plausible pour le reste).
• Aucune référence de couleur cassée (chaque valeur CSS de couleur est dans la palette de DESIGN.md ou une variante alpha/fallback valide).
• Les points de rupture responsive correspondent à la section "Comportement Responsive" de DESIGN.md.
• La page rend bien à 1440w, 768w et 375w (simule mentalement).
• L'accent est utilisé au maximum deux fois au total.

6. Terminé

Écris uniquement index.html. Ne génère pas de fichier CSS séparé, de fichier JS ou de README.

---

Pour les auteurs de skills lisant ceci comme référence

Ceci est un skill minimal mais complet. Structure :

saas-landing-skill/
├── SKILL.md    ← vous êtes ici
└── assets/
    └── base.html    (template de démarrage optionnel ; ce skill n'en utilise pas)

Choses à noter :

• Le bloc front-matter od: est optionnel pour la compatibilité avec Claude-Code uniquement, mais son ajout active les entrées typées, curseurs, métadonnées de prévisualisation et le gating de capacités d'OD.
• Le workflow sous 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. Le skill donne à l'agent l'autorité de surcharger lorsque le brief entre en conflit, mais jamais d'inventer de nouveaux tokens.
• Le balisage data-od-id est la façon dont nous connectons les éléments au mode commentaire. Les skills qui veulent la compatibilité avec le mode commentaire doivent annoter leur sortie.

Voir ../../docs/skills-protocol.md pour le protocole complet.