Ir para o guia de uso
Anti UI Sloppor UIZZE

Anti UI Slop Skill.

Comece pelos objetos e restrições reais do produto antes de escolher um tratamento visual.

  • Design de UI
  • Revisão de design
Revisão da fonte · Anti UI SlopSKILL.md
Tarefa Design de UI Produz • Uma revisão de interface baseada no produto ou uma crítica focada • Decisões de design vinculadas a tokens, componentes e tarefas de usuário existentes • Uma nota de handoff concisa que identifica problemas observáveis e mudanças resolvidas Antes de começar Um agente capaz de ler arquivos do projeto; suporte de renderização para verificações visuais. O UIZZE MCP pago é opcional.
Resumo editorial · fonte revisada em 2026-10-07 · não é um exemplo gerado

01 Funcionalidades

Baseie as decisões de interface no produto

Um fluxo de UI centrado no produto que seleciona um guia específico para a tarefa, usa opcionalmente referências do UIZZE e verifica a interface renderizada.

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

A abordagem de trabalho

Anti UI Slop é um fluxo compacto para construir, polir ou revisar uma interface sem substituir a identidade do produto por uma estética genérica de IA. Ele pede que o agente inspecione primeiro o briefing, as telas existentes, os componentes e os design tokens. Essas restrições têm precedência sobre os exemplos da própria Skill, o que o torna especialmente relevante para trabalho dentro de um aplicativo já estabelecido.

A fonte direciona cada pedido para um único playbook: trabalho novo, operação do produto, polimento, simplificação, auditoria ou iOS nativo. Ela não pede que o agente combine todas as checklists. Ferramentas de referência opcionais do UIZZE podem responder a uma dúvida visual específica ainda não resolvida, mas a Skill gratuita e o catálogo público não exigem conta. A verificação final é o comportamento observável da interface, como cortes, sobreposições e controles que não fazem nada.

Entregas esperadas

  • Uma revisão de interface baseada no produto ou uma crítica focada
  • Decisões de design vinculadas a tokens, componentes e tarefas de usuário existentes
  • Uma nota de handoff concisa que identifica problemas observáveis e mudanças resolvidas
Ver o briefing de exemplo

Do briefing à revisão

  1. 01
    Leia o contexto do produto

    Inspecione a tela solicitada e o design system ao redor. Identifique o que os usuários tentam realizar antes de alterar layout ou estilo.

  2. 02
    Escolha um modo de trabalho

    Selecione o playbook que corresponde ao pedido. Um polimento não deve virar silenciosamente um redesign, e uma auditoria deve continuar sendo uma crítica, a menos que se peça implementação.

  3. 03
    Verifique o resultado renderizado

    Quando o ambiente permitir, inspecione a interface real uma vez e corrija quebras visíveis, controles inacessíveis e interações inertes.

02 Quando usar

Quando usar

Um agente capaz de ler arquivos do projeto; suporte de renderização para verificações visuais. O UIZZE MCP pago é opcional.

Bom encaixe

  • Telas de produto existentesÚtil quando um agente precisa estender um painel ou fluxo sem inventar um design system concorrente.
  • Refinamento focadoServe para pedidos de simplificar ou polir uma tela específica preservando sua funcionalidade estabelecida.

Limites a verificar

  • As referências são opcionaisO UIZZE MCP pago é uma conexão separada. Instalar esta Skill não estabelece acesso às ferramentas de referência hospedadas.
  • Nenhum veredito de design automáticoA fonte descreve um método de trabalho, não uma garantia de que toda interface gerada seja distintiva ou acessível.
  • Os avisos de licença divergemSKILL.md declara MIT, enquanto o LICENSE do diretório da skill contém termos Apache-2.0. Peça ao mantenedor que esclareça os termos aplicáveis antes de reutilizar.

Traga estas entradas

  • Uma tela concretaForneça um caminho de arquivo, uma captura de tela ou uma breve descrição da interface que está sendo construída ou revisada.
  • Linguagem de design existenteInclua convenções de componentes, tokens e exemplos de UI do produto já aceitos.
  • Escopo da mudançaEscolha entre nova construção, redesign, polimento, simplificação ou auditoria para que o agente não amplie a tarefa.

03 Decisões importantes

Decisões que importam

  1. Produto antes de novidade

    Convenções familiares são mantidas quando ajudam o fluxo. A diferença é conquistada por uma hierarquia específica do produto, não por decoração.

  2. Um playbook por vez

    O roteamento explícito reduz instruções conflitantes e evita que um pequeno refinamento acumule requisitos de redesign não relacionados.

04 Exemplo de briefing

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

Use a pasta completa da Skill para que o playbook selecionado esteja disponível. O fluxo gratuito não exige dependência nem executável.

Arquivo-fonte upstream
https://github.com/github/awesome-copilot/blob/3a685010a7afdc0dbd4c83b7fbda6c316aa516e5/skills/anti-ui-slop/SKILL.md

Um agente capaz de ler arquivos do projeto; suporte de renderização para verificações visuais. O UIZZE MCP pago é opcional.

Comece com uma entrega

Adapte o escopo, o material de origem e as restrições deste briefing antes de executar a skill.

Briefing de exemplo
Use anti-ui-slop para polir nossa tela de lista de faturas. Leia primeiro os componentes existentes de tabela, filtro e botão. Preserve a arquitetura da informação e o fluxo de pagamento. Use apenas o playbook de polimento, identifique o problema de hierarquia mais importante, implemente uma correção contida e inspecione cortes, controles de teclado e o comportamento do estado vazio. Não conecte um serviço de referência pago.

Inspecione o resultado

Compare a saída real com estes critérios observáveis.

  • As convenções de componentes e tokens existentes continuam reconhecíveis.
  • O playbook escolhido corresponde ao escopo solicitado.
  • A tela renderizada não apresenta cortes, sobreposições nem controles inertes observados no caminho revisado.

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.

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 upstream podem mudar.

Proprietário da fonte
UIZZE
Licença
SKILL.md declara MIT; o LICENSE vinculado do diretório da skill contém termos Apache-2.0. Esclareça os termos aplicáveis antes de reutilizar.
Versão revisada
2026-10-07 · 3a685010a7af
Resumo editorial da fonte
Um fluxo de UI centrado no produto que seleciona um guia específico para a tarefa, usa opcionalmente referências do UIZZE e verifica a interface renderizada.

Resumo original da OpenDesign, baseado 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

Preciso de uma assinatura do UIZZE?

Não para a Skill gratuita e o catálogo público. A fonte descreve as referências pagas do MCP como opcionais e exige um resultado real de conexão antes de afirmar que há acesso.

Ela prescreve um único estilo visual?

Não. O briefing do produto e a linguagem de design existente têm prioridade sobre os exemplos da Skill.

Posso usá-la apenas para uma auditoria?

Sim. Uma auditoria explícita tem seu próprio playbook; um pedido de revisão não precisa autorizar alterações na interface.

OpenDesign

Abra espaço para a próxima iteração de design.

Mantenha briefing, material de origem e trabalho de design juntos em um espaço de trabalho local. Verifique a configuração da própria skill antes de adicioná-la ao seu fluxo de trabalho.

Arquivo-fonte upstream
https://github.com/github/awesome-copilot/blob/3a685010a7afdc0dbd4c83b7fbda6c316aa516e5/skills/anti-ui-slop/SKILL.md