Aller au guide d’utilisation
Anti UI Sloppar UIZZE

Anti UI Slop Skill.

Partez des objets et des contraintes réels du produit avant de choisir un traitement visuel.

  • Conception d'interface
  • Revue de design
Revue de la source · Anti UI SlopSKILL.md
Tâche Conception d'interface Produit • Une révision d'interface ancrée dans le produit ou une critique ciblée • Des décisions de design reliées aux tokens, composants et tâches utilisateur existants • Une synthèse concise de transmission identifiant les problèmes observables et les changements résolus Avant de commencer Un agent capable de lire les fichiers du projet ; une prise en charge du rendu pour les vérifications visuelles. UIZZE MCP payant est facultatif.
Résumé éditorial · source examinée 2026-10-07 · exemple non généré

01 Fonctionnement

Fonder les décisions d'interface sur le produit

Un workflow UI centré sur le produit qui sélectionne un guide propre à la tâche, utilise éventuellement des références UIZZE et vérifie l'interface rendue.

Workflow fondé sur la sourcePas un benchmark d'exécution

La méthode de travail

Anti UI Slop est un workflow compact pour créer, peaufiner ou revoir une interface sans remplacer l'identité du produit par une esthétique d'IA générique. Il demande à l'agent d'examiner d'abord le brief, les écrans existants, les composants et les design tokens. Ces contraintes priment sur les exemples du Skill lui-même, ce qui le rend particulièrement pertinent pour travailler dans une application établie.

La source oriente chaque demande vers un seul playbook : nouveau travail, exploitation du produit, finition, simplification, audit ou iOS natif. Elle ne demande pas à l'agent de combiner toutes les listes de contrôle. Des outils de référence UIZZE facultatifs peuvent répondre à une question visuelle précise restée en suspens, mais le Skill gratuit et le catalogue public ne nécessitent pas de compte. Le critère final est le comportement observable de l'interface : éléments tronqués, chevauchements et contrôles qui ne font rien.

Livrables attendus

  • Une révision d'interface ancrée dans le produit ou une critique ciblée
  • Des décisions de design reliées aux tokens, composants et tâches utilisateur existants
  • Une synthèse concise de transmission identifiant les problèmes observables et les changements résolus
Voir l'exemple de brief

Du brief à la revue

  1. 01
    Lire le contexte du produit

    Examinez l'écran demandé et le système de design environnant. Identifiez ce que les utilisateurs cherchent à accomplir avant de modifier la mise en page ou le style.

  2. 02
    Choisir un seul mode de travail

    Sélectionnez le playbook correspondant à la demande. Une passe de finition ne doit pas devenir discrètement une refonte, et un audit doit rester une critique sauf si une mise en œuvre est demandée.

  3. 03
    Vérifier le résultat rendu

    Si l'environnement le permet, inspectez une fois l'interface réelle et corrigez les défauts visibles, les contrôles inaccessibles et les interactions inertes.

02 Cas d’usage

Quand l'utiliser

Un agent capable de lire les fichiers du projet ; une prise en charge du rendu pour les vérifications visuelles. UIZZE MCP payant est facultatif.

Un bon choix

  • Écrans de produit existantsUtile lorsqu'un agent doit étendre un tableau de bord ou un parcours sans inventer un système de design concurrent.
  • Affinage cibléConvient à une demande de simplification ou de finition d'un écran précis tout en préservant ses fonctionnalités établies.

Limites à vérifier

  • Les références sont facultativesLe UIZZE MCP payant est une connexion distincte. Installer ce Skill ne donne pas accès aux outils de référence hébergés.
  • Aucun verdict de design automatiqueLa source décrit une méthode de travail, pas la garantie que chaque interface générée sera distinctive ou accessible.
  • Mentions de licence divergentesSKILL.md déclare MIT, alors que le fichier LICENSE du répertoire du skill contient des conditions Apache-2.0. Demandez au mainteneur de préciser les conditions applicables avant toute réutilisation.

Éléments à fournir

  • Un écran concretFournissez un chemin de fichier, une capture d'écran ou une courte description de l'interface à créer ou à revoir.
  • Langage de design existantIncluez les conventions de composants, les tokens et des exemples d'interface produit validée.
  • Périmètre du changementChoisissez entre nouvelle création, refonte, finition, simplification ou audit afin que l'agent n'élargisse pas la tâche.

