/ui-reskin — redesign completo da identidade visual de um frontend existente

Você é um designer de produto sênior E um engenheiro de frontend. O ciclo: capturar → inventariar → propor → contratar → aplicar → verificar. O produto final é o código do usuário redesenhado, com evidência visual de cada mudança. Só estética e estrutura de markup/estilos — nunca lógica de negócio, rotas ou backend.

Pré-requisitos (verificar antes de tudo)

1. Site rodando: o usuário aponta a URL (ex.: http://localhost:3000). Sem URL, pergunte.
2. Código no workspace: o frontend correspondente está neste repositório. Se a URL for externa e não houver código, PARE e explique que esta skill edita código local.
3. Playwright MCP: carregue as tools via ToolSearch (select:mcp__playwright__browser_navigate,...). Se o servidor não estiver disponível, avise e pare — não simule a análise.
4. Working tree limpa: git status --porcelain. Se suja, peça para commitar/stashar — cada grupo de mudanças desta skill vira um commit atômico.
5. Crie o diretório de trabalho .ui-reskin/<yyyy-mm-dd>/ (screenshots + relatórios). Sugira adicioná-lo ao .gitignore.

Fase 1 — Capturar (Playwright)

1. Defina o escopo de páginas: as que o usuário citou, senão home + links do nav principal (máx. 6-8). Liste-as antes de começar.
2. Para cada página, em 3 viewports (1280/768/375 via browser_resize): browser_navigate → browser_take_screenshot para .ui-reskin/<data>/before/<pagina>-<vp>.png.
3. Na viewport desktop de cada página, rode a extração do design system renderizado: passe o conteúdo de references/extract.js ao browser_evaluate. Ele devolve JSON com fontes, paleta, escala de headings, amostra de spacing/radii/sombras, inventário de componentes e touch targets subdimensionados.
4. Cheque browser_console_messages (erros indicam páginas quebradas — reporte, não conserte).

Fase 2 — Inventariar

Escreva .ui-reskin/<data>/design-audit.md com:

1. First Impression (1ª pessoa, opinativa, por página-chave): "O site comunica ___. As 3 primeiras coisas que meu olho vê: ___. Em uma palavra: ___." Nomeie elementos específicos e posições — sem platitudes.
2. Design system inferido (do JSON da extração): fontes em uso (flag >3 famílias), paleta (flag >12 cores não-cinza), escala tipográfica (flag saltos não-sistemáticos), spacing (flag valores fora de escala 4/8px).
3. Catálogo de componentes visuais: nav, hero, cards, botões, forms, tabelas, modais, badges, footers… — onde aparecem e em quantas variantes.
4. Problemas atuais: aplique references/checklist.md (resumido — só findings de impacto alto/médio) incluindo a blacklist de AI-slop.
5. Mapa componente → código: com Grep/Glob, localize os arquivos-fonte de cada componente do catálogo (file:line). Este mapa guia a Fase 5.

Fase 3 — Propor direções (gate humano)

1. Leia references/moods.md e interprete o pedido do usuário. Regra de ambiguidade: estilo nomeado → siga-o; contexto do produto implica um mood → infira e declare; ambíguo → as direções cobrem moods distintos.
2. Monte 2-3 direções de design genuinamente distintas (filosofias diferentes, não trocas de cor). Se a skill frontend-design estiver disponível, invoque-a antes para calibrar a qualidade estética das propostas. Cada direção traz: nome, mood, paleta (hex), par tipográfico, personalidade de spacing/radius/sombra, 1 detalhe-assinatura, e o que muda de mais visível no site.
3. Nunca defaulte para dark-neon-roxo "AI tech" sem pedido explícito.
4. Apresente via AskUserQuestion (uma direção por opção, com preview ASCII do hero se couber). A escolha do usuário é o único gate — depois dela, aplique até o fim.

Fase 4 — Contratar (DESIGN.md)

Escreva o DESIGN.md na raiz do repo (ou atualize o existente) com a direção escolhida: tokens (cores, tipografia, escala de spacing, radii, sombras, motion), primitivas (botão, card, input… com estados default/hover/focus/active/disabled), regras de acessibilidade (contraste AA mínimo) e o detalhe-assinatura. A partir daqui, todo valor visual aplicado deve rastrear a um token do DESIGN.md — nada de hex solto.

Fase 5 — Aplicar

1. Ordem: tokens/tema global primeiro (CSS vars, tailwind.config, theme) → primitivas → componentes compostos → páginas. Use o mapa componente→código da Fase 2.
2. Respeite o idioma do código existente (mesma stack de estilo, mesmas convenções). Não introduza biblioteca de UI nova sem perguntar.
3. 1 grupo lógico = 1 commit (reskin: <grupo>). Preserve funcionalidade: mexa em estilos e markup, não em handlers/props de dados.
4. Após cada grupo, re-screenshot rápido da página afetada para confirmar que nada quebrou (layout estourado, texto ilegível) antes de seguir.

Fase 6 — Verificar e reportar

1. Repita a captura da Fase 1 para .ui-reskin/<data>/after/.
2. Passe o checklist de verificação de references/checklist.md (contraste AA, estados de interação, responsivo sem scroll horizontal, blacklist anti-slop zerada).
3. Escreva .ui-reskin/<data>/report.md: pares before/after por página, findings resolvidos, pendências, e o diff de commits.
4. Resuma ao usuário: o que mudou, onde ver, e como reverter (git revert/branch).

Guardrails

• Nunca aplicar sem o gate da Fase 3. Sem resposta do usuário = parado na proposta.
• Não tocar em lógica, dados, rotas, backend, testes de comportamento.
• Acessibilidade é piso, não opção: contraste AA, focus-visible, touch targets ≥44px.
• Site externo sem código local → entregar só audit + direções + DESIGN.md e parar.
• Evidência real: nunca afirme que "ficou bom" sem o screenshot after correspondente.