Break UIpor Emil Kowalski

Break UI Skill.

Encontre as falhas de interface que dados de demonstração amigáveis escondem. O Break UI dá ao seu agente de código um método para testar componentes reais com valores extremos plausíveis, apresentando os problemas antes de alterar o design.

Testes de estresse de UI
Fixtures de casos extremos
Relatório de revisão

Baixar OpenDesign Ver guia de uso

Revisão da fonte · break-uiSKILL.md

Tarefa Revisão de design e acessibilidade Produz • Um inventário de campos com fontes, limites e valores opcionais • Fixtures de pior caso e um seletor de conjuntos de dados apenas para desenvolvimento • Falhas priorizadas, correções propostas e decisões para o responsável Antes de começar Código-fonte do componente, dados de demonstração existentes e limites dos campos; um app em execução e um navegador para verificação visual.

Resumo editorial · fonte revisada 2026-10-12 · não é um exemplo gerado

01 O que faz

Teste o componente, não uma falha simulada

Este fluxo de trabalho é descrito na fonte fixada. Não é uma execução registrada nem um benchmark.

Fluxo baseado na fonteNão é um benchmark de execução

A abordagem de trabalho

Uma lista de membros pode funcionar com nomes curtos e ainda assim perder o menu de ações quando um e-mail é longo. O Break UI rastreia cada valor exibido até props, fixtures ou dados de API, verifica os limites aceitos e substitui os dados nessa mesma fronteira. Ele não altera o layout apenas para fabricar uma falha.

A comparação deve continuar inspecionável: alterne entre dados de demonstração e de pior caso, com estados separados de vazio, item único e lista grande quando relevante. O relatório distingue conteúdo ilegível ou inacessível, dano visual e premissas frágeis; também registra o que já funcionou bem.

Entregas esperadas

Um inventário de campos com fontes, limites e valores opcionais
Fixtures de pior caso e um seletor de conjuntos de dados apenas para desenvolvimento
Falhas priorizadas, correções propostas e decisões para o responsável

Ver o briefing de exemplo

Da entrada aos resultados

01
Mapeie cada valor exibido
Leia o componente, as regras de validação e os formatos de API. Registre limites e o comportamento com campos ausentes, incluindo contagens, selos, imagens e tamanho de lista, não apenas campos de texto.
02
Crie casos extremos verossímeis
Combine nomes longos, nomes curtos, campos ausentes e rótulos localizados em uma fixture com o mesmo formato dos dados existentes. Use os limites do esquema quando conhecidos e registre campos sem limite em vez de inventar um.
03
Compare em tamanhos reais
Mantenha o seletor em desenvolvimento ou em uma rota de protótipo. Inspecione o contêiner real do componente, 320px e seu layout mais largo, além de texto ampliado; inclua modo escuro e RTL se o produto os suportar.
04
Relate antes de corrigir
Dê a cada falha uma gravidade, o valor que a provoca, a correção proposta e a localização no arquivo. Pare para decisões como quebra de linha versus truncamento; aplique correções somente quando solicitado e, depois, teste novamente os estados de demonstração e extremos.

02 Quando usar

Quando usar

Use em um componente existente cujo conteúdo varia. Esta é uma revisão de resiliência a dados, não um redesign visual.

Bons casos de uso

Listas e cartões densosLinhas de membros, resultados de busca e cartões de arquivos combinam nomes, metadados, selos e ações que disputam um espaço limitado.
Interfaces localizadasRótulos traduzidos longos, nomes em alfabetos não latinos e layouts RTL suportados podem expor premissas que o texto de demonstração em inglês não revela.
Coleções vazias e grandesVerifique zero itens, um item, limites do tamanho de página e uma lista grande realista, incluindo plural e comportamento de rolagem.

Limites a considerar

Não é crítica de gostoA skill não escolhe uma nova direção visual nem redesenha o componente. Seus resultados dizem respeito a dados realistas e ao design existente.
Sem decisões de produto automáticasSe um campo deve quebrar linha, ser truncado ou desaparecer, isso pode exigir uma decisão do responsável. O fluxo padrão relata primeiro e para antes de aplicar correções.
A evidência visual exige um navegadorUma revisão apenas do código pode identificar riscos, mas não pode provar o que o usuário vê. A fonte exige distinguir os achados inferidos das falhas verificadas visualmente.

Traga estas entradas

O componente realForneça o componente ou a tela, seu contêiner habitual e uma rota local funcional. Uma captura de tela sozinha não revela a fronteira dos dados nem os limites de validação.
Formatos e limites dos dadosInclua fixtures de demonstração, props ou tipos de API, regras de validação e campos opcionais. Registros sintéticos bastam; não forneça dados reais de clientes.
Estados e ambientes suportadosInforme o tamanho máximo da lista, os idiomas suportados e os requisitos de modo escuro e RTL. Indique se o pedido é apenas de relatório ou inclui correções aprovadas.

