Break UIpar Emil Kowalski

Break UI Skill.

Repérez les défaillances d'interface que les données de démonstration flatteuses masquent. Break UI donne à votre agent de code une méthode pour tester de vrais composants avec des valeurs extrêmes plausibles, puis présenter les problèmes avant de modifier le design.

Tests de résistance de l'interface
Jeux de données de cas limites
Rapport de revue

Télécharger OpenDesign Voir le guide d'utilisation

Revue de la source · break-uiSKILL.md

Tâche Revue de design et accessibilité Produit • Un inventaire des champs avec leurs sources, limites et valeurs facultatives • Des jeux de données du pire cas et un sélecteur de jeu de données réservé au développement • Des défaillances hiérarchisées, des correctifs proposés et des décisions à prendre par le responsable Avant de commencer Code source du composant, données de démonstration existantes et limites des champs ; une application en cours d'exécution et un navigateur pour la vérification visuelle.

Résumé éditorial · source examinée 2026-10-12 · pas un exemple généré

01 Ce qu'elle fait

Tester le composant, pas une défaillance simulée

Ce flux de travail est décrit dans la source épinglée. Il ne s'agit ni d'une exécution enregistrée ni d'un benchmark.

Flux de travail issu de la sourcePas un benchmark d'exécution

La méthode de travail

Une liste de membres peut fonctionner avec des noms courts et pourtant perdre son menu d'actions quand un e-mail est long. Break UI remonte de chaque valeur affichée jusqu'aux props, aux jeux de données ou aux données API, vérifie les limites acceptées et remplace les données à cette même frontière. Elle ne modifie pas la mise en page simplement pour provoquer une défaillance.

La comparaison doit rester vérifiable : basculez entre données de démonstration et données du pire cas, avec des états distincts pour liste vide, élément unique et grande liste lorsque c'est pertinent. Le rapport distingue le contenu illisible ou inaccessible, les dégâts visuels et les hypothèses fragiles ; il consigne aussi ce qui a déjà tenu bon.

Livrables attendus

Un inventaire des champs avec leurs sources, limites et valeurs facultatives
Des jeux de données du pire cas et un sélecteur de jeu de données réservé au développement
Des défaillances hiérarchisées, des correctifs proposés et des décisions à prendre par le responsable

Voir l'exemple de brief

Des entrées aux constats

01
Cartographier chaque valeur affichée
Lisez le composant, les règles de validation et les structures API. Consignez les limites et le comportement en cas de champ manquant, y compris les compteurs, badges, images et la longueur des listes, pas seulement les champs de texte.
02
Construire des cas limites crédibles
Combinez noms longs, noms courts, champs manquants et libellés localisés dans un jeu de données de même structure que les données existantes. Utilisez les limites du schéma lorsqu'elles sont connues, et consignez les champs non bornés au lieu d'inventer une limite.
03
Comparer aux tailles réelles
Gardez le sélecteur dans l'environnement de développement ou sur une route de prototype. Inspectez le conteneur réel du composant, 320 px et sa mise en page la plus large, ainsi que le texte agrandi ; incluez le mode sombre et le RTL si le produit les prend en charge.
04
Rapporter avant de réparer
Attribuez à chaque défaillance une gravité, la valeur déclenchante, un correctif proposé et l'emplacement dans le fichier. Arrêtez-vous pour les décisions telles que retour à la ligne ou troncature ; n'appliquez les correctifs que sur demande, puis retestez les états de démonstration et extrêmes.

02 Quand l'utiliser

Quand l'utiliser

Utilisez-la sur un composant existant dont le contenu varie. Il s'agit d'une revue de résilience aux données, pas d'une refonte visuelle.

Un bon cas d'usage

Listes denses et cartesLes lignes de membres, résultats de recherche et cartes de fichiers combinent noms, métadonnées, badges et actions qui se disputent un espace limité.
Interfaces localiséesLes libellés traduits longs, les noms non latins et les mises en page RTL prises en charge peuvent révéler des hypothèses que le texte de démonstration en anglais ne montre pas.
Collections vides et volumineusesVérifiez zéro élément, un élément, les limites de taille de page et une grande liste réaliste, y compris le pluriel et le comportement du défilement.

Limites à vérifier

Pas une critique de goûtLa compétence ne choisit pas de nouvelle direction visuelle et ne refond pas le composant. Ses constats portent sur des données réalistes et le design existant.
Aucune décision produit automatiqueDécider si un champ doit passer à la ligne, être tronqué ou disparaître peut relever du responsable. Par défaut, le flux de travail rapporte d'abord et s'arrête avant d'appliquer les correctifs.
Les preuves visuelles exigent un navigateurUne revue limitée à la source peut identifier des risques, mais elle ne peut pas prouver ce que voit l'utilisateur. La source exige de distinguer les constats déduits des défaillances vérifiées visuellement.

Les éléments à fournir

Le composant réelFournissez le composant ou l'écran, son conteneur habituel et une route locale fonctionnelle. Une capture d'écran seule ne révèle ni la frontière des données ni les limites de validation.
Structures de données et limitesIncluez les jeux de données de démonstration, les props ou types API, les règles de validation et les champs facultatifs. Des enregistrements synthétiques suffisent ; ne fournissez pas de données clients réelles.
États et environnements pris en chargeIndiquez la taille maximale de liste, les langues prises en charge, ainsi que les exigences de mode sombre et de RTL. Précisez si la demande se limite au rapport ou inclut des correctifs approuvés.

