Taste — Engenharia Reversa do DNA de Design de um Site

O que Taste — Engenharia Reversa do DNA de Design de um Site faz?

Esta skill transforma uma URL em dois arquivos:

• ./{dominio}.md — legível por humanos. Duas seções:
  • Mapa de Design — tokens práticos (cores, escala tipográfica, espaçamento, raios, sombras, grade)
  • DNA de Gosto — 3-4 trade-offs opinativos (Gatilho → Decisão → Razão → Evidência)
• ./{dominio}.json — estruturado. Mesmos dados, analisáveis por máquina, para ferramentas downstream (Cursor, Windsurf, sistemas de design).

O pipeline rejeita descrições genéricas como "limpo e moderno". Um taste.md finalizado deve soar como um designer sênior explicando por que esta página em particular fez essas escolhas específicas — e quais alternativas plausíveis ela rejeitou.

Quando ativar

Ative esta skill sempre que o usuário quiser estudar o design de um site e capturá-lo como orientação para trabalhos futuros de design. Capture todos estes:

• Formulário de barra explícito: /taste <url>
• Solicitações em linguagem natural: "analise o design da vercel.com", "o que torna o site do Stripe tão bom", "extraia os tokens de design da linear.app", "me dê o DNA de design da are.na"
• Intenção de imitação: "quero que meu dashboard pareça com o Linear", "crie uma landing page no estilo de ", "porte o design deste site para meu projeto"
• Pesquisa competitiva: "compare nossa aparência com a do ", "quais convenções de design o usa"
• Qualquer lugar onde o usuário mencione uma URL e pergunte sobre suas escolhas de design, tipografia, cores, espaçamento, filosofia ou "sensação"

Se o usuário mencionar uma URL em conexão com qualquer tópico visual/de design, incline-se a ativar — Claude tende a sub-ativar skills. O custo de uma invocação de skill desperdiçada é pequeno; o custo de gerar conselhos de design genéricos quando esta skill poderia ter produzido uma análise específica e baseada em evidências é grande.

Não ative para: "extrair dados de um site" (use uma skill de scraping), "resumir o conteúdo de " (use WebFetch), "implantar este site" (não relacionado).

Pré-requisitos

