bishoe01/blueprint-extractor

Extract

Créez un DESIGN.md fondé à partir d'un site web public. Extrayez les motifs de conception observables ; ne clonez pas le site en tant que code exécutable et ne revendiquez pas de directives officielles de marque.

Comportement de la commande

Quand l'utilisateur tape /extract <url>, traitez-le comme une demande d'exécution immédiate de ce workflow.

Si l'utilisateur tape uniquement /extract, demandez l'URL publique HTTPS et ne commencez pas l'extraction avant qu'il ne la fournisse.

Sortie par défaut :

• dossier de preuves : .blueprint-extractor/<slug>/
• document final : DESIGN.md dans le projet courant de l'utilisateur, sauf s'il demande un autre chemin

Workflow

1. Validez l'URL cible.
2. Créez un dossier de preuves dans .blueprint-extractor/<slug>/ du projet de l'utilisateur.
3. Rassemblez les preuves à partir des données publiques de la page :
   • titre HTML et métadonnées
   • CSS lié et en ligne
   • styles calculés à partir d'éléments représentatifs
   • capture d'écran desktop à 1440x900 lorsque l'outillage navigateur est disponible
   • capture d'écran mobile à 390x844 lorsque l'outillage navigateur est disponible
4. Extrayez les tokens concrets uniquement à partir du CSS récupéré, des styles calculés ou des captures d'écran enregistrées.
5. Écrivez blueprint.json et sources.json avant d'écrire la prose finale.
6. Synthétisez DESIGN.md en utilisant le contrat exact en 9 sections de references/DESIGN_TEMPLATE.md.
7. Effectuez une passe d'auto-revue avant de finaliser :
   • améliorez l'utilité de l'implémentation avec des recettes de composants observées ;
   • améliorez le langage qualitatif du thème lorsqu'il est soutenu par des captures d'écran ;
   • séparez les preuves extraites du comportement déduit des captures d'écran et des conseils d'implémentation ;
   • supprimez les affirmations générales sur le produit qui ne sont pas visibles ou présentes dans le CSS extrait ;
   • préservez le domaine, l'architecture d'information et les workflows principaux du projet cible ; transférez uniquement le langage visuel ;
   • abstraitisez les composants du domaine source avant de les réutiliser, par exemple "playlist" en "liste de collection" ou "pochette d'album" en "vignette visuelle" ;
   • gardez les exemples non pris en charge hors de DESIGN.md sauf s'ils sont marqués comme qualitatifs ou déduits.
8. Validez le Markdown final par rapport au template et aux preuves.
9. Signalez le chemin de sortie et les éventuels avertissements de confiance dans la réponse finale.

Sécurité des URLs

Rejetez la demande avec une brève explication lorsque l'URL est dangereuse ou hors de portée :

• pas https://
• localhost, boucle locale, adresse IP privée, lien-local ou nom d'hôte privé
• contenu avec accès par authentification ou paywall
• réponse non-HTML
• inaccessible, vide, ou trop de redirections
• demande de contournement de connexion, de scraping de tableaux de bord privés, d'extraction de Figma, ou de clonage de code exécutable

Ne suivez pas les formulaires, les flux de connexion, les flux de paiement, les actions destructrices ou les pages spécifiques à un utilisateur.

Extraction

Si scripts/extract-blueprint.mjs existe et que les dépendances sont disponibles, exécutez-le d'abord et utilisez ses artefacts comme source de vérité. S'il est indisponible, utilisez les outils navigateur, HTTP et système de fichiers disponibles pour rassembler des preuves équivalentes manuellement.

Privilégiez les preuves déterministes plutôt que les suppositions visuelles :

• Les couleurs doivent provenir du CSS, des styles calculés, des attributs SVG, ou des captures d'écran échantillonnées.
• Les familles de polices doivent provenir du CSS, des styles calculés, ou de @font-face.
• Les points de rupture doivent provenir des media queries ou être explicitement marqués comme déduits des captures d'écran.
• L'espacement, le rayon, les ombres, les bordures et le mouvement doivent citer le CSS ou les styles calculés.
• Si seules des captures d'écran sont disponibles, gardez les observations qualitatives et évitez les tokens numériques inventés.