03 Les décisions importantes

Les décisions importantes

Les jeux de données entrent par la vraie frontière
Modifier une prop ou une réponse simulée teste le comportement du composant. Modifier le balisage ou le CSS pour forcer une défaillance testerait un autre composant.
Les valeurs courtes ou manquantes comptent aussi
Un nom d'une seule lettre, un avatar absent ou un compteur à un peuvent révéler des défauts d'initiales, de repli et de pluriel que les longues chaînes ne montreront jamais.
Le pire cas devient un jeu de données de non-régression
Après les réparations approuvées, conservez le jeu de données pour les vérifications ultérieures et comparez-le aux données normales. Le sélecteur reste réservé au développement et ne doit pas être livré en production.

04 Essayer un brief ciblé

Essayer un brief ciblé

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

Vérifier la configuration

Installez-la depuis le dépôt public de compétences de Emil Kowalski et sélectionnez cette compétence pour votre agent.

Commande d'installation ciblée

npx skills@latest add emilkowalski/skills --skill break-ui

Le README documente l'installation du dépôt avec npx skills@latest add emilkowalski/skills. La commande ciblée ci-dessous sélectionne cette entrée. Elle nécessite Node.js/npm pour npx ; la source n'impose pas de version minimale. Consultez les instructions d'origine avant de l'exécuter.

Commencer par un composant piloté par les données

Cet exemple de brief est original et non testé. Remplacez les détails du composant et de l'environnement par le contexte réel de votre projet.

Exemple de brief

Utilise break-ui sur notre composant MemberList dans sa route de prototype existante. Inspecte d'abord les types de props et les limites de validation. Crée des jeux de données synthétiques de démonstration et du pire cas réaliste couvrant des noms longs et d'une seule lettre, un long e-mail example.com, un avatar et un rôle manquants, ainsi que du texte non latin pris en charge. Ajoute des états de liste vide et à un seul membre, ainsi que la taille maximale réaliste de liste trouvée dans le code. Garde le sélecteur de jeu de données réservé au développement et préserve le balisage et les styles du composant pendant les tests. Vérifie sa largeur réelle dans la barre latérale, 320 px, la mise en page prise en charge la plus large et un zoom de 200 %. Rapporte les défaillances avec les emplacements dans les fichiers, les correctifs proposés et les décisions nécessaires. Sépare les constats vérifiés dans le navigateur des risques déduits du code, consigne ce qui a tenu bon, et n'applique pas encore de correctifs.

Examiner les preuves avant de corriger

Comparez le rapport avec le code et le comportement réel dans le navigateur. Séparez les observations non vérifiées des défaillances reproduites.

Chaque champ testé a une source réelle et une limite documentée ou une inconnue explicitement indiquée.
Le changement de données atteint la même frontière du composant ; le contrôle est limité au développement ou à un prototype.
Les constats incluent la valeur en cause, l'emplacement et les preuves ; les données normales et les cas réussis ne sont pas omis.

OpenDesign fournit un espace de travail de design local pour les agents de code. Cette fiche ne signifie pas que la compétence est incluse dans OpenDesign, ni que ses outils externes, identifiants et dépendances logicielles sont fournis.

Télécharger OpenDesign Lire le guide de démarrage rapide

05 Source et licence

Source et licence

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

Propriétaire de la source: Emil Kowalski
Dépôt: emilkowalski/skills
Fichier de la compétence: skills/break-ui/SKILL.md
Licence: MIT
Instantané examiné: 2026-10-12 · 2d228630ba14

Résumé éditorial de la source

Soumettez l'interface existante à des données extrêmes réalistes avec un bouton de comparaison réservé au développement ; rapportez les défaillances avant de les corriger. Il s'agit d'un résumé éditorial de la source épinglée, pas d'un rapport d'exécution.

Résumé original par OpenDesign, d'après la source liée. Les étoiles du dépôt sont un indicateur de popularité daté, pas une mesure d'utilisation de la compétence ni une note de qualité.

06 Questions avant de commencer

Questions avant de commencer

Break UI corrige-t-elle automatiquement le composant ?

Pas par défaut. Elle rapporte les défaillances et les correctifs proposés, puis attend. La source prend aussi en charge une demande explicite de correction ; les décisions admettant plus d'une réponse valable doivent quand même être tranchées.

Teste-t-elle uniquement le texte long ?

Non. Son catalogue couvre les valeurs manquantes, les nombres, les collections, le temps, les médias, les états et l'environnement. Les listes vides et à un seul élément sont des cas distincts, pas des substituts à un jeu de données de texte long.

Puis-je l'exécuter sans projet ?

La source autorise un composant autonome et une comparaison HTML autonome. Sans accès à un navigateur, les constats doivent être signalés comme déduits plutôt que vérifiés visuellement.

Break UI

Essayez les données que la démo n'avait pas prévues

Commencez par un composant et des enregistrements synthétiques réalistes. Examinez ce qui échoue, choisissez les correctifs et conservez le jeu de données pour la prochaine modification.

Télécharger OpenDesign Parcourir les compétences de design