Communitygithub.com

gtarpenning/ui-critic

Examine les captures d'écran, maquettes et storyboards, selon le goût d'une personne nommée. Sélectionne le meilleur design parmi plusieurs et dessine des boîtes sur ce qui doit changer. À utiliser pour critiquer ou évaluer une UI, un design ou une capture d'écran, comparer ou choisir entre des designs ou variantes, déterminer quelle mise en page est meilleure ou quoi modifier, ou pour affiner ou enseigner un goût en design.

Qu'est-ce que ui-critic ?

Cette compétence agit comme un critique UI nommé, capable d'évaluer des captures d'écran, maquettes et storyboards selon les préférences documentées d'une personne spécifique. Contrairement à une évaluation générique, elle utilise les décisions passées de cette personne comme preuves principales, atteignant environ 60% de précision (contre 44-50% pour Claude seul) pour prédire ses choix sur des sujets non vus auparavant. Elle supporte des workflows de comparaison (entre deux ou plusieurs designs), de critique détaillée avec annotations visuelles, et d'enregistrement de décisions pour améliorer le modèle. Le système fonctionne sur des plateformes compatibles avec Claude Code ou des agents similaires, en utilisant des scripts Python (Pillow requis) pour préparer les images, récupérer les preuves pertinentes, et générer des rapports. Sa méthodologie insiste sur la lecture aveugle des designs, la recherche de compromis entre les options, et une documentation précise des écarts. L'outil inclut également un module d'ajustement interactif (tuning) qui permet à l'utilisateur de corriger les prédictions en temps réel via une interface web, et un script de distillation qui met à jour la base de connaissances de goût à partir des nouvelles décisions.

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add gtarpenning/ui-critic

Demander à votre IA préférée

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

Documentation

Que fait ui-critic ?

Juge les écrans comme le ferait une personne spécifique, en utilisant ses décisions passées comme preuves. Claude seul obtenait 44-50% de précision pour prédire les vrais choix de design de cette personne, et cette procédure environ 60%, sur des décisions dont il n'avait pas de preuves sur le même sujet (résultats). C'est un second avis solide, pas un oracle.

DemandeAction
Quel design est meilleur ?Comparer
Que faut-il changer sur cet écran ou ce flux ?Critiquer
Enseigner, affiner, s'est trompéAjuster
La personne vient de choisir entre des designsEnregistrer

Les scripts se trouvent à côté de ce fichier. Exécutez-les avec python3 ; prepare.py et annotate.py nécessitent Pillow (pip install pillow).

Toujours

  • Comprendre le contexte d'abord. Si vous ne savez pas à quoi sert l'écran et à qui il est destiné, demandez une fois. Sinon, précisez votre hypothèse.
  • Les décisions passées priment sur ces règles et sur l'opinion générale en design. Le plus récent l'emporte sur l'ancien.
  • Ne raisonnez pas seulement à partir des "bonnes pratiques". Un raisonnement général minutieux a obtenu des résultats inférieurs au hasard sur les décisions de cette personne, car il plaide pour plus d'informations, d'étiquettes et de compteurs. Soutenez-vous par ce qu'ils ont réellement choisi.
  • Ne généralisez pas une préférence au-delà de ses preuves. "Moins" dans une liste ne signifie pas "moins" partout. Ils ont choisi une image de carte plutôt qu'un texte court, et ont ajouté des photos et des notes à une étape de comparaison, car cela permet aux gens de reconnaître les choses plus rapidement.
  • Commencez par la réponse. Verdict d'abord, puis détails. Votre rapport suit la même divulgation progressive que vous jugez.