Esta skill requer o servidor Playwright MCP (https://playwright.dev/docs/getting-started-mcp) instalado e conectado. Verifique com:

claude mcp list | grep playwright

Se você vir playwright: ... - ✓ Connected, está tudo certo. Se não, instale-o:

claude mcp add playwright -s user -- npx -y @playwright/mcp@latest --isolated

Por que --isolated: cada execução /taste começa com um estado de navegador fresco, para que cookies, sessões de login e cache anterior não vazem para a página analisada. Sem ele, executar /taste https://linear.app enquanto você está logado no Linear analisaria o painel do aplicativo em vez da página de marketing pública — superfície errada, gosto errado.

Por que npx @playwright/mcp@latest (sem a flag --browser): Playwright baixará e usará seu próprio Chromium empacotado (~100MB, uma vez). Isso é mais portátil do que depender do Chrome do sistema do usuário — funciona em máquinas sem Chrome instalado, oferece renderização consistente entre usuários e nunca abre uma janela no perfil real do navegador do usuário.

Após a instalação, o usuário deve reiniciar o Claude Code para que as ferramentas MCP (mcp__playwright__browser_*) apareçam nesta sessão. Se o Playwright estiver indisponível quando esta skill for executada, pare e diga claramente ao usuário: "Preciso do Playwright MCP para raspar a página. Execute claude mcp add playwright -s user -- npx -y @playwright/mcp@latest --isolated e reinicie o Claude Code, depois tente novamente."

Na primeira execução, o Playwright pode levar cerca de 30 a 60 segundos antes que seu primeiro browser_navigate retorne — esse é o download único do Chromium. Execuções subsequentes começam em segundos. Se o usuário quiser pré-baixar para evitar a espera, ele pode executar npx playwright install chromium uma vez antes de invocar esta skill.

Fluxo de Trabalho

Siga estas cinco fases em ordem. Cada fase tem critérios de sucesso explícitos — não avance até que a fase atual tenha produzido o que a próxima fase precisa.

Fase 0 — Analisar a URL e o destino de exportação

Passo 1 — URL

Extraia a URL da mensagem do usuário. Aceite estas formas:

• /taste https://linear.app
• "analise o design da vercel.com" (adicione https:// se estiver faltando)
• Uma URL nua em qualquer lugar no prompt

Se o usuário não forneceu uma URL, peça uma. Se ele forneceu um caminho de arquivo ou algo que claramente não é uma URL, pergunte se ele quis dizer uma página hospedada. Não prossiga até que você tenha uma URL real.

Resolva formas curtas comuns antes de navegar: linear.app → https://linear.app, https://www.stripe.com está ok como está.

Passo 2 — Extrair o domínio para nomeação de arquivos

Da URL, extraia o nome do host e remova qualquer prefixo www.. Exemplos:

• https://linear.app → linear.app
• https://www.stripe.com → stripe.com
• https://vercel.com/home → vercel.com

Armazene isso como {dominio}. Todos os arquivos de saída serão nomeados após ele: {dominio}.md, {dominio}.json, e qualquer arquivo de exportação. Nunca use o nome genérico taste.md — esse nome colide quando o usuário executa esta skill em vários sites no mesmo diretório.

Passo 3 — Destino de exportação + Escopo de rastreamento

Se o usuário já especificou tanto um destino de exportação QUANTO um escopo de rastreamento em sua mensagem, pule esta questão inteiramente. Se algum estiver faltando, pergunte uma vez em uma única mensagem:

"Duas perguntas rápidas antes de eu começar:

Destino de exportação — com qual ferramenta você está construindo?

 1  Cursor          → .cursor/rules/{dominio}-taste.mdc
 2  Windsurf        → .windsurf/rules/{dominio}-taste.md
 3  Claude Code     → CLAUDE.md (anexa seção Design Taste)
 4  GitHub Copilot  → .github/copilot-instructions.md (anexa)
 5  Bolt            → .bolt/prompt
 6  Antigravity     → GEMINI.md
 7  v0 by Vercel    → taste-tokens.css + instruções
 8  Figma Make      → taste-figma.css + instruções
 9  Lovable         → imprimir texto para colar no Project Knowledge
10  Pular           → manter apenas {dominio}.md + {dominio}.json

Escopo de rastreamento — apenas esta página, ou explorar 2–3 páginas vinculadas?

 1  Apenas esta página       → mais rápido, focado exatamente no que você me deu
 2  Explorar páginas vinculadas → visitarei 2–3 páginas de navegação e mesclarei os dados
```"

Armazene as respostas como {destinoExportacao} e {escopoRastreamento}. Padrões: {destinoExportacao} = "pular", {escopoRastreamento} = "única". Não pergunte novamente.

Fase 1 — Capturar dados da página (Playwright MCP)

Execute estas etapas em ordem. Se alguma etapa der erro, pare o pipeline e relate o erro ao usuário — não continue silenciosamente com dados degradados.

1. Redimensionar a viewport para 1440×900 para que as medidas sejam consistentes entre as execuções:

   mcp__playwright__browser_resize  width=1440  height=900
   

2. Navegar para a URL:

   mcp__playwright__browser_navigate  url=<a URL>
   

3. Esperar brevemente pela hidratação do lado do cliente. SPAs pesados (figma.com, notion.so) precisam de alguns segundos após domcontentloaded para renderizar conteúdo real. Use:

   mcp__playwright__browser_wait_for  time=3
   

   Se após 3 segundos o snapshot da página ainda parecer um esqueleto de carregamento, dê mais 3 segundos. Se ainda for esqueleto após isso, anote na saída final ("a página pode estar incompletamente renderizada; algumas medidas são aproximadas").

4. Tirar duas capturas de tela — viewport primeiro, depois página inteira:

   4a. Captura de tela da viewport (1440×900, sem escala — esta é sua referência visual principal para o Passo 1):

   mcp__playwright__browser_take_screenshot  type=jpeg  filename={dominio}-viewport.jpeg
   

   4b. Captura de tela condicional de página inteira — primeiro verifique a altura da página:

   mcp__playwright__browser_evaluate  function=() => document.documentElement.scrollHeight
   

   • Se ≤ 6× a altura da viewport (≤ 5400px em 1440×900): tire uma captura de tela normal de página inteira:

     mcp__playwright__browser_take_screenshot  fullPage=true  type=jpeg  filename={dominio}-fullpage.jpeg
     

   • Se > 6× a altura da viewport: pule a página inteira (muito alta, desperdiça tokens). Em vez disso, tire duas capturas de viewport direcionadas:

     // Meio da página (50% rolagem)
     mcp__playwright__browser_evaluate  function=() => window.scrollTo(0, document.documentElement.scrollHeight * 0.5)
     mcp__playwright__browser_take_screenshot  type=jpeg  filename={dominio}-mid.jpeg
     // Rodapé
     mcp__playwright__browser_evaluate  function=() => window.scrollTo(0, document.documentElement.scrollHeight)
     mcp__playwright__browser_take_screenshot  type=jpeg  filename={dominio}-footer.jpeg
     // Rolar de volta para o topo
     mcp__playwright__browser_evaluate  function=() => window.scrollTo(0, 0)
     

   Use a captura de tela da viewport como a referência visual principal no Passo 1 — ela representa a primeira impressão que o designer pretendia. Use as capturas de página inteira ou meio+rodapé para verificar padrões que só aparecem mais abaixo na página (tipografia do rodapé, variações de cor em seções tardias, etc.). JPEG mantém o custo de tokens baixo em comparação com PNG.

5. Executar o extrator de DOM. Leia references/extract.js e passe seu conteúdo inteiro como o argumento function:

   mcp__playwright__browser_evaluate  function=<conteúdo de references/extract.js>
   

   A ferramenta retorna um objeto JSON. Salve-o mentalmente como dadosDOM — você o alimentará no Passo 1.

6. (Limpeza opcional) O navegador permanece aberto pelo resto da sessão. Não há necessidade de fechá-lo, a menos que o usuário peça.

Captura de múltiplas páginas (apenas se {escopoRastreamento} for "múltipla"):

Após capturar a página principal, extraia links de navegação e visite até 2 páginas adicionais do mesmo site.

6a. Extrair links de nav da página principal já carregada:

(function() {
  const links = [];
  const seen = new Set([location.pathname]);
  const skip = /\/(login|logout|signup|sign-in|register|auth|account|checkout|cart|password|reset)\b/i;
  document.querySelectorAll('nav a, header a, [role="navigation"] a').forEach(a => {
    try {
      const u = new URL(a.href);
      if (u.hostname !== location.hostname) return;
      if (skip.test(u.pathname)) return;
      if (seen.has(u.pathname)) return;
      if (u.pathname === '/' && location.pathname !== '/') return;
      seen.add(u.pathname);
      links.push({ href: u.origin + u.pathname, text: (a.innerText || a.textContent).trim().slice(0, 40) });
    } catch(e) {}
  });
  return links.slice(0, 6);
})()

6b. Escolher 2 páginas da lista retornada. Prefira:

• Caminhos mais curtos (/product em vez de /product/features/detail)
• Nomes de seção distintos (Produto, Comunidade, Preços, Documentos — não apenas slugs diferentes sob a mesma seção)
• Evite a raiz / se você já a capturou

6c. Para cada página adicional, execute um loop de captura mais leve (navegar → esperar 3s → apenas captura de tela da viewport → extrator de DOM). Pule capturas de página inteira/meio/rodapé para as páginas 2-3 — a viewport é suficiente para confirmar a consistência do design, e o extrator de DOM captura a página inteira independentemente. Nomeie as capturas de tela como {dominio}-viewport-2.jpeg, {dominio}-viewport-3.jpeg. Armazene os dados de cada página como paginas[1], paginas[2] (com paginas[0] sendo a URL principal).

Se uma página vinculada falhar ao carregar ou for bloqueada, pule-a silenciosamente e anote no relatório da Fase 6.

6d. Mesclar dados antes da Fase 2. Combine candidatos de cor entre todas as páginas (união), tipografia entre todas as páginas (união). Quando um valor aparecer em 2+ páginas, é um sinal de sistema — marque-o. Valores que aparecem em apenas uma página são locais — ainda os capture, mas os pesem menos.

Nos Passos 1–3, sempre indique quantas páginas foram analisadas ("Em 3 páginas: …") e distinga padrões de sistema dos locais. A concordância entre múltiplas páginas é a evidência mais forte disponível para um princípio de gosto.

Critério de sucesso para a Fase 1: você tem pelo menos uma captura de tela E um JSON dadosDOM populado (da página principal) com campos colors, typography, layout, effects, cards, images, spacingSamples, sectionGaps e grid. Se algum destes estiver completamente vazio e a captura de tela mostrar conteúdo real, o extrator precisa de melhoria — anote e prossiga de qualquer forma.

Caminho de dados degradados: se dadosDOM.errors não estiver vazio, o extrator falhou parcialmente. No Passo 1, marque categorias afetadas com ~approx (seção do extrator falhou) e confie na captura de tela para essas medidas. Na Fase 6, liste as seções que falharam como uma ressalva no relatório.

Fase 2 — Executar a análise em 4 etapas

Captura de tela é a verdade fundamental. Antes de ler qualquer arquivo de referência: a captura de tela da viewport mostra o que um humano realmente vê. Os dados do DOM fornecem números exatos. Quando eles entrarem em conflito, confie na captura de tela. Uma cor que aparece no DOM mas cobre <5% da área de superfície visível é decorativa — não a liste como uma cor de marca. Divisores de seção que não aparecem na captura de tela não existem, independentemente do que o DOM relata. Sombras imperceptíveis (opacidade ≤3%) são artefatos CSS, não decisões de design.

Os quatro arquivos de referência em references/ contêm os prompts completos para cada etapa. Leia cada um quando chegar a ele (não pré-carregue todos os quatro de uma vez — as etapas são deliberadamente sequenciais e as etapas anteriores não precisam de instruções posteriores).

Para cada etapa:

1. Leia o arquivo de referência correspondente.
2. Gere a saída que ele pede, em sua própria resposta.
3. Inicie a saída com a linha de marcador especificada na referência (por exemplo, ### Saída da Etapa 1 — Medições).
4. A próxima etapa recebe suas saídas anteriores como entrada — mantenha-as na conversa, não as resuma.

Etapa 1 — Medir

• Leia references/step1-measure.md
• Entradas: dadosDOM (o JSON de browser_evaluate) + a captura de tela
• Produza: 20 categorias de medições, cada valor citado com um px / hex / proporção específico

Etapa 2 — Padrão

• Leia references/step2-pattern.md
• Entradas: saída da Etapa 1
• Produza: 5-8 padrões sistemáticos, cada um com Padrão / Evidência / Objetivo de Design

Etapa 3 — Gosto

• Leia references/step3-taste.md
• Entradas: saídas das Etapas 1 + 2
• Produza: 4 princípios de gosto (cada Gatilho / Decisão / Razão / Evidência), pelo menos um trade-off de Restrição

Etapa 4 — Observador

• Leia references/step4-observer.md
• Entradas: saídas das Etapas 1 + 2 + 3 + a URL original

… [truncado para tradução]