unslop-design

Unslop design

Três partes: o que corrigir (checklist.md, cada correção com sua razão), como orquestrar (process.md, rodadas com revisores e desenvolvedores em paralelo) e casos e fontes (references.md: os cinco antes/depois que iniciaram esta skill e um mapa de Refactoring UI). O cartão de especificações que cada revisor preenche está em spec-card.md. Notas por plataforma (SwiftUI, Compose, web, widgets, watch, car) ficam em platforms.md. Leia apenas a que você precisa, não todas.

Princípios (não negociáveis)

1. Uma correção é uma regra, não um ajuste. Toda mudança é enviada como um token ou componente (espaçamento, tamanho da fonte, peso, função de cor, raio, sombra, botão), nunca como um literal na view. Se o token não existir, crie-o na mesma mudança. Escolha valores por eliminação dentro da escala (tente o valor e seus dois vizinhos; o do meio vence ou você repete), nunca pixel a pixel.
2. Hierarquia antes da cor. A tela tem que funcionar em escala de cinza: espaçamento, tamanho, peso e contraste fazem o trabalho; a cor vem depois e apenas para significar algo. Se não estiver claro em cinza o que importa, a cor não vai consertar.
3. A primeira coisa que você lê é a resposta. Um número principal por tela (o saldo, o preço, o progresso de hoje); tudo o mais fica em segundo plano. Enfatize desenfatizando a concorrência, não inflando o principal. No máximo uma superfície escura/principal por tela, e nenhuma em folhas ou modais.
4. A cor diz uma coisa. Um acento de marca para a ação ou o número principal; todo o resto é uma função com significado (dinheiro/sucesso, para cima/perigo, status, recompensa) e cinza para o que apenas navega. Cor decorativa = excesso. A cor nunca funciona sozinha: uma forma ou uma palavra a acompanha.
5. Contraste medido, não presumido. WCAG AA (4,5:1 texto, 3:1 texto grande e ícones) calculado a partir dos valores hex reais contra os fundos reais, claro e escuro. Branco sobre uma cor de marca verde/amarelo quase nunca passa; texto cinza sobre fundo colorido também não (escolha uma tonalidade do mesmo matiz).
6. Nada que a tela não possa entregar. Sem números inventados, sem projeção apresentada como dado, sem funcionalidade implícita que não existe, sem estado vazio que mente. Projete a menor versão que você pode realmente enviar.
7. Um gesto de assinatura, tirado do domínio. Um detalhe de marca nascido do que o aplicativo mostra (um preço de quadro de preços com o último dígito menor, números de matriz de pontos em um aplicativo de corrida), não uma nova fonte ou efeito; e ele degrada graciosamente onde não se aplica. Todo o resto é nativo: não lute contra a barra de guias, interruptores ou folhas do sistema.
8. Plataformas são enviadas juntas. Se o projeto tem iOS e Android (ou app e web), a mudança vai para ambos no mesmo PR, em todos os idiomas.
9. Verifique o que o usuário vê. Capturas de tela em claro e escuro, no maior tamanho de texto, em uma moeda/idioma não padrão, com dados reais (nomes longos, vazio, 2.000 itens). O que não puder ser compilado no seu ambiente é auditado pela leitura, e o PR informa isso.

Qualquer agente (Claude Code, Codex, Cursor, Copilot, Gemini…)

As regras são as mesmas em todos os lugares. Onde diz "agentes", use o que sua ferramenta tem: subagentes se ela os tiver (Claude Code, Codex…), com uma árvore de trabalho git cada para os desenvolvedores. Sem subagentes, execute os revisores um após o outro, cada um com seu próprio resumo, e mantenha suas saídas separadas antes da etapa do júri. Onde diz "publicar", o Claude Code publica um artefato; outros agentes escrevem um arquivo HTML que o usuário abre. Em um aplicativo de chat sem base de código, pare após a proposta antes/depois.

Acordo de trabalho (padrões)

• Revisores = designers de produto seniores e desenvolvedores = desenvolvedores seniores, como agentes (use o modelo que o usuário solicitar). O orquestrador não constrói as áreas: ele faz o trabalho compartilhado, integra e audita.
• Toda decisão vem com uma recomendação explícita e acionável.
• Antes de implementar, publique o antes/depois e aguarde o "sim" do usuário.
• Cada rodada também revisa o que as rodadas anteriores enviaram e todos os vídeos/capturas de tela recebidos, não apenas os mais recentes.
• Quando a mesclagem for permitida após o CI ficar verde: feche com uma lista do que verificar ao compilar (riscos concretos) e, se não houver Mac/simulador, um prompt autocontido para uma sessão local.
• Em "está tudo pronto?": pronto (com PRs) · pendente de você · deixado de fora propositalmente.
• Após a última rodada, atualize o sistema de design do projeto.

Fluxo resumido

1. Inventário: quadros dos vídeos (process.md § 1), telas e estados, e cada tela localizada no código.
2. Sistema: verifique (ou crie) as escalas de espaçamento, tipo, cor e elevação (checklist.md § Sistema). Sem escalas, revisores julgam a olho.
3. Passagem em escala de cinza + revisores paralelos (3-4, um por área) contra checklist.md, aplicando correções uma de cada vez.
4. Proposta vencedora: uma página HTML com antes/depois, o cartão de especificações e a lista de decisões; o usuário escolhe.
5. Desenvolvedores por área em árvores de trabalho isoladas com um resumo fechado; integre, compile, audite, PR, responda aos bots de revisão, mescle quando verde.
6. Finalmente: atualize o sistema de design do projeto (documentação + tokens + sua própria skill) com o que é novo.

Se o projeto já tem sua própria skill de design

Use-a para tokens e componentes concretos; esta skill traz o método e o checklist geral. Se uma regra aqui entrar em conflito com uma decisão escrita do projeto, o projeto vence e a proposta destaca isso.