Break UIpor Emil Kowalski

Break UI Skill.

Encuentra los fallos de interfaz que ocultan los datos de demostración amables. Break UI da a tu agente de programación un método para probar componentes reales con valores extremos plausibles y presentar los fallos antes de cambiar el diseño.

Pruebas de estrés de la interfaz
Fixtures de casos límite
Informe de revisión

Descargar OpenDesign Ver la guía de uso

Revisión de la fuente · break-uiSKILL.md

Tarea Revisión de diseño y accesibilidad Produce • Un inventario de campos con fuentes, límites y valores opcionales • Fixtures de peor caso y un selector de conjuntos de datos solo para desarrollo • Fallos priorizados, correcciones propuestas y decisiones para el responsable Antes de empezar Código fuente del componente, datos de demostración existentes y límites de los campos; una aplicación en ejecución y un navegador para la verificación visual.

Resumen editorial · fuente revisada 2026-10-12 · no es un ejemplo generado

01 Qué hace

Prueba el componente, no un fallo simulado

Este flujo de trabajo se describe en la fuente fijada. No es una ejecución registrada ni un benchmark.

Flujo de trabajo basado en la fuenteNo es un benchmark de ejecución

El enfoque de trabajo

Una lista de miembros puede funcionar con nombres cortos y aun así perder su menú de acciones cuando un correo es largo. Break UI rastrea cada valor mostrado hasta las props, los fixtures o los datos de API, comprueba los límites aceptados y sustituye los datos en ese mismo límite. No altera el diseño solo para fabricar un fallo.

La comparación debe poder inspeccionarse: alterna entre datos de demostración y de peor caso, con estados separados de vacío, un solo elemento y lista grande cuando corresponda. El informe distingue el contenido ilegible o inaccesible, el daño visual y las suposiciones frágiles; también registra lo que ya funcionaba bien.

Entregables esperados

Un inventario de campos con fuentes, límites y valores opcionales
Fixtures de peor caso y un selector de conjuntos de datos solo para desarrollo
Fallos priorizados, correcciones propuestas y decisiones para el responsable

Ver el brief de ejemplo

De la entrada a los hallazgos

01
Mapea cada valor mostrado
Lee el componente, las reglas de validación y las estructuras de API. Registra los límites y el comportamiento ante campos ausentes, incluidos recuentos, insignias, imágenes y longitud de la lista, no solo los campos de texto.
02
Crea casos límite verosímiles
Combina nombres largos, nombres cortos, campos ausentes y etiquetas localizadas en un fixture con la misma estructura que los datos existentes. Usa los límites del esquema cuando se conozcan y registra los campos sin límite en lugar de inventar uno.
03
Compara a tamaños reales
Mantén el selector en desarrollo o en una ruta de prototipo. Inspecciona el contenedor real del componente, 320 px y su diseño más ancho, además de texto ampliado; incluye modo oscuro y RTL si el producto los admite.
04
Informa antes de reparar
Asigna a cada fallo una gravedad, el valor que lo provoca, una corrección propuesta y la ubicación en el archivo. Detente ante decisiones como ajustar el texto o truncarlo; aplica correcciones solo si se piden y luego vuelve a probar los estados de demostración y extremos.

02 Cuándo usarlo

Cuándo usarlo

Úsalo en un componente existente cuyo contenido varíe. Es una revisión de resistencia a los datos, no un rediseño visual.

Buen encaje

Listas y tarjetas densasLas filas de miembros, los resultados de búsqueda y las tarjetas de archivos combinan nombres, metadatos, insignias y acciones que compiten por un espacio limitado.
Interfaces localizadasLas etiquetas traducidas largas, los nombres no latinos y los diseños RTL admitidos pueden revelar suposiciones que el texto de demostración en inglés no detecta.
Colecciones vacías y grandesComprueba cero elementos, un elemento, los límites del tamaño de página y una lista grande realista, incluidos el plural y el comportamiento del desplazamiento.

Límites que conviene revisar

No es una crítica de gustoEl skill no elige una nueva dirección visual ni rediseña el componente. Sus hallazgos se refieren a datos realistas y al diseño existente.
Sin decisiones de producto automáticasQue un campo se ajuste, se trunque o desaparezca puede requerir la decisión de un responsable. El flujo predeterminado informa primero y se detiene antes de aplicar correcciones.
La evidencia visual necesita un navegadorUna revisión solo del código puede identificar riesgos, pero no demostrar lo que ve el usuario. La fuente exige distinguir los hallazgos inferidos de los fallos verificados visualmente.

Aporta estas entradas

El componente realProporciona el componente o la pantalla, su contenedor habitual y una ruta local en funcionamiento. Una captura de pantalla por sí sola no revela el límite de los datos ni los límites de validación.
Estructuras de datos y límitesIncluye fixtures de demostración, props o tipos de API, reglas de validación y campos opcionales. Bastan registros sintéticos; no aportes datos reales de clientes.
Estados y entornos admitidosIndica el tamaño máximo de la lista, los idiomas admitidos y los requisitos de modo oscuro y RTL. Aclara si la petición es solo de informe o incluye correcciones aprobadas.

