slice-mockup-html

Découpage d'une maquette en HTML

Copiez une maquette en HTML de manière fidèle ; ne la reconcevez pas. Un résultat correct, superposé à la maquette, ne montre quasiment aucune différence. La créativité, les « améliorations » et les fonctionnalités supplémentaires sont considérées comme des erreurs.

Workflow (dans l'ordre, ne pas sauter d'étape)

1. Recevoir la maquette

Confirmez que la maquette existe réellement (vérifiez /mnt/user-data/uploads et la conversation) ; si ce n'est pas le cas, demandez-la, ne devinez jamais. Si elle comporte plusieurs pages/cadres, demandez lesquels construire.

Entrées supportées : PNG, SVG, Figma via MCP (JPG est traité comme PNG). Pour tout autre format, demandez à l'utilisateur d'exporter en PNG ou SVG. Comment lire chaque entrée est décrit dans references/mockup-audit.md. Pour Figma, chargez le skill figma:figma-design-to-code avant d'appeler get_design_context.

2. Poser les deux questions

Posez les deux questions ensemble, avant l'audit et avant le codage. Ignorez une question si l'utilisateur y a déjà répondu. Utilisez ask_user_input_v0 si disponible (un seul appel, deux questions) ; sinon, posez-les en texte court et clair.

1. Format de sortie : Fichier unique (HTML, CSS, JS en ligne dans un seul index.html, plus assets/) ou Fichiers séparés (index.html, css/style.css, js/main.js, plus assets/)
2. CSS : Vanilla CSS, Bootstrap via CDN, ou Tailwind via CDN

Après les réponses, lisez references/output-structure.md et le fichier correspondant : references/vanilla.md, references/bootstrap.md ou references/tailwind.md. Ne lisez pas les deux autres.

3. Auditer avant de coder

Lisez references/mockup-audit.md et produisez le cahier des charges d'audit (zone de travail, conteneur, grille, couleurs, polices, espacements, rayons, ombres, ressources, interactions visibles), chaque valeur marquée mesurée ou estimée. Affichez un résumé à l'utilisateur uniquement si une décision est nécessaire (police non identifiable, ressource manquante) ; sinon continuez.

4. Écrire le code

• Règles : references/responsive-and-fidelity.md (pixel-parfait et responsive), references/code-standards.md (HTML sémantique, BEM), references/anti-slop.md (interdictions). Appliquez-les pendant l'écriture, pas après.
• Les valeurs à la largeur de la maquette doivent correspondre exactement à l'audit (en px, pas arrondies à l'échelle d'un framework).
• JS uniquement pour les composants interactifs visibles dans la maquette, en suivant le test de contenu dans anti-slop.md (construisez le comportement quand la maquette contient le contenu nécessaire, sinon gardez-le statique et rapportez-le) ; pas de bibliothèques supplémentaires au-delà de ce qu'exige le framework choisi.

5. Vérifier

Suivez les étapes de vérification dans references/responsive-and-fidelity.md, puis exécutez la vérification finale dans references/anti-slop.md. Si le sandbox ne peut pas rendre, dites-le clairement.

6. Livrer

Enregistrez dans /mnt/user-data/outputs/ et partagez avec present_files. Pour plusieurs fichiers, créez une seule archive .zip avec la structure de dossiers intacte (afin que les chemins des ressources restent valides) et présentez également index.html.

Ensuite, fournissez un rapport d'au maximum 6 lignes, uniquement ce dont l'utilisateur a besoin : polices non identifiées et leurs substituts, valeurs estimées, ressources de substitution, icônes qui n'ont pas pu être recréées ou qui dépassent le budget de taille, comportement interactif construit ou laissé statique faute de contenu, et parties tablette/mobile déduites car la maquette ne les contient pas. Pas de suggestions de fonctionnalités, d'idées d'amélioration ou d'auto-éloge.

Principes fondamentaux

• La fidélité avant tout. Si la maquette semble faible, copiez-la telle quelle.
• N'ajoutez rien d'absent de la maquette ; ne devinez pas en silence : chaque hypothèse ayant un impact visuel va dans le rapport.
• Copiez le texte exactement, y compris les majuscules, la ponctuation et les nombres ; signalez le texte illisible.