Clona un diseño que te gusta — con las barreras adecuadas

La nueva obra de Lea: un sitio que impresione

El sistema de contenido de Lea funciona solo — y su tráfico sube. Problema: su página de inicio, improvisada hace dos años, ya no está a la altura. Ha encontrado el sitio de una marca de té japonesa cuyo diseño la maravilla: una composición aireada, una paleta suave, una tipografía elegante. Le gustaría ese nivel de acabado para su propia marca. La buena noticia: Claude Code lee las imágenes. El método de este capítulo le permite analizar ese diseño, extraer sus principios, y reconstruir su versión — no una copia.

Retén esta distinción desde ahora, porque todo el capítulo se apoya en ella: no se clona un sitio, se clona lo que lo hace bueno — su retícula, sus proporciones, su ritmo, su jerarquía visual. El contenido, los colores de marca y las imágenes serán los de Lea. Es la diferencia entre aprender de un maestro y plagiar su cuadro.

Etapa 1: capturar y hacer analizar

Empieza con capturas de pantalla del sitio admirado: la página entera, luego zooms sobre las zonas clave (header, sección hero, retícula de productos, footer). Arrástralas directamente a Claude Code — lee las imágenes nativamente, tanto en la extensión como en la terminal. Pero no pidas «hazme el mismo sitio»: obtendrías una imitación aproximada. Pide primero un análisis estructurado, porque es lo que transforma una impresión visual en especificaciones explotables:

analiza esta captura de pantalla de sitio web como un diseñador senior.
dame un análisis estructurado:

1. LAYOUT: estructura de la página, retícula (número de columnas, medianiles), ancho máximo del contenido
2. PALETA: cada color en hex, su rol (fondo, texto, acento, bordes), los ratios de uso
3. TIPOGRAFÍA: familias probables, tamaños (título/subtítulo/cuerpo), pesos, interlineado, caja
4. ESPACIADOS: el ritmo vertical entre secciones, los paddings internos de tarjetas/botones
5. JERARQUÍA: en qué orden circula el ojo, y qué procedimientos crean ese orden (tamaño, contraste, espacio)
6. FIRMA: las 3 decisiones que dan su personalidad a este diseño

no generes NINGÚN código por ahora.

El «no generes ningún código por ahora» es deliberado: es el Plan Mode del capítulo 2 aplicado al diseño. Primero quieres validar que el análisis capta lo que te gusta de ese sitio. Lee en particular el punto 6 — la «firma» — y corrige si hace falta: «no, lo que más me gusta es el contraste entre las fotos grandes y el texto minúsculo». Esa conversación encuadra todo lo que sigue.

Etapa 2: extraer los design tokens

Validado el análisis, se convierte en design tokens: variables CSS que codifican cada decisión visual (colores, tamaños, espaciados). Es la etapa que lo cambia todo respecto a un clonado ingenuo: los tokens separan el sistema de diseño (reutilizable) de los valores (que Lea reemplazará por los suyos). Este es el prompt completo:

a partir de tu análisis, genera un archivo tokens.css que contenga los design tokens en variables CSS:

:root {
  /* colores: fondo, superficie, texto, texto-secundario, acento, acento-hover, borde */
  /* tipo: familias, tamaños (escala modular), pesos, interlineados */
  /* espaciados: escala (xs, sm, md, lg, xl, 2xl) coherente con el ritmo observado */
  /* varios: radius, sombras, ancho máximo del contenido */
}

