imagile-dev/design

O que design faz?

Crie interfaces que pareçam escolhidas, não geradas. Cada padrão é uma decisão que alguém pulou. Esta skill toma cada decisão de propósito: um briefing primeiro, uma construção até um piso de qualidade, depois uma crítica de screenshots reais.

Dois modos de falha, e o primeiro é pior:

1. Genérico. A página poderia pertencer a qualquer produto em sua categoria. Ela veste os padrões atuais de IA, ou é tão simples que ninguém a lembra.
2. Ruidoso. Cada elemento performa. Movimento, gradientes e ornamentos competem, e nada se lê primeiro.

A cura para ambos é uma ideia forte, expressa em um lugar, dentro de um sistema disciplinado. Restrição não é o objetivo. Intenção é.

1. Escolha o modo

Modo	Use quando	Faça
Build	Uma nova página, tela, componente, deck ou conjunto de imagens	Seções 2 a 5
Refine	"Deixe mais ousado, mais silencioso, mais simples, mais colorido, mais vivo"	Seção 6
Critique	"Revise isto", "isto parece correto?", uma nota	references/critique.md
Polish	Antes de enviar qualquer coisa visual	Seção 7

Refine nunca redesenha. Ele mantém a identidade, o texto e tudo fora da solicitação. Se a solicitação precisar de um redesign, diga e pare. Nunca divida a diferença entre os dois.

2. Carregue o contexto primeiro

1. Leia DESIGN.md na raiz do repositório, o CLAUDE.md do repo, os tokens existentes (global.css, tailwind.config.*, arquivos de tema) e .claude/image-generation/style.md.
2. O briefing vence. Quando DESIGN.md ou o usuário fixa um visual, siga-o exatamente, mesmo que o visual esteja na lista de tells. As regras abaixo governam apenas as escolhas que ninguém fez ainda.
3. Sem DESIGN.md, explore o repo, depois faça no máximo três perguntas sobre fatos duráveis: quem usa, o que deve alcançar e que prova existe. Nunca peça a alguém para escolher uma estética no abstrato. Mostre duas ou três opções.
4. Escreva o que aprendeu em DESIGN.md a partir de references/design-md.md. A próxima sessão não deve ter que perguntar de novo.
5. Uma correção é uma regra permanente. Quando o usuário corrigir uma escolha visual, adicione uma linha em "Regras permanentes" em DESIGN.md na mesma rodada.
6. Use apenas a evidência disponível. Nunca invente depoimentos, logotipos de clientes, contagens de usuários, métricas ou citações. Marque dados de placeholder e liste-os para o usuário confirmar.

3. Escreva o briefing (Modo Build)

Publique um breve no chat antes de escrever código. Leva um minuto e previne o resultado genérico.

1. Leitura de design. Uma linha: "Lendo isso como uma [superfície] para [público], no modo [modo], inclinando-se para [direção]."

2. Modo de superfície. Escolha um por superfície, não por produto. A landing page de uma ferramenta de desenvolvedor ainda é Persuadir.

   Modo	Superfícies	Expressão	Variância / Movimento / Densidade
   Persuadir	Landing, preços, lançamento, portfólio home	Uma grande ideia, imagens reais, um campo de cor	7 / 6 / 3
   Operar	App, dashboard, configurações, admin	O sistema é o design. Sem espetáculo	3 / 2 / 7
   Ler	Docs, artigos, aulas	A tipografia carrega a página	3 / 2 / 5
   Experienciar	Jogos, aprendizado lúdico, crianças, eventos	Personagens, movimento ambiente, humor	8 / 8 / 4

   Os três dials vão de 1 a 10. Variância é simetria a assimetria ousada. Movimento é estático a cinematográfico. Densidade é galeria a cockpit. Leia palavras de vibe neles: "minimalista" abaixa variância e densidade, "chamativo" ou "vivo" aumenta movimento, "denso" ou "pro" aumenta densidade. Registre os dials em DESIGN.md.

