gaznil/web-skills

Clone du design d'un site web avec Firecrawl

À utiliser lorsque l'utilisateur souhaite transformer une URL en un fichier de système de design pratique que les agents peuvent utiliser immédiatement.

Résultat par défaut : extraire le système de design de n'importe quel site web en une ligne et le formater en DESIGN.md.

La compétence doit ressembler à un flux de travail léger autour de l'extraction Firecrawl : rassembler le contenu visible de la page, sa structure, ses métadonnées, ses liens et les signaux visuels disponibles, puis synthétiser ces résultats en un fichier markdown de système de design propre.

Entretien de prise en main

Déduire l'URL source, la stack cible et si une implémentation est demandée à partir du contexte. Si l'utilisateur fournit une URL et demande un système de design, procéder immédiatement.

Poser au maximum 1 à 3 questions concises uniquement en cas de blocage, comme l'URL du site web, s'il faut produire uniquement DESIGN.md ou aussi implémenter, ou une stack cible requise.

Utiliser l'interface utilisateur normale de l'agent hôte ou son modal. Ne pas nommer de fonction de question spécifique à un environnement.

Plan de collecte Firecrawl

Utiliser Firecrawl via l'interface en ligne de commande ou un outil équivalent. Toujours commencer par deux extractions parallèles de l'URL fournie :

1. Les formats branding et images ensemble pour les tokens de design structurés et l'ensemble complet des images de la page.
2. Une capture d'écran plein écran pour le contexte visuel.

Exemple :

firecrawl scrape "https://exemple.com" --format branding,images -o ".firecrawl/exemple-branding.json" --pretty &
firecrawl scrape "https://exemple.com" --full-page-screenshot -o ".firecrawl/exemple-screenshot.png" &
wait

Combiner branding et images en un seul appel coûte toujours un seul crédit et est obligatoire : le bloc branding ne remonte que les ressources de marque organisées (logo, favicon, ogImage, logoHref), donc sans images, l'agent manquera les images de contenu réelles de la page (héros, photos de produits, diapositives de carrousel, visuels de fonctionnalités, illustrations, photos d'accompagnement, œuvres de fin de page, etc.). Sur une page produit comme tesla.com/cybertruck, le bloc branding n'a pas de héros — seul images renvoie le héros principal du Cybertruck (par exemple Cybertruck-Hero-Desktop-NA-SA-APAC.png) et le reste des photographies de la page.

Si l'extraction de la capture d'écran renvoie une URL d'image distante (par exemple un lien de stockage signé) au lieu d'un fichier local, la télécharger vers le même chemin .firecrawl/ afin que DESIGN.md puisse référencer une ressource locale stable.

Utiliser la sortie structurée branding comme source principale pour les couleurs, la typographie, les composants, les ressources de marque (logo, favicon, ogImage), la personnalité et les notes de confiance. Utiliser la liste images comme source de vérité pour les images de contenu de la page — photographies héros, photos de produits, carrousels, visuels de fonctionnalités, illustrations et graphiques décoratifs. Utiliser la capture d'écran comme référence visuelle principale pour la mise en page, la hiérarchie et l'impression générale. Ajouter des formats supplémentaires uniquement lorsque ceux-ci sont insuffisants pour l'artefact final.

Collecter :

• les données de marque pour les couleurs, la typographie, l'espacement, les boutons, les logos, les images de marque, la personnalité et la confiance
• la liste complète des images pour les images héros, produits, fonctionnalités et sections au-delà des ressources de marque organisées
• une capture d'écran plein écran sauvegardée localement dans .firecrawl/ afin de pouvoir l'intégrer dans DESIGN.md
• le markdown de la page pour les titres, la hiérarchie du texte, les appels à l'action, la navigation et l'ordre des sections si nécessaire
• les métadonnées et liens pour obtenir des indices sur la marque, le produit et l'objectif de la page si nécessaire
• le HTML uniquement lorsque la sortie du branding, la liste des images et la capture d'écran sont insuffisants pour déduire les classes, les noms de polices, les variables CSS ou la structure des composants
• les pages liées uniquement lorsque l'utilisateur demande un système de site plus large