03 Decisões importantes

Decisões importantes

As fixtures entram pela fronteira real
Alterar uma prop ou uma resposta simulada testa o comportamento do componente. Editar a marcação ou o CSS para forçar uma falha testaria outro componente.
Valores curtos e ausentes também contam
Um nome de uma letra, um avatar ausente ou uma contagem de um podem expor defeitos de iniciais, fallback e plural que strings longas nunca revelarão.
O pior caso vira fixture de regressão
Após as correções aprovadas, mantenha a fixture para verificações futuras e compare-a com os dados normais. O seletor continua apenas para desenvolvimento e não deve ir para produção.

04 Experimente um briefing focado

Experimente um briefing focado

O briefing de exemplo abaixo não foi testado. Verifique a configuração da skill antes de usá-lo.

Revise a configuração

Instale a partir do repositório público de skills de Emil Kowalski e selecione esta skill para o seu agente.

Comando de instalação com escopo

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

O README documenta a instalação do repositório com npx skills@latest add emilkowalski/skills. O comando com escopo abaixo seleciona esta entrada. Ele requer Node.js/npm para o npx; a fonte não fixa uma versão mínima. Inspecione as instruções originais antes de executá-lo.

Comece com um componente orientado a dados

Este briefing de exemplo é original e não foi testado. Substitua os detalhes de componente e ambiente pelo contexto real do seu projeto.

Briefing de exemplo

Use break-ui no nosso componente MemberList em sua rota de protótipo existente. Inspecione primeiro os tipos das props e os limites de validação. Crie fixtures sintéticas de demonstração e de pior caso realista, cobrindo nomes longos e de uma letra, um e-mail longo de example.com, um avatar e um papel ausentes e texto não latino suportado. Adicione estados vazio e de um único membro, além do tamanho máximo realista de lista encontrado no código. Mantenha o seletor de conjuntos de dados apenas para desenvolvimento e preserve a marcação e os estilos do componente durante os testes. Verifique a largura real da barra lateral, 320px, o layout mais largo suportado e zoom de 200%. Relate as falhas com localização nos arquivos, correções propostas e quaisquer decisões necessárias. Separe os achados verificados no navegador dos riscos baseados no código, registre o que se manteve bem e não aplique correções ainda.

Revise as evidências antes de corrigir

Confira o relatório com o código e o comportamento real no navegador. Mantenha as observações não verificadas separadas das falhas reproduzidas.

Todo campo testado tem uma fonte real e um limite documentado ou uma incógnita explícita.
A troca de dados chega à mesma fronteira do componente; o controle fica restrito ao desenvolvimento ou a um protótipo.
Os achados incluem o valor que falha, a localização e a evidência; dados normais e casos aprovados não são omitidos.

O OpenDesign oferece um espaço de trabalho de design local para agentes de código. Esta listagem não significa que a skill esteja incluída no pacote nem que suas ferramentas externas, credenciais e dependências de software estejam incluídas.

Baixar OpenDesign Leia o guia rápido

05 Fonte e licença

Fonte e licença

Esta página descreve a revisão fixada da fonte, vinculada abaixo. O comportamento e os requisitos originais podem mudar.

Responsável pela fonte: Emil Kowalski
Repositório: emilkowalski/skills
Arquivo da skill: skills/break-ui/SKILL.md
Licença: MIT
Versão revisada: 2026-10-12 · 2d228630ba14

Resumo editorial da fonte

Teste a UI existente sob estresse com dados extremos realistas e um alternador de comparação apenas para desenvolvimento; relate as falhas antes de corrigi-las. Este é um resumo editorial da fonte fixada, não um relatório de execução.

Resumo original do OpenDesign, com base na fonte vinculada. As estrelas do repositório são um sinal de popularidade datado, não de uso da skill nem uma nota de qualidade.

06 Perguntas antes de começar

Perguntas antes de começar

O Break UI corrige o componente automaticamente?

Não por padrão. Ele relata as falhas e as correções propostas e depois aguarda. A fonte também admite um pedido explícito de correção; decisões com mais de uma resposta válida ainda precisam ser resolvidas.

Ele testa apenas texto longo?

Não. Seu catálogo cobre valores ausentes, números, coleções, tempo, mídia, estados e ambiente. Listas vazias e de um item são casos separados, não substitutos de uma fixture de texto longo.

Posso usá-lo sem um projeto?

A fonte permite um componente isolado e uma comparação autônoma em HTML. Sem acesso a um navegador, os achados devem ser marcados como inferidos, e não como verificados visualmente.

Break UI

Teste dados que a demonstração não previu

Comece com um componente e registros sintéticos realistas. Revise o que falha, escolha as correções e mantenha a fixture para a próxima alteração.

Baixar OpenDesign Explorar skills de design