benjaminstelzer/scoville-ui-anti-ai-slop

Scoville UI Anti-AI-Slop

Melhore a interface do produto. Trate usabilidade, design da informação, adaptaçã o, acessibilidade e clareza como resultados; não instale uma segunda linguagem de design disfarçada de melhor prática.

Se o usuário excluir explicitamente este Skill, pare antes de ler uma referência, usar uma ferramenta direcionada pelo Skill, alterar qualquer coisa ou fazer uma alegação de conclusão derivada do Skill. Uma instrução de projeto ou host com autoridade superior ainda pode exigir isso; relate esse conflito exato. Excluir um Skill irmão exclui apenas esse irmão e não autoriza a reprodução de seu contrato aqui.

Resolver propriedade primeiro

Resolva cada preocupação nesta ordem:

1. requisitos de sistema, segurança e acessibilidade juridicamente vinculantes;
2. o pedido explícito do usuário, incluindo uma aceitação informada de uma limitação relatada contra um destino não vinculante;
3. instruções do repositório;
4. requisitos canônicos do produto, componentes do sistema de design, wrappers, temas, tokens semânticos e ativos aprovados;
5. o framework ou plataforma proprietária para preocupações não resolvidas;
6. padrões locais deliberados que concordam com esses proprietários; e
7. os princípios gerais de UI deste Skill para a lacuna restante.

Não permita que uma fonte inferior substitua um proprietário superior. Superficie um conflito material. Uma convenção local repetida conta apenas quando é deliberada, atual e apropriada para a mesma superfície.

Quando nenhum destino de acessibilidade for nomeado, use WCAG 2.2 Nível AA para UI web e a orientação atual da plataforma proprietária em outros lugares. Use componentes e APIs suportados. Se o proprietário canônico não puder atingir o piso, relate a limitação exata em vez de ocultá-la com uma linguagem de design paralela.

Leia framework-alignment.md antes de decidir um proprietário quando a pilha não for familiar, a propriedade for ambígua, várias camadas de UI interagirem, nenhum proprietário visual canônico parecer existir ou o caminho de customização suportado for incerto.

Manter a propriedade da família distinta

Este Skill trabalha sozinho. Código assume escopo de engenharia, propriedade de código, integridade, risco e prova. UI assume alinhamento de framework, hierarquia, layout, apresentação de interação, adaptação responsiva e evidência renderizada. Scribe assume significado, terminologia, localização e fidelidade apenas quando a redação visível ou acessível é variável; strings fixas exatas da fonte não o ativam.

UI assume layout de texto, legibilidade, espaço, escala e se um rótulo obrigatório ou nome acessível existe e está associado. Scribe, quando aplicável, assume o que ele diz. Não copie regras de irmãos nem repita sua verificação.

Roteirizar o trabalho

1. Inspecione a superfície solicitada, instruções do repositório, versão do framework, proprietários canônicos e a superfície comparável mais próxima apenas conforme necessário.
2. Identifique a tarefa principal, prioridade, estados afetados, variação de conteúdo, entradas e transformações responsivas.
3. Reutilize componentes canônicos, tokens, variantes, layouts, breakpoints e interações. Adicione um primitivo apenas para uma lacuna demonstrada em seu proprietário.
4. Faça a menor alteração coerente para o resultado e estados necessários.
5. Verifique apenas condições renderizadas que possam refutar o resultado. Separe evidência renderizada, inspeção de fonte e comportamento não verificado no relatório. Para uma direção não implementada ou auditoria apenas de fonte, diga explicitamente que a direção ou descobertas não foram renderizadas e o comportamento renderizado permanece não verificado; não carregue validação apenas para relatar esse limite.

Leia ui-quality.md antes de tomar uma decisão de qualidade sobre fluxo de tarefas, hierarquia, layout, legibilidade, estados, estrutura de acessibilidade ou comportamento responsivo. Para uma pergunta apenas de evidência, carregue validação sozinha, a menos que a própria interface também precise ser julgada.

Leia validation.md após uma mudança de interface ou antes de alegar comportamento renderizado, comportamento responsivo, interação observada, qualidade visual ou acessibilidade. Não o carregue para uma auditoria apenas de fonte que confine as descobertas à estrutura inspecionada e explicitamente deixe o comportamento renderizado e interativo não verificado. Uma compilação ou revisão de fonte não pode provar comportamento renderizado.

Proteger o piso de integridade de UI

Nunca melhore a aparência inventando uma linguagem visual paralela, ignorando um token semântico, reconstruindo um componente acessível, removendo acomodações de foco ou entrada, ocultando conteúdo obrigatório, usando um único sinal visual como único portador de significado, omitindo recuperação para um estado alterado ou aplicando uma exceção local através de uma sobrescrita de tema global.

Não imponha fontes, paletas, raios, sombras, padrões de cartão, breakpoints, valores de pixel ou proibições da moda preferidos. Regras quantitativas vêm do padrão de acessibilidade, plataforma ou sistema de design — não deste Skill.

Quando solicitado apenas a auditar ou aconselhar, retorne descobertas priorizadas vinculadas à evidência observada e não edite.