Ne pas sur-explorer par défaut. La première version doit être utile à partir d'une seule page représentative.

Quoi extraire

Déduire et documenter le langage de design du site :

• couleurs : primaires, secondaires, accents, arrière-plans, bordures, texte, états
• typographie : familles de polices si détectables, échelle typographique, graisses, hauteurs de ligne, traitement des titres/corps
• espacement : largeurs de conteneur, rythme des sections, espacements de grille, échelle de remplissage, densité
• mise en page : structure de la page, motifs héros, cartes, grilles, navigation, pied de page, hypothèses responsives
• composants : boutons, champs de saisie, cartes, badges, éléments de navigation, blocs de prix, témoignages, rangées de fonctionnalités, formulaires
• imagerie et icônes : style, langage des formes, traitement des illustrations/photos, contraintes du logo ; extraire les images héros, produits, fonctionnalités et sections représentatives de la liste complète des images plutôt que de se fier à branding.images, qui ne contient que logo, favicon, ogImage et logoHref
• mouvement et interaction : états de survol, transitions, style d'animation lorsqu'il est observable ou déductible
• voix et motifs de contenu : formulation des appels à l'action, style des titres, rythme du texte produit

Lorsqu'une valeur ne peut pas être mesurée exactement à partir de la sortie de l'extraction, l'étiqueter comme déduite et donner une approximation pratique.

Travail parallèle

Si approprié, utiliser des sous-agents ou des exécuteurs de tâches parallèles équivalents. Les répartitions naturelles incluent une page par chercheur pour les sites multipages, ou un réviseur chacun pour les couleurs, la typographie, l'espacement et les composants.

Chaque chercheur parallèle doit renvoyer les URL sources, les preuves extraites, les tokens de design déduits et les notes de confiance.

Livrable final

Créer ou retourner un DESIGN.md avec cette structure. Intégrer la capture d'écran plein écran près du haut afin qu'un agent de codage dispose du contexte visuel en plus des tokens.

# DESIGN.md : [Site source]

## Source
- URL : [URL source]
- Date de capture : [date]
- Preuves : [extraction/capture d'écran/html/liens utilisés]

## Capture d'écran de référence
![Capture d'écran plein écran de [Site source]](./.firecrawl/[source]-screenshot.png)

Utiliser cette capture d'écran comme source de vérité visuelle pour la mise en page, la hiérarchie, la densité et l'impression générale. Les tokens ci-dessous décrivent la même page sous une forme lisible par machine.

## Résumé du design
[Description courte du langage visuel et de ce qu'un agent doit recréer]

## Tokens de design

### Couleurs
[Rôles de couleur nommés avec valeurs hexadécimales lorsqu'elles sont connues ; marquer clairement les valeurs déduites]

### Typographie
[Polices, recommandations de fallback, échelle, graisses, règles pour les titres et le corps]

### Espacement et mise en page
[Échelle d'espacement, conteneurs, grilles, rayon, ombres, bordures]

## Composants
[Boutons, cartes, navigation, formulaires, héros, sections de fonctionnalités, prix, pied de page, etc.]

## Motifs de page
[Ordre des sections, mises en page courantes, comportement responsive]

## Style de contenu
[Voix, style des appels à l'action, motifs de titres, densité du texte]

## Instructions de construction pour l'agent
[Instructions concrètes qu'un agent de codage IA peut suivre pour créer un nouveau site dans ce style]

## Entrées de réexécution
workflow: firecrawl-website-design-clone
source_url: [url]
target_stack: [stack]
output: DESIGN.md

Si l'utilisateur demande à implémenter, d'abord produire ou mettre à jour DESIGN.md, puis l'utiliser comme source de vérité pour la construction.

Niveau de qualité

• Ne pas sous-entendre que l'utilisateur a des droits sur les logos, images, marques ou copies de tiers.
• Préférer les tokens de design réutilisables aux observations ponctuelles.
• Distinguer les faits observés des approximations déduites.
• Garder la sortie suffisamment compacte pour qu'un autre agent puisse la coller dans son contexte et construire à partir de celle-ci.
• Conserver les URL sources et les artefacts d'extraction pour révision.