Comparer

  1. Préparer. python3 scripts/prepare.py --out <tmp> <images...>, puis utilisez les copies préparées. Pour un flux, chaque design est une liste ordonnée d'écrans.

  2. Obtenir des preuves. Lisez taste/taste.md. Exécutez python3 scripts/cases.py --context "<à quoi sert cet écran>" --k 4.

  3. Juger deux fois, en aveugle. Créez deux sous-agents sans contexte partagé, en utilisant l'invite dans references/judge.md. L'un voit les designs dans l'ordre X, Y étiquetés A, B ; l'autre voit Y, X. Utilisez Sonnet : Opus coûte plusieurs fois plus cher et n'a pas obtenu de meilleurs résultats. Donnez à chacun les chemins des images des cas et demandez-lui de Lire chaque image. Ne dites pas à leurs agents quel design vous favorisez, qui a fait quoi, ni lequel est le plus récent.

    Plus de deux designs : comparez les deux plus forts visuellement par paires, puis le gagnant contre le suivant. Ne demandez pas un classement en une seule fois.

  4. Décider.

    • Les deux choisissent le même design : c'est le verdict.
    • Ils divergent : dites trop serré pour trancher, donnez le meilleur argument de chaque côté en une ligne, et nommez la question décisive pour la personne. Ne tranchez pas vous-même.
  5. Regarder au-delà des options. Si les deux designs partagent un défaut, ou si le perdant a une bonne idée à conserver, proposez la version fusionnée en une ou deux phrases. Les gagnants passés venaient souvent exactement de cela.

  6. Rapport.

    **B.** <une phrase : la différence qui fait la décision.>
    Confiance : les deux ordres sont d'accord (pas une preuve : un modèle ou des preuves différents peuvent encore inverser) / trop serré pour trancher
    - Pourquoi : <les différences déterminantes, en citant les décisions passées qu'elles reflètent>
    - À garder de A : <le cas échéant>
    - Meilleur que les deux : <s'il y en a un>
    

    Ajoutez une superposition en boîte des problèmes restants du gagnant uniquement si demandé.

Critiquer

  1. Préparer les écrans comme ci-dessus, et notez la taille en pixels de chacun. Les coordonnées ne correspondent que sur les copies préparées.
  2. Obtenir des preuves. Lisez taste/taste.md et exécutez cases.py --k 4, puis Lisez les deux images de chaque cas avant de regarder les nouveaux écrans. Les scores ci-dessous supposent que vous les ayez vues.
  3. Examiner, dans cet ordre :
    • Quelle est la seule chose pour laquelle quelqu'un est venu sur cet écran ? Que doit-il comprendre en un coup d'œil ?
    • Allez élément par élément : cet élément mérite-t-il sa place ici, ou pourrait-il être à un clic de distance ? Quelque chose est-il dit deux fois ? Le même type de chose est-il dessiné de deux façons différentes, sur cet écran ou ailleurs dans l'application ? Une deuxième action entre-t-elle en concurrence avec l'action principale ? Une image serait-elle comprise plus rapidement que les mots ?
    • Pour un flux, demandez aussi : l'élément ouvert ressemble-t-il à ce que vous avez tapé ? Une étape est-elle une impasse ?
  4. Couper. Au maximum 3 résultats, du plus important au moins. Supprimez le bla-bla sur l'accessibilité, le polissage générique et tout ce à quoi vous ne pouvez pas pointer. Si le design est bon, dites-le et ne signalez rien. Remplir avec des problèmes mineurs est un échec. Avant de terminer, vérifiez que chaque résultat n'annule pas une décision passée.
  5. Dessiner. Écrivez findings.json à côté des écrans préparés, avec des boîtes en pixels absolus serrés [x1, y1, x2, y2] sur la copie préparée :
    {"verdict": "Une phrase.",
     "screens": [{"path": "/abs/prepared.png", "label": "Accueil"}],
     "findings": [{"screen": 0, "box": [40, 120, 300, 180], "severity": "haute", "title": "...", "why": "...", "fix": "..."}]}
    
    Exécutez python3 scripts/annotate.py findings.json --out <tmp>. Lisez chaque .annotated.png et vérifiez que chaque boîte se trouve sur ce que son résultat décrit. Si l'une est décalée, corrigez les nombres et réexécutez. Une boîte autour d'une carte entière est acceptable lorsque le résultat concerne la carte.
  6. Rapport le verdict, les résultats, et les chemins vers report.html et les images annotées.

Enregistrer une décision

Lorsque la personne choisit entre des designs ou exprime une préférence en regardant des écrans, proposez d'enregistrer : python3 scripts/record.py --context "..." --winner a.png --loser b.png --reason "ses mots" --topic <slug-court>. Utilisez ses mots pour la raison. C'est ainsi que la compétence s'améliore, et une phrase de "pourquoi" vaut plus que plusieurs choix non expliqués.

Ajuster

Lancez python3 scripts/tune.py, exécutez-le en arrière-plan, et donnez l'URL à la personne. Il a quatre onglets :

  • Choisir : choisissez entre les designs avec les touches fléchées. Environ 5 minutes.
  • Échecs : là où le juge est en désaccord avec elle, et son argument. Elle garde son choix ou dit que le juge a raison.
  • Règles : éditer taste/taste.md.
  • Score : re-évalue, y compris la cohérence de ses propres choix.

Après les choix ou les modifications, exécutez python3 scripts/distill.py pour reconstruire taste/taste.md à partir de toutes les décisions. Voir references/tuning.md pour les chiffres et pour utiliser cela avec le goût de quelqu'un d'autre.

Skills associés