3. Frase de cena. Quem usa, onde e em que luz. "Uma enfermeira do turno da noite verificando uma agenda em um telefone em uma sala de descanso escura" decide escuro ou claro. Um rótulo de categoria como "ferramenta de dev significa escuro" não.

4. Frase de ideia. "[Algo que só este assunto tem] se torna [um dispositivo visual]." Em seguida, execute o teste do concorrente: troque pelo nome de um concorrente. Se a frase ainda funcionar, a ideia é genérica. Reescreva-a.

5. Tokens. Quatro a seis cores nomeadas e uma estratégia de cores (references/color.md). Famílias tipográficas e seus papéis (references/typography.md). Um conceito de layout como uma frase mais um wireframe ASCII. O nível de movimento.

6. Argumento (apenas Persuadir). Uma afirmação por seção, cada uma com sua prova. Exclua qualquer seção que não tenha afirmação. Não use como padrão hero, linha de logotipos, três recursos, CTA.

7. Verifique contra os tells. Para cada eixo que o briefing deixa livre, leia references/tells.md. Pergunte se o tema pode ser adivinhado apenas pela categoria, depois se o visual pode ser adivinhado pela categoria mais "não o visual usual". Se alguma resposta for sim, revise essa parte e diga o que mudou.

4. Construa até o piso

Gaste ousadia em um lugar. Deixe um elemento ser a coisa memorável, mantenha tudo ao redor silencioso e corte decoração que não sirva à ideia. Quando remover um tell, preencha o espaço com algo real: escala, imagens, conteúdo ou um campo de cor. Remoção sozinha deixa uma página fina e vazia.

O piso se sustenta em toda superfície sem ser anunciado:

• Tokens, não literais. Cores, tipo, espaço, raio e movimento vivem como tokens em :root. Claro e escuro vêm de prefers-color-scheme, substituível com data-theme. Um toggle, quando presente, vence.
• Contraste. 4,5:1 para texto, 3:1 para texto grande, ícones, controles e anéis de foco. Nunca texto cinza em fundo colorido.
• Tipo. No máximo duas famílias. Cinco tamanhos ou menos. Corpo 16px ou maior com 45 a 75 caracteres por linha. Cabeçalhos cabem em duas linhas em qualquer largura.
• Mobile first. Funciona a partir de 320px com uma margem de 16px e sem rolagem lateral. Alvos de toque têm 44px. Inputs têm 16px para que o iOS não faça zoom. Nunca desabilite o zoom.
• Estados. Todo controle tem padrão, hover, focus-visible, ativo, desabilitado, carregando, erro e sucesso. Toda região assíncrona tem carregando, vazio e erro.
• Estabilidade. Sem deslocamento de layout. Painéis animados ou assíncronos mantêm altura fixa. Cartões em uma grade compartilham altura com o rodapé fixo.
• Nunca incline algo clicável. Inclinação é apenas para selos decorativos e adesivos.
• Movimento. Proposital, interrompível, apenas transform e opacity, e mais suave com prefers-reduced-motion. Conteúdo é visível sem JavaScript.
• Imagens. Arte real ou gerada em um estilo coeso. Arte de personagem e decorativa é enviada como recorte transparente, nunca uma caixa escura. Nenhum texto embutido em imagens.
• Texto. Curto, específico e escrito do lado do usuário. Visuais superam parágrafos.

Detalhes vivem nas referências. Leia apenas o que a tarefa precisa:

Arquivo	Aborda
references/typography.md	Escolha de faces, escala, medida, tipo de exibição, carregamento
references/color.md	Estratégia de cor, tokens OKLCH, modo escuro, contraste
references/layout.md	Espaço, moldura, grades, hierarquia, responsivo e toque
references/motion.md	Se deve animar, easing, durações, performance, movimento reduzido
references/interaction.md	Estados, formulários, dados de pior caso, velocidade percebida
references/copy.md	Escrita UX, erros, estados vazios, conteúdo honesto
references/imagery.md	Direção de arte, arte gerada, fotos, ícones
references/decks.md	Apresentações de slides e palestras
references/tells.md	A lista datada de padrões de design gerado

5. Olhe para isso