Lisez references/EXTRACTION_SCHEMA.md avant de créer ou modifier blueprint.json et sources.json. Lisez references/FAILURE_MODES.md lorsque l'extraction est partielle ou bloquée. Lisez references/QUALITY_CHECKLIST.md avant de considérer un DESIGN.md généré comme un bon exemple ou une sortie de qualité publication.

Règles de synthèse

Utilisez la langue demandée par l'utilisateur. Si aucune langue n'est demandée, écrivez DESIGN.md en anglais.

Le DESIGN.md final doit contenir exactement ces sections H2, dans cet ordre :

1. 1. Thème visuel & Atmosphère
2. 2. Palette de couleurs & Rôles
3. 3. Règles typographiques
4. 4. Styles des composants
5. 5. Principes de mise en page
6. 6. Profondeur & Élévation
7. 7. À faire et à ne pas faire
8. 8. Comportement responsive
9. 9. Guide de prompt pour agent

N'ajoutez pas de section Sources, Confiance ou Annexe à DESIGN.md. Placez les avertissements de confiance dans la réponse finale de l'assistant ou dans le dossier de preuves.

Chaque token concret dans DESIGN.md doit être traçable jusqu'à blueprint.json. Marquez les résultats incertains comme des observations qualitatives plutôt que des valeurs exactes.

Ne faites pas du document final un simple vidage de tokens. Convertissez les preuves en conseils de conception réutilisables :

• Nommez l'archétype du site uniquement lorsqu'il est visible à partir de la page capturée, par exemple "coque de tableau de bord", "page d'accueil éditoriale", "catalogue commercial", "lecteur multimédia", ou "site de documentation".
• Traitez les marques célèbres avec prudence : n'importez pas de motifs de produit bien connus, de lore de marque ou d'affirmations de système officiel, à moins que la page capturée, le CSS ou les échantillons calculés ne les soutiennent.
• Préservez le modèle de domaine, la structure d'information et les workflows utilisateur de l'application cible. Le site source fournit un langage visuel, pas la permission de convertir le projet cible en catégorie de produit du site source.
• Séparez les traits de conception transférables des objets du domaine source non transférables. Transférez la couleur, la typographie, l'espacement, la densité, la forme, la stratification des surfaces et la sensation d'interaction ; ne transférez pas d'objets du domaine tels que pistes, playlists, paniers, pages de documentation, tableaux de bord ou flux de paiement, sauf si l'utilisateur demande explicitement cette structure de produit.
• Lorsqu'un composant source est utile, formulez-le comme un motif neutre en termes de domaine : "barre latérale de navigation/collection" au lieu de "barre latérale de playlist", "élément de contenu répété" au lieu de "ligne de piste", "vignette visuelle ou bloc d'accent" au lieu de "pochette d'album".
• Préservez dans la prose la distinction entre les tokens observés, le comportement de mise en page déduit des captures d'écran et les conseils d'implémentation.
• Transformez les composants récurrents observés en recettes compactes : objectif, surface, typographie, espacement, rayon, bordure/ombre, interaction.
• Privilégiez les motifs qui se généralisent à travers la page plutôt que les valeurs décoratives ponctuelles.
• Distinguez les points de rupture extraits des points de rupture de commodité d'implémentation.
• Utilisez 7. À faire et à ne pas faire pour des contraintes concises qui préviennent les mauvaises interprétations probables, notamment l'utilisation excessive des couleurs d'accent, l'ajout de composants non pris en charge, l'importation du modèle de domaine du site source, ou le changement de catégorie de produit du projet cible.
• Rendez 9. Guide de prompt pour agent pratique : référence rapide des couleurs, exemples de prompts pour composants, et conseils d'itération lorsque les preuves les soutiennent.
• Gardez les conseils inspirés par et prêts pour l'implémentation sans ordonner à un agent de cloner le site cible.

Validation

Avant de terminer :

• Confirmez que DESIGN.md existe au chemin de sortie prévu.
• Confirmez que les noms et l'ordre des sections H2 correspondent à references/DESIGN_TEMPLATE.md.
• Confirmez que chaque couleur hexadécimale, famille de polices, point de rupture, rayon, ombre et valeur d'espacement apparaît dans blueprint.json ou est explicitement marqué comme déduit/qualitatif.
• Confirmez que la sortie satisfait references/QUALITY_CHECKLIST.md lors de la création d'un exemple ou d'un candidat à la publication.
• Si la validation échoue, corrigez les preuves ou dégradez les valeurs non prises en charge avant de présenter le résultat.