Communitygithub.com

cdesiles/design-verify

Vérifie un artefact de conception dans un navigateur réel avant de le livrer — erreurs console, ressources cassées, débordements, puis une revue visuelle de la capture d'écran. À lire avant de livrer quoi que ce soit.

Qu'est-ce que design-verify ?

Cette compétence (skill) est conçue pour les développeurs et designers qui souhaitent valider automatiquement la qualité technique et visuelle d'artefacts de conception (pages HTML) avant de les livrer. Elle lance une version headless d'un navigateur réel (comme Chromium) pour détecter les erreurs JavaScript, les ressources manquantes (polices, images), les débordements horizontaux, et vérifie que les fichiers CSS de tokens de design sont bien utilisés, en listant les valeurs littérales de couleurs interdites. Le script produit un rapport détaillé (stderr, JSON) et une capture d'écran pour une revue humaine. En cas d'échec, le code de sortie est 1. La compétence est typiquement utilisée dans des environnements comme OpenCode mais peut être adaptée à d'autres postes de travail. Elle impose une limite de trois cycles de correction avant de livrer avec une note honnête. Utile pour éviter de livrer des maquettes cassées ou des designs non conformes au système de tokens.

Compatible avec~Claude Code~Codex CLI~Cursor✓OpenCode
npx skills add https://github.com/cdesiles/opencode-kit/tree/HEAD/skills/design-verify

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Vérifier

Le script détecte les défaillances mécaniques. La capture d'écran permet de détecter les défaillances de conception. Faites les deux, à chaque fois.

Exécution

node ~/.config/opencode/lib/design/verify.mjs "design/Foo.html" --full --out design/.verify/foo.png

Variantes courantes :

CasOptions
Diaporama, une capture par slide--each "section" --step --each-out design/.verify/deck
Document, largeur d'impression--width 900 --height 1200 --full
Affiche ou canevas fixe--width 1080 --height 1350 --full
Vérification d'un panneau étroit--width 900
Animation lente à stabiliser--settle 2000

Il sert le fichier sur un port local temporaire, le charge en mode headless, et affiche du JSON ainsi qu'un résumé sur stderr. Le code de sortie 1 signifie qu'un problème a été détecté.

Lire la sortie

  • errors — erreurs console et exceptions non capturées. Il s'agit généralement d'un script qui référence un élément manquant. Corrigez la cause, ne la masquez pas.
  • failedRequests — polices, images, fichiers voisins manquants. Une police manquante est remplacée silencieusement par une police de secours et toute la décision typographique est perdue, donc ce point est plus important qu'il n'y paraît.
  • horizontalScroll — la page est plus large que la zone d'affichage. À l'écran, cela donne une barre de défilement que personne ne souhaite ; à l'impression, cela signifie que le contenu est tronqué sur le bord droit. Trouvez l'élément dans la liste overflowing.
  • metrics.fontFamilies — les polices réellement rendues. Si la police d'affichage n'est pas présente, la police ne s'est pas chargée et vous examinez la police de secours.
  • images[].loaded: false — ressource cassée ou chemin relatif erroné.
  • metrics.nodeCount — une vérification de cohérence, pas un objectif.

Vérifier la discipline des tokens

Avant de juger la conception, vérifiez qu'elle utilise bien le système. Lorsque tokens.css se trouve à côté de l'artefact, le vérificateur le fait pour vous sous tokens : il avertit lorsque la page ne lie pas le fichier, et liste chaque littéral de couleur — hex, oklch(), rgb() et autres — présents dans le CSS de la page et dans ses autres feuilles de style locales, comme components.css.

Chaque occurrence est soit un token qui devrait exister, soit une valeur qui contourne le fichier. Le CSS structurel (transformation d'échelle d'un diaporama, grille d'une affiche) contient légitimement des nombres en px ; les littéraux de couleur presque jamais. Le chrome de visualisation neutre, comme le letterbox d'un diaporama ou le bureau autour d'une page de document, utilise des couleurs nommées telles que black et white.

Ensuite, regardez la capture d'écran

Ouvrez le fichier. Jugez, dans cet ordre :

  1. Hiérarchie — l'œil se pose-t-il d'abord sur le titre, puis sur le détail secondaire ? Plissez les yeux : si tout a le même poids, il n'y a pas de hiérarchie.
  2. Espacement — rythme cohérent et suffisant. Les écarts inégaux entre les groupes sont le signe le plus courant d'une mise en page non réfléchie.
  3. Alignement — tout ce qui devrait partager un bord gauche et ce qui ne le fait pas.
  4. Rognage et chevauchement — texte touchant ou dépassant une limite, élément s'échappant de son conteneur.
  5. Contraste — gris atténué sur gris clair est l'échec par défaut. Vérifiez les valeurs réelles, ne faites pas confiance au rendu de la capture d'écran.
  6. Contenu — pas de remplissage, pas de texte factice oublié, pas de chiffres que vous avez inventés.

Corriger et ré-exécuter

Corrigez directement à partir du texte d'erreur ; ne relisez pas tout le fichier pour trouver la ligne. Ré-exécutez après chaque modification substantielle. Trois cycles est la limite — après cela, livrez-le avec une note honnête sur ce qui ne va pas encore.

Export

Lorsque l'artefact est destiné à un endroit sans le dossier :

node ~/.config/opencode/lib/design/inline.mjs "design/Foo.html"

Cela écrit Foo.standalone.html avec les feuilles de style locales copiées à l'intérieur. Exécutez également le vérificateur sur la copie autonome — l'incorporation est l'endroit où les chemins relatifs et les références url() se brisent.

Ne dites jamais qu'une conception est terminée parce que le script s'est terminé avec un code 0. Le script ne sait pas si elle est belle.

Individual skills in this repo

This repo contains 4 individual skills — each has its own dedicated page.

Skills associés