restricciones:
- cada variable está comentada con su rol
- la escala de espaciado debe ser una verdadera escala (ratio constante), no valores al azar
- propón después una SEGUNDA paleta: misma lógica de contrastes, pero con los colores de mi marca (verde salvia #87A96B, crema #F5F0E8, marrón #5C4033)

Mira bien la última restricción: pedimos la transposición hacia la paleta de Lea desde esta etapa. El diseño admirado proporciona la lógica de los contrastes (fondo claro, acento saturado usado con moderación, texto casi negro pero no del todo); los valores se vuelven los de la marca. Es el momento preciso donde el proyecto deja de ser una copia para convertirse en una creación informada.

Etapa 3: reconstruir TU versión

Solo ahora se construye — con los contenidos de Lea: sus productos, sus fotos, sus textos (que tu skill /post ya sabe redactar en su voz). Pide una página que consuma exclusivamente los tokens: ningún color ni tamaño en duro en el HTML. Esta disciplina paga doblemente: cambiar un token actualiza todo el sitio, y puedes hacer evolucionar la paleta sin tocar la estructura.

construye mi página de inicio en HTML/CSS usando exclusivamente
las variables de tokens.css (ningún valor en duro).

estructura: header depurado, sección hero con mi foto de la gama solar,
retícula de 3 productos, banda «compromisos», footer.
contenidos: usa los textos de content/inicio.md.
imágenes: solo las de la carpeta assets/ (mis fotos).

respeta el layout y el ritmo analizados, NO los contenidos del sitio original.

Etapa 4: iterar por diferencias

La primera versión estará cerca pero no será exacta — es normal, y la peor reacción sería volver a pedirlo todo en bloque («todavía no es eso, empieza de nuevo»). El buen método es la iteración por diferencias: se compara sistemáticamente, se lista, se corrige punto por punto. Es el mismo bucle de afinado que en el capítulo 4 para la voz de marca, aplicado al píxel:

aquí tienes una captura de MI página actual y la captura del sitio de referencia.
compara las dos como un director de arte y lista las 10 diferencias
más visibles, ordenadas por impacto visual decreciente.

para cada diferencia: lo que hace la referencia, lo que hace mi versión,
y la corrección precisa (qué token o qué regla CSS modificar).

luego corrígelas UNA POR UNA mostrándome el resultado en cada etapa.

El «una por una» tiene la misma función que en el encuadre del capítulo 3: hace cada cambio observable. Si una corrección degrada el conjunto (ocurre — el espaciado perfecto de la referencia puede ahogar tus contenidos más densos), la rechazas por separado en lugar de tirar todo el lote. Dos o tres pasadas de este bucle bastan generalmente para pasar de «parecido» a «acabado profesional».

Ir más lejos: analizar la estructura real de una página pública

Las capturas muestran el renderizado, no la mecánica. Para entender cómo se obtiene un efecto (esa retícula que se reorganiza elegantemente en móvil, ese header que se condensa al hacer scroll), puedes pedir a Claude recuperar una URL pública y analizar el HTML/CSS real — es la herramienta WebFetch, que autorizaste en el capítulo 2:

recupera https://ejemplo-de-marca.com y analiza la estructura:
- cómo está construida la retícula de productos (¿grid? ¿flex? ¿breakpoints?)
- cómo gestiona el header el scroll y el móvil
- qué variables CSS o convenciones de nombrado usan

objetivo: entender la TÉCNICA para aplicar la misma lógica
a mi página, con mis tokens. no copies ningún contenido ni ningún asset.

flowchart LR
  A["Captura de pantalla del sitio admirado"] --> B["Análisis estructurado (diseñador senior)"]
  B --> C["Design tokens: tokens.css"]
  C --> D["Reconstrucción con TUS contenidos y TU paleta"]
  D --> E["Comparación lado a lado: 10 diferencias"]
  E -->|"Correcciones una por una"| D
  E -->|"Acabado alcanzado"| F["Página de Lea en línea"]

La frontera ética y legal: inspirarse, no copiar

Hablemos francamente de la línea que no hay que cruzar, porque es más nítida de lo que se cree. Las ideas de diseño — una retícula, unas proporciones, un ritmo de espaciados, el principio de una paleta suave — no se pueden apropiar: toda la web se inspira en toda la web, y así es como progresan los estándares. En cambio, los assets son obras protegidas: logos, ilustraciones, fotos, iconos dibujados a medida, textos. Copiarlos no es inspiración, es infracción — da igual que sea «solo para inspirarse» o que Claude lo haya hecho por ti.

Barreras técnicas: blindar el proyecto con allow/deny

Una obra de rediseño implica muchos comandos: instalación de dependencias, servidores locales, manipulaciones de archivos. Es el buen momento para profundizar los permisos del capítulo 2 con una verdadera política allow/deny escrita en .claude/settings.json — por tanto commiteada y compartida con quien se una al proyecto:

{
  "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.*)"
    ]
  }
}

Lee la lista deny línea por línea, porque cada regla cuenta un accidente evitado: rm -rf (la eliminación recursiva que se lleva una carpeta entera por una ruta mal construida), git push --force (que puede aplastar el historial compartido), y la lectura de .env — sí, se puede prohibir a Claude leer un archivo: tus claves API no aparecerán nunca en el contexto, y por tanto nunca en una respuesta. Y recuerda el capítulo 2: deny siempre prevalece sobre allow, incluso si una regla de autorización amplia lo engloba.

Completa con CLAUDE.local.md para tus preferencias personales de obra: «el servidor de previsualización corre en el puerto 4321», «mis capturas de referencia están en ~/Escritorio/refs/». Esos detalles te pertenecen; no tienen nada que hacer en la memoria común del proyecto.

Permiso o hook: dos cerraduras complementarias

Ahora dispones de dos mecanismos de protección, y es útil ver con precisión cómo se articulan:

La regla de reparto: lo que está prohibido siempre y en todas partes corresponde a los permisos — es binario, mejor declararlo una vez. Lo que depende del contenido («¿este post supera el límite? ¿respeta la voz?») corresponde a un hook, porque hay que examinar para decidir. Las dos capas juntas, más la validación humana en el punto de palanca (capítulo 7), forman la defensa en profundidad de tu sistema: Lea puede dejar a Claude trabajar rápido precisamente porque las barreras, ellas, nunca duermen.