03 Decisiones que importan

Decisiones que importan

Los fixtures entran por el límite real
Cambiar una prop o una respuesta simulada prueba el comportamiento del componente. Editar el marcado o CSS para forzar un fallo probaría un componente distinto.
Los valores cortos y ausentes también cuentan
Un nombre de una sola letra, un avatar ausente o un recuento de uno pueden revelar defectos en iniciales, valores alternativos y plurales que las cadenas largas nunca mostrarán.
El peor caso se convierte en fixture de regresión
Tras las reparaciones aprobadas, conserva el fixture para comprobaciones posteriores y compáralo con datos normales. El selector sigue siendo solo para desarrollo y no debe llegar a producción.

04 Prueba un brief concreto

Prueba un brief concreto

El brief de ejemplo siguiente no se ha probado. Revisa la configuración del skill antes de usarlo.

Revisa la configuración

Instala desde el repositorio público de skills de Emil Kowalski y selecciona este skill para tu agente.

Comando de instalación acotado

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

El README documenta la instalación del repositorio con npx skills@latest add emilkowalski/skills. El comando acotado siguiente selecciona esta entrada. Requiere Node.js/npm para npx; la fuente no fija una versión mínima. Revisa las instrucciones originales antes de ejecutarlo.

Empieza con un componente basado en datos

Este brief de ejemplo es original y no se ha probado. Sustituye los detalles del componente y del entorno por el contexto real de tu proyecto.

Brief de ejemplo

Usa break-ui en nuestro componente MemberList dentro de su ruta de prototipo existente. Inspecciona primero los tipos de props y los límites de validación. Crea fixtures sintéticos de demostración y de peor caso realista que incluyan nombres largos y de una sola letra, un correo largo de example.com, un avatar y un rol ausentes, y texto no latino admitido. Añade estados vacío y de un solo miembro, además del tamaño máximo realista de lista que encuentres en el código. Mantén el selector de conjuntos de datos solo para desarrollo y conserva el marcado y los estilos del componente durante las pruebas. Comprueba su ancho real de barra lateral, 320 px, el diseño más ancho admitido y un zoom del 200 %. Informa de los fallos con ubicaciones de archivo, correcciones propuestas y las decisiones necesarias. Separa los hallazgos verificados en el navegador de los riesgos basados en el código, registra lo que resistió y no apliques correcciones todavía.

Revisa la evidencia antes de corregir

Contrasta el informe con el código y con el comportamiento real del navegador. Mantén separadas las observaciones no verificadas de los fallos reproducidos.

Cada campo probado tiene una fuente real y un límite documentado o una incógnita explícita.
El cambio de datos llega al mismo límite del componente; el control queda confinado al desarrollo o a un prototipo.
Los hallazgos incluyen el valor que falla, la ubicación y la evidencia; no se omiten los datos normales ni los casos que pasan.

OpenDesign ofrece un espacio de trabajo de diseño local para agentes de programación. Este listado no significa que el skill esté incluido ni que se incluyan sus herramientas externas, credenciales y dependencias de software.

Descargar OpenDesign Leer la guía de inicio rápido

05 Fuente y licencia

Fuente y licencia

Esta página describe la revisión fijada de la fuente enlazada abajo. El comportamiento y los requisitos originales pueden cambiar.

Propietario de la fuente: Emil Kowalski
Repositorio: emilkowalski/skills
Archivo del skill: skills/break-ui/SKILL.md
Licencia: MIT
Instantánea revisada: 2026-10-12 · 2d228630ba14

Resumen editorial de la fuente

Pon a prueba la interfaz existente con datos extremos realistas y un interruptor de comparación solo para desarrollo; informa de los fallos antes de corregirlos. Este es un resumen editorial de la fuente fijada, no un informe de ejecución.

Resumen original de OpenDesign, basado en la fuente enlazada. Las estrellas del repositorio son una señal de popularidad fechada, no el uso del skill ni una puntuación de calidad.

06 Preguntas antes de empezar

Preguntas antes de empezar

¿Break UI corrige el componente automáticamente?

No por defecto. Informa de los fallos y de las correcciones propuestas, y espera. La fuente también admite una petición explícita de corrección; las decisiones con más de una respuesta válida siguen debiendo resolverse.

¿Solo prueba texto largo?

No. Su catálogo abarca valores ausentes, números, colecciones, tiempo, medios, estados y entorno. Las listas vacías y de un elemento son casos aparte, no sustitutos de un fixture de texto largo.

¿Puedo usarlo sin un proyecto?

La fuente permite un componente independiente y una comparación autónoma con HTML. Sin acceso a un navegador, los hallazgos deben marcarse como inferidos y no como verificados visualmente.

Break UI

Prueba datos que la demostración no previó

Empieza con un componente y registros sintéticos realistas. Revisa lo que falla, elige las correcciones y conserva el fixture para el siguiente cambio.

Descargar OpenDesign Explorar skills de diseño