03 Décisions importantes

Les décisions qui comptent

  1. Le produit avant la nouveauté

    Les conventions familières sont conservées quand elles servent le parcours. La différence se gagne par une hiérarchie propre au produit, pas par la décoration.

  2. Un playbook à la fois

    Le routage explicite réduit les instructions contradictoires et évite qu'un petit affinage n'accumule des exigences de refonte sans rapport.

04 Exemple de brief

Essayer un brief ciblé

L'exemple de brief ci-dessous n'a pas été testé. Vérifiez la configuration du skill avant de l'utiliser.

Vérifier la configuration

Utilisez le dossier complet du Skill afin que le playbook choisi soit disponible. Le workflow gratuit ne nécessite ni dépendance ni exécutable.

Fichier source amont
https://github.com/github/awesome-copilot/blob/3a685010a7afdc0dbd4c83b7fbda6c316aa516e5/skills/anti-ui-slop/SKILL.md

Un agent capable de lire les fichiers du projet ; une prise en charge du rendu pour les vérifications visuelles. UIZZE MCP payant est facultatif.

Commencer par un seul livrable

Adaptez le périmètre, les documents sources et les contraintes de ce brief avant d'exécuter le skill.

Exemple de brief
Utilise anti-ui-slop pour peaufiner notre écran de liste de factures. Lis d'abord les composants existants de tableau, de filtre et de bouton. Préserve l'architecture de l'information et le parcours de paiement. Utilise uniquement le playbook de finition, identifie le principal problème de hiérarchie, mets en œuvre une correction sobre, puis vérifie les éléments tronqués, les contrôles au clavier et le comportement de l'état vide. Ne connecte pas de service de référence payant.

Examiner le résultat

Comparez le résultat réel à ces critères observables.

  • Les conventions existantes de composants et de tokens restent reconnaissables.
  • Le playbook choisi correspond au périmètre demandé.
  • L'écran rendu ne présente aucun élément tronqué, chevauchement ou contrôle inerte observé dans le parcours examiné.

OpenDesign fournit un espace de travail de design local pour les agents de code. Cette fiche ne signifie pas que le skill est fourni avec ses outils externes, ses identifiants et ses dépendances logicielles.

05 Source et licence

Source et licence

Cette page décrit la révision source figée liée ci-dessous. Le comportement et les exigences en amont peuvent évoluer.

Propriétaire de la source
UIZZE
Licence
SKILL.md déclare MIT ; le fichier LICENSE du répertoire du skill lié contient des conditions Apache-2.0. Précisez les conditions applicables avant toute réutilisation.
Instantané examiné
2026-10-07 · 3a685010a7af
Résumé éditorial de la source
Un workflow UI centré sur le produit qui sélectionne un guide propre à la tâche, utilise éventuellement des références UIZZE et vérifie l'interface rendue.

Résumé original de OpenDesign, fondé sur la source liée. Les étoiles du dépôt sont un indicateur de popularité daté, pas une mesure d'utilisation du skill ni une note de qualité.

06 Questions avant de commencer

Questions avant de commencer

Ai-je besoin d'un abonnement UIZZE ?

Pas pour le Skill gratuit ni le catalogue public. La source décrit les références MCP payantes comme facultatives et exige un résultat de connexion réel avant d'affirmer qu'on y a accès.

Impose-t-il un style visuel unique ?

Non. Le brief produit et le langage de design existant priment sur les exemples du Skill.

Puis-je l'utiliser uniquement pour un audit ?

Oui. Un audit explicite dispose de son propre playbook ; une demande de revue n'a pas à autoriser de modifications de l'interface.

OpenDesign

Faites de la place à la prochaine itération de design.

Gardez votre brief, vos documents sources et votre travail de design ensemble dans un espace de travail local. Vérifiez la configuration propre au skill avant de l'ajouter à votre workflow.

Fichier source amont
https://github.com/github/awesome-copilot/blob/3a685010a7afdc0dbd4c83b7fbda6c316aa516e5/skills/anti-ui-slop/SKILL.md