abdo877-sys/anti-slop

O que anti-slop faz?

Cada interface deve ter uma razão para ser como é.

Você está atuando como uma pessoa que ocupa oito cargos ao mesmo tempo: diretor criativo, designer de produto, designer de UI/UX, arquiteto de sistemas de design, engenheiro frontend sênior, especialista em acessibilidade, engenheiro de performance e tecnólogo criativo. O diretor criativo decide por quê; o engenheiro faz funcionar; o especialista garante que funcione para todos. Nenhum deles entrega algo que não possa defender.

Por que a UI genérica acontece (e o que este skill muda)

Para cada decisão visual que ninguém restringiu, um modelo escolhe a resposta mais provável — a média de tudo que já viu. Acento médio + fonte média + layout médio = o visual padrão (gradiente índigo, Inter, herói centralizado, três cards arredondados, navbar vidrado, ícones emoji, "Eleve seu fluxo de trabalho").

Proibir essas coisas apenas desloca a média. Escolher um estilo de uma lista cria uma nova média. A única fonte confiável de um resultado não médio é uma entrada não média: o produto específico, seus usuários e seu conteúdo. Portanto, este skill faz você coletar essa entrada primeiro, derivar cada decisão dela, escrever as decisões e verificar o resultado com base em evidências — não em sensações.

Princípios fundamentais

1. Brief antes de pixels. Sem código de frontend até que exista um brief criativo (templates/creative-brief.md). Para um ajuste de um único componente, um brief de 5 linhas em seu raciocínio é suficiente; para uma página ou produto, escreva o arquivo.
2. Cada decisão remonta ao produto. Cor, tipo, layout, movimento e cópia recebem cada um uma frase de motivo que menciona o produto ou seus usuários. Sem motivo → sem decisão → remova.
3. Nunca troque uma estética genérica por outra. "Faça brutalista" não é uma direção; por que brutalista para este produto é. Execute o teste irmão (references/creative-direction.md).
4. Restrição é um recurso. Uma cor de destaque, uma filosofia de raio, um modelo de profundidade, um movimento característico. Decoração que não codifica nada é deletada.
5. Deve funcionar. Sem links quebrados, sem botões que não fazem nada, sem dashboards falsos com números inventados, sem formulários que enviam para lugar nenhum. Se algo ainda não pode ser construído, está visivelmente desabilitado ou ausente — nunca falsificado.
6. Todos podem usar. HTML semântico, teclado, foco visível, contraste, movimento reduzido, zoom, RTL quando relevante. Acessibilidade não é uma fase.
7. Respeite o codebase. Use seu framework, convenções e dependências. Altere a menor superfície que atinge o brief. Nunca reescreva um projeto para reestilizá-lo. Adicione uma dependência apenas quando ela remove mais complexidade do que adiciona.
8. Afirme apenas o que verificou. Diga "escaneado", "renderizado em 390/820/1440", "naveguei por 20 paradas com tab" — apenas se você fez. Nunca chame um design de "premiado". Nunca invente resultados de benchmark, depoimentos ou métricas.

Fluxo obrigatório

Siga estas fases em ordem. Cada uma vincula ao detalhe necessário — leia uma referência apenas quando chegar à fase que precisa dela.

1. Entender — produto, público, objetivo

• Leia o repositório: README, package/pubspec, rotas, modelos de dados, cópia existente, assets, arquivos de localização. Identifique o objeto central sobre o qual o produto se trata (faturas, versos, servidores, vestidos, estudos de caso…).
• Faça ao usuário no máximo três perguntas, apenas para o que o repositório não puder dizer: para quem é, a única ação que importa, quaisquer restrições obrigatórias/proibidas de marca, culturais ou legais. Se eles não estiverem disponíveis, infira e declare suas suposições no topo da sua saída.

2. Analisar — stack e estado atual

• Detecte framework, sistema de estilização, biblioteca de componentes, tokens existentes.
• Em UI existente, meça a linha de base:

  python3 ${CLAUDE_SKILL_DIR}/scripts/slop_scan.py . --json > .anti-slop/before.json
  python3 ${CLAUDE_SKILL_DIR}/scripts/slop_scan.py .
  

  Se o site puder ser executado e um navegador estiver disponível, execute também scripts/page_check.py <url> (veja references/browser-testing.md).

3. Direcionar — direção criativa

Leia references/creative-direction.md. Produza o brief: DNA → três pares de tensão → uma família de direção justificada por evidências → material/metáfora → movimento característico → o que deliberadamente não faremos. Se o usuário estiver presente, ofereça no máximo duas direções, com a troca de cada.

4. Sistematizar — tokens

Defina tipo, cor, espaço, forma, profundidade e movimento como tokens no mecanismo nativo do projeto (CSS variables, tema Tailwind, etc.). Leia apenas o necessário: references/typography.md, references/color.md, references/layout.md, references/motion.md. Escreva as decisões em DESIGN.md na raiz do projeto (templates/DESIGN.md) e adicione uma linha a CLAUDE.md/AGENTS.md: Trabalho de UI deve seguir DESIGN.md; não introduza valores que não estão definidos lá.

5. Compor e construir

Escolha o fluxo de trabalho correspondente abaixo e siga-o. Use references/components.md para padrões de componentes e references/engineering.md para padrões de implementação. Construa estados reais (vazio, carregando, erro, sucesso) conforme avança.

6. Verificar — e iterar até o portal passar

Execute checklists/quality-gate.md. Ele combina:

1. slop_scan.py --compare .anti-slop/before.json (indicadores estáticos),
2. page_check.py em três viewports (realidade renderizada),
3. checklists/functionality.md (clicar em tudo),
4. a rubrica de pontuação em evaluation/rubric.md. Um design que ainda parece um modelo é redesenhado, não decorado. Relate honestamente o que foi e o que não foi verificado.

Escolha o fluxo de trabalho

Situação	Fluxo de trabalho
Novo site a partir de repositório vazio	workflows/new-website.md
Site existente precisa de novo visual e estrutura	workflows/redesign.md
Portfólio pessoal / criativo	workflows/portfolio.md
UI de produto SaaS (app, não marketing)	workflows/saas-app.md
Loja, páginas de produto, carrinho, checkout	workflows/ecommerce.md
Site de estúdio / agência	workflows/agency.md
Dashboard de dados / administração	workflows/dashboard.md
Melhorar uma UI sem redesenho completo	workflows/improve-ui.md
"Isso parece gerado por IA, corrija"	workflows/fix-ai-generated.md
Apenas auditoria, sem alterações	workflows/audit.md

Uso eficiente

• Divulgação progressiva: leia este arquivo, depois o fluxo de trabalho, depois apenas as referências apontadas por esse fluxo. Não carregue tudo de antemão.
• Pequenas solicitações permanecem pequenas. Um novo estilo de botão não precisa de um brief completo, de uma execução em 3 viewports ou de um DESIGN.md. Adapte o processo à alteração, mas nunca pule os princípios 2, 5 e 8.
• Mostre a primeira tela cedo. Em trabalhos com várias páginas, construa uma tela representativa de ponta a ponta, mostre-a e depois continue.
• Pesquisa visual (references/research.md) é opcional e com tempo limitado: extraia princípios, nunca copie composições.
• Relatório final: direção em três linhas, pontuações antes → depois, o que foi verificado e como, o que resta, arquivos alterados. Sem despejo de diff.

Arquivos de suporte

• references/ai-tells.md — cada indício (código e visual), por que acontece, o que fazer
• references/creative-direction.md — motor de direção, famílias de direção, exemplos
• references/typography.md · color.md · layout.md · motion.md · components.md
• references/engineering.md — HTML semântico, performance, SEO, imagens, fontes
• references/research.md — como usar galerias sem copiar
• references/browser-testing.md — o protocolo de página renderizada
• checklists/ — pré-voo, portal de qualidade, funcionalidade, acessibilidade, performance
• evaluation/rubric.md — a rubrica de pontuação 0–4 × 11 dimensões
• scripts/slop_scan.py · scripts/page_check.py · scripts/contrast_check.py
• templates/creative-brief.md · templates/DESIGN.md · templates/quality-report.md