Clona um design de que gostas — com as salvaguardas certas

O novo estaleiro da Lea: um site que impressiona

O sistema de conteúdo da Lea funciona sozinho — e o seu tráfego sobe. Problema: a sua página inicial, improvisada há dois anos, já não acompanha. Ela descobriu o site de uma marca de chá japonesa cujo design a maravilha: um layout arejado, uma paleta suave, uma tipografia elegante. Ela gostaria desse nível de acabamento para a sua própria marca. A boa notícia: o Claude Code lê imagens. O método deste capítulo permite-lhe analisar esse design, extrair os seus princípios e reconstruir a sua versão — não uma cópia.

Retém esta distinção desde já, porque todo o capítulo assenta nela: não se clona um site, clona-se o que o torna bom — a sua grelha, as suas proporções, o seu ritmo, a sua hierarquia visual. O conteúdo, as cores de marca e as imagens serão os da Lea. É a diferença entre aprender com um mestre e plagiar o seu quadro.

Etapa 1: capturar e mandar analisar

Começa por capturas de ecrã do site admirado: a página inteira, depois zooms nas zonas-chave (header, secção hero, grelha de produtos, footer). Arrasta-as diretamente para o Claude Code — ele lê imagens nativamente, na extensão como no terminal. Mas não peças «faz-me o mesmo site»: obterias uma imitação aproximativa. Pede primeiro uma análise estruturada, porque é ela que transforma uma impressão visual em especificações exploráveis:

analisa esta captura de ecrã de site web como um designer sénior.
dá-me uma análise estruturada:

1. LAYOUT: estrutura da página, grelha (número de colunas, goteiras), largura máx. do conteúdo
2. PALETA: cada cor em hex, o seu papel (fundo, texto, destaque, bordas), os rácios de uso
3. TIPOGRAFIA: famílias prováveis, tamanhos (título/subtítulo/corpo), pesos, entrelinha, caixa
4. ESPAÇAMENTOS: o ritmo vertical entre secções, os paddings internos dos cartões/botões
5. HIERARQUIA: em que ordem o olho circula, e que processos criam essa ordem (tamanho, contraste, espaço)
6. ASSINATURA: as 3 escolhas que dão a sua personalidade a este design

não geres NENHUM código por agora.

O «não geres nenhum código por agora» é deliberado: é o Plan Mode do capítulo 2 aplicado ao design. Queres primeiro validar que a análise capta o que gostas nesse site. Lê o ponto 6 em particular — a «assinatura» — e corrige se necessário: «não, o que me agrada sobretudo é o contraste entre as grandes fotos e o texto minúsculo». Esta conversa enquadra tudo o que se segue.

Etapa 2: extrair os design tokens

Validada a análise, convertemo-la em design tokens: variáveis CSS que codificam cada decisão visual (cores, tamanhos, espaçamentos). É a etapa que muda tudo em relação a uma clonagem ingénua: os tokens separam o sistema de design (reutilizável) dos valores (que a Lea substituirá pelos seus). Eis o prompt completo:

a partir da tua análise, gera um ficheiro tokens.css com os design tokens em variáveis CSS:

:root {
  /* cores: fundo, superfície, texto, texto-secundário, destaque, destaque-hover, borda */
  /* tipo: famílias, tamanhos (escala modular), pesos, entrelinhas */
  /* espaçamentos: escala (xs, sm, md, lg, xl, 2xl) coerente com o ritmo observado */
  /* diversos: radius, sombras, largura máx. do conteúdo */
}