Revisão de código não é revisão de design. Renderize e olhe.

1. Execute a página e capture screenshots em 375px e 1440px, mais 768px para layouts que mudam lá. Capture claro e escuro quando ambos existirem. Use playwright-cli, o painel do navegador ou qualquer ferramenta de navegador que a sessão tiver.
2. Aperte os olhos para cada screenshot. O elemento primário, o elemento secundário e os grupos devem ainda ser lidos nessa ordem.
3. Caça por colisões: sobreposição, banners cortados, texto que quebra onde não deveria, ícones desalinhados, grades desiguais, uma fileira de 3 mais 1 onde 2 por 2 pertence.
4. Critique com references/critique.md, corrija em sua ordem de correção e capture novamente. Pare após três rodadas e reporte o que sobrou.
5. Para jogos e peças interativas, jogue-os. Um subagente testa em largura mobile e encontra o que ler o código nunca encontrará.
6. Deixe o servidor de desenvolvimento rodando e dê ao usuário a URL. Coloque os screenshots finais no PR: mobile e desktop, claro e escuro.

Quando a direção estiver aberta, como uma fonte, um logotipo ou uma paleta, construa dois ou três pequenos mockups lado a lado e deixe o usuário escolher. Depois construa o vencedor.

6. Refine

Cada refinamento segue um método: avalie o estado atual, escreva uma tese de uma frase, aplique-a no vocabulário do sistema existente, capture screenshots, então finalize.

Solicitação	O que fazer
Mais ousado	Eleve o alvo ao nível de confiança de seus vizinhos: escala, peso, compromisso de cor, imagens. Em seguida, silencie o que o rodeia
Mais silencioso	Remova um acessório de cada vez. Abaixe o dial de movimento. Mescle cores para menos papéis
Mais simples	Corte seções que não fazem afirmação. Corte palavras pela metade. Transforme parágrafos em um visual
Mais cor	Suba um degrau na escada da estratégia de cor. Nunca adicione um segundo matiz de destaque primeiro
Tipografia	Reconstrua a escala e o pareamento de references/typography.md
Layout	Corrija a moldura, as bordas esquerdas e o ritmo de references/layout.md
Animar	Primeiro, passe pelo portão de frequência em references/motion.md. Depois adicione um momento orquestrado
Texto mais claro	Aplique references/copy.md
Responsivo	Refazer para 375px primeiro: coluna única, alvos de toque reais, nada cortado
Endurecer	Alimente dados de pior caso e adicione os estados ausentes de references/interaction.md

7. Checklist de envio

Execute isso antes de considerar qualquer trabalho visual concluído:

• DESIGN.md reflete as decisões tomadas e quaisquer correções dadas
• Screenshots em 375px e desktop, claro e escuro, não mostram colisões ou cortes
• Nada em references/tells.md aparece a menos que o briefing o tenha fixado
• Todo controle tem seus estados, e toda região assíncrona tem carregando, vazio e erro
• Dados de pior caso renderizam: nomes longos, zero e um item, números enormes
• O teclado alcança tudo, o foco é visível e o movimento reduzido é respeitado
• A skill accessibility reporta zero violações graves nos temas principais
• As imagens são coesas, recortadas onde deveriam e otimizadas com web-optimize
• O texto é reduzido ao que o usuário precisa, sem provas inventadas
• O servidor de desenvolvimento está rodando e o PR tem os screenshots

Habilidades relacionadas

• accessibility audita WCAG 2.2 AA com axe-core em larguras, esquemas e temas.
• image-generation cria arte a partir de um style.md bloqueado por paleta. background-removal o recorta. web-optimize o envia.
• architecture contém os padrões de stack para sites em sua referência web.

Créditos

Esta skill parafraseia e combina ideias da skill frontend-design da Anthropic (Apache-2.0), do Impeccable de Paul Bakaus (Apache-2.0), das skills de design engineering de Emil Kowalski (MIT) e do taste-skill de Leonxlnx (MIT). Nenhum texto é copiado. Cada arquivo de referência nomeia a fonte de suas regras.