benjaminstelzer/scoville-anti-ai-slop-ui

Scoville UI Anti-AI-Slop

Améliorez l'interface du produit. Traitez l'utilisabilité, la conception de l'information, l'adaptation, l'accessibilité et la clarté comme des résultats ; n'installez pas un second langage de conception déguisé en bonne pratique.

Si l'utilisateur exclut explicitement ce Skill, arrêtez-vous avant de lire une référence, d'utiliser un outil dirigé par le Skill, de changer quoi que ce soit, ou de faire une revendication de complétion dérivée du Skill. Une instruction de projet ou d'hôte ayant une autorité supérieure peut toujours l'exiger ; signalez ce conflit exact. Exclure un skill frère exclut uniquement ce frère et n'autorise pas à reproduire son contrat ici.

Résoudre la propriété en premier

Résolvez chaque préoccupation dans cet ordre :

1. exigences système, de sécurité et d'accessibilité juridiquement contraignantes ;
2. la demande explicite de l'utilisateur, y compris l'acceptation éclairée d'une limitation signalée par rapport à un objectif non contraignant ;
3. instructions du dépôt ;
4. exigences produit canoniques, composants du système de design, wrappers, thèmes, tokens sémantiques et ressources approuvées ;
5. le framework ou la plateforme propriétaire pour les préoccupations non résolues ;
6. motifs locaux délibérés qui s'accordent avec ces propriétaires ; et
7. les principes généraux d'UI de ce Skill pour l'écart restant.

Ne laissez pas une source inférieure remplacer un propriétaire supérieur. Signalez un conflit matériel. Une convention locale répétée ne compte que si elle est délibérée, actuelle et appropriée à la même surface.

Lorsqu'aucun objectif d'accessibilité n'est nommé, utilisez WCAG 2.2 Niveau AA pour l'UI web et les directives actuelles de la plateforme propriétaire ailleurs. Utilisez les composants et API pris en charge. Si le propriétaire canonique ne peut pas atteindre le plancher, signalez la limitation exacte plutôt que de la cacher avec un langage de conception parallèle.

Lisez framework-alignment.md avant de décider d'un propriétaire lorsque la pile est inconnue, la propriété ambiguë, plusieurs couches d'UI interagissent, aucun propriétaire visuel canonique ne semble exister, ou le chemin de personnalisation pris en charge est incertain.

Garder la propriété familiale distincte

Ce Skill fonctionne seul. Code possède le périmètre d'ingénierie, la propriété du code, l'intégrité, le risque et la preuve. UI possède l'alignement du framework, la hiérarchie, la disposition, la présentation des interactions, l'adaptation réactive et les preuves rendues. Scribe possède le sens, la terminologie, la localisation et la fidélité uniquement lorsque la formulation visible ou accessible est variable ; les chaînes fixes exactes de la source ne l'activent pas.

UI possède la disposition du texte, la lisibilité, l'espacement, la mise à l'échelle, et si une étiquette requise ou un nom accessible existe et est associé. Scribe, le cas échéant, possède ce qu'il dit. Ne copiez pas les règles des skills frères et ne répétez pas leur vérification.

Acheminer le travail

1. Inspectez la surface demandée, les instructions du dépôt, la version du framework, les propriétaires canoniques et la surface comparable la plus proche uniquement si nécessaire.
2. Identifiez la tâche principale, la priorité, les états affectés, la variation de contenu, les entrées et les transformations réactives.
3. Réutilisez les composants canoniques, tokens, variantes, mises en page, points de rupture et interactions. Ajoutez un primitif uniquement pour un écart démontré chez son propriétaire.
4. Effectuez le plus petit changement cohérent pour le résultat et les états nécessaires.
5. Vérifiez uniquement les conditions rendues qui pourraient infirmer le résultat. Séparez les preuves rendues, l'inspection source et le comportement non vérifié dans le rapport. Pour une direction non implémentée ou un audit exclusivement source, dites explicitement que la direction ou les conclusions ne sont pas rendues et que le comportement rendu reste non vérifié ; ne chargez pas de validation simplement pour signaler cette limite.

Lisez ui-quality.md avant de prendre une décision de qualité concernant le flux de tâches, la hiérarchie, la disposition, la lisibilité, les états, la structure d'accessibilité ou le comportement réactif. Pour une question de preuve uniquement, chargez la validation seule à moins que l'interface elle-même doive également être jugée.

Lisez validation.md après un changement d'interface ou avant de revendiquer un comportement rendu, un comportement réactif, une interaction observée, une qualité visuelle ou une accessibilité. Ne la chargez pas pour un audit exclusivement source qui confine les conclusions à la structure inspectée et laisse explicitement le comportement rendu et interactif non vérifié. Une compilation ou une revue de source ne peut pas prouver un comportement rendu.

Protéger l'intégrité minimale de l'UI

N'améliorez jamais l'apparence en inventant un langage visuel parallèle, en contournant un jeton sémantique, en reconstruisant un composant accessible, en supprimant les accommodations de focus ou de saisie, en masquant un contenu requis, en utilisant un seul indice visuel comme unique porteur de sens, en omettant la récupération d'un état modifié, ou en appliquant une exception locale via un remplacement global de thème.

N'imposez pas de polices, palettes, rayons, ombres, motifs de cartes, points de rupture, valeurs en pixels ou interdictions à la mode préférés. Les règles quantitatives proviennent de la norme d'accessibilité, de la plateforme ou du système de design – pas de ce Skill.

Lorsqu'on vous demande uniquement d'auditer ou de conseiller, renvoyez des conclusions priorisées liées à des preuves observées et n'éditez pas.