restrições:
- cada variável é comentada com o seu papel
- a escala de espaçamento deve ser uma verdadeira escala (rácio constante), não valores ao acaso
- propõe depois uma SEGUNDA paleta: a mesma lógica de contrastes, mas com as cores da minha marca (verde-salva #87A96B, creme #F5F0E8, castanho #5C4033)

Olha bem para a última restrição: pedimos a transposição para a paleta da Lea logo nesta etapa. O design admirado fornece a lógica dos contrastes (fundo claro, destaque saturado usado com parcimónia, texto quase preto mas não totalmente); os valores tornam-se os da marca. É o momento preciso em que o projeto deixa de ser uma cópia para se tornar uma criação informada.

Etapa 3: reconstruir a TUA versão

Só agora é que se constrói — com os conteúdos da Lea: os seus produtos, as suas fotos, os seus textos (que o teu skill /post já sabe redigir na sua voz). Pede uma página que consome exclusivamente os tokens: nenhuma cor nem tamanho em valores fixos no HTML. Esta disciplina compensa a dobrar: mudar um token atualiza todo o site, e podes fazer evoluir a paleta sem tocar na estrutura.

constrói a minha página inicial em HTML/CSS usando exclusivamente
as variáveis do tokens.css (nenhum valor fixo).

estrutura: header depurado, secção hero com a minha foto da gama solar,
grelha de 3 produtos, faixa «compromissos», footer.
conteúdos: usa os textos de content/accueil.md.
imagens: apenas as da pasta assets/ (as minhas fotos).

respeita o layout e o ritmo analisados, NÃO os conteúdos do site de origem.

Etapa 4: iterar por diferenças

A primeira versão estará próxima mas não certa — é normal, e a pior reação seria pedir tudo de novo em bloco («ainda não é isto, recomeça»). O bom método é a iteração por diferenças: compara-se sistematicamente, lista-se, corrige-se ponto por ponto. É o mesmo ciclo de afinação do capítulo 4 para a voz de marca, aplicado ao píxel:

aqui está uma captura da MINHA página atual e a captura do site de referência.
compara as duas como um diretor artístico e lista as 10 diferenças
mais visíveis, ordenadas por impacto visual decrescente.

para cada diferença: o que faz a referência, o que faz a minha versão,
e a correção precisa (que token ou que regra CSS modificar).

depois corrige-as UMA A UMA mostrando-me o resultado a cada etapa.

O «uma a uma» tem a mesma função que no enquadramento do capítulo 3: torna cada mudança observável. Se uma correção degradar o conjunto (acontece — o espaçamento perfeito da referência pode sufocar os teus conteúdos mais densos), recusa-la isoladamente em vez de deitar fora o lote inteiro. Duas ou três passagens deste ciclo bastam geralmente para passar de «parecido» a «acabamento profissional».

Ir mais longe: analisar a estrutura real de uma página pública

As capturas mostram o resultado, não a mecânica. Para compreender como um efeito é obtido (aquela grelha que se reorganiza elegantemente no mobile, aquele header que se condensa ao fazer scroll), podes pedir ao Claude para obter um URL público e analisar o HTML/CSS real — é a ferramenta WebFetch, que autorizaste no capítulo 2:

obtém https://exemplo-de-marca.com e analisa a estrutura:
- como a grelha dos produtos é construída (grid? flex? breakpoints?)
- como o header gere o scroll e o mobile
- que variáveis CSS ou convenções de nomenclatura eles usam

objetivo: compreender a TÉCNICA para aplicar a mesma lógica
à minha página, com os meus tokens. não copies nenhum conteúdo nem nenhum asset.

flowchart LR
  A["Captura de ecrã do site admirado"] --> B["Análise estruturada (designer sénior)"]
  B --> C["Design tokens: tokens.css"]
  C --> D["Reconstrução com os TEUS conteúdos e a TUA paleta"]
  D --> E["Comparação lado a lado: 10 diferenças"]
  E -->|"Correções uma a uma"| D
  E -->|"Acabamento atingido"| F["Página da Lea online"]

A fronteira ética e legal: inspirar-se, não copiar

Falemos francamente da linha a não cruzar, porque ela é mais nítida do que se pensa. As ideias de design — uma grelha, proporções, um ritmo de espaçamentos, o princípio de uma paleta suave — não se apropriam: toda a web se inspira em toda a web, e é assim que os standards progridem. Em contrapartida, os assets são obras protegidas: logótipos, ilustrações, fotos, ícones desenhados à medida, textos. Copiá-los não é inspiração, é contrafação — pouco importa que seja «só para inspiração» ou que tenha sido o Claude a fazê-lo por ti.

Salvaguardas técnicas: trancar o projeto com allow/deny

Um estaleiro de redesign implica muitos comandos: instalação de dependências, servidores locais, manipulações de ficheiros. É o momento certo para aprofundar as permissões do capítulo 2 com uma verdadeira política allow/deny escrita em .claude/settings.json — portanto commitada e partilhada com quem se juntar ao projeto:

{
  "permissions": {
    "allow": [
      "Bash(npm run:*)",
      "Bash(npm install:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "WebFetch(domain:fonts.google.com)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)",
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

Lê a lista deny linha a linha, porque cada regra conta um acidente evitado: rm -rf (a eliminação recursiva que leva uma pasta inteira num caminho mal construído), git push --force (que pode esmagar o histórico partilhado), e a leitura do .env — sim, pode-se proibir o Claude de ler um ficheiro: as tuas chaves API nunca aparecerão no contexto, logo nunca numa resposta. E lembra-te do capítulo 2: deny prevalece sempre sobre allow, mesmo que uma regra de autorização ampla a englobe.

Completa com o CLAUDE.local.md para as tuas preferências pessoais de estaleiro: «o servidor de pré-visualização corre na porta 4321», «as minhas capturas de referência estão em ~/Desktop/refs/». Estes detalhes pertencem-te; não têm nada que fazer na memória comum do projeto.

Permissão ou hook: duas fechaduras complementares

Dispões agora de dois mecanismos de proteção, e é útil ver precisamente como se articulam:

A regra de repartição: o que é proibido sempre e em todo o lado pertence às permissões — é binário, mais vale declará-lo uma vez. O que depende do conteúdo («este post ultrapassa o limite? respeita a voz?») pertence a um hook, porque é preciso examinar para decidir. As duas camadas juntas, mais a validação humana no ponto de alavancagem (capítulo 7), formam a defesa em profundidade do teu sistema: a Lea pode deixar o Claude trabalhar depressa precisamente porque as salvaguardas, essas, nunca dormem.