Asigne un sistema de diseño a Bolt

Según la documentación de Bolt, un sistema de diseño proporciona a Bolt un conjunto de reglas visuales (colores, tipografía, espaciado, estilos de componentes) a seguir durante la construcción. El beneficio declarado es que Bolt genera código de UI basado en sus componentes reales en lugar de código provisional que tendría que sustituir posteriormente.

Existen dos niveles, y la diferencia es crucial antes de planificar su uso:

Los sistemas preinstalados son una forma excelente de comprobar la diferencia que aporta un sistema: elija uno, pulse *Try example* y compare la calidad del resultado frente a un prompt sencillo. Lo que no puede hacer es adaptarlo a su marca, ya que son de solo lectura. En el momento en que necesite una identidad propia, deberá elegir entre un plan Team o la terminal.

El modelo de Bolt es de compilación, no de carga. Su documentación indica que Bolt compila su sistema de diseño a partir de sus propias fuentes, su librería de componentes y su sitio web del sistema de diseño, y que su sistema de diseño *está definido por esas fuentes*. Cuando las fuentes cambian, se sincroniza Bolt para adoptar la versión más reciente.

Este es un modelo limpio con una consecuencia que se manifiesta más tarde: el sistema compilado es una instantánea. Entre sincronizaciones, Bolt genera código basándose en una versión de su sistema que puede ya no coincidir con lo que se ha desplegado. Este es el fallo que los equipos de sistemas de diseño ya conocen como token drift: la fuente de verdad diseñada y la desplegada divergen, y un agente que genera código con confianza basándose en una copia obsoleta produce código listo para producción sobre una base incorrecta, y más rápido que nunca. Incluya la sincronización en su lista de verificación de lanzamiento, no en su lista de tareas de mantenimiento.

No es inusual que Bolt necesite fuentes para compilar. Hemos revisado la documentación actual de cada constructor de IA y agente de código principal, y la estructura es la misma en todos ellos.

Si mantiene una librería de componentes y un sitio de documentación, el compilador de Bolt es la herramienta adecuada y debería contratar el plan Team. Si su sistema de diseño es actualmente "lo que sea que Bolt haya hecho en la primera pantalla", no hay nada que compilar, y el resto de esta página es la respuesta práctica.

Bolt es un StackBlitz WebContainer, lo que significa que ejecuta un entorno Node real con una terminal real en el navegador. Casi ninguna otra herramienta de esta categoría lo hace. Puede instalar paquetes, ejecutar generadores y escribir archivos, por lo que un sistema de diseño se instala exactamente igual que en su máquina, sin restricciones de plan ni pasos de compilación.

1. 1

   Asegúrese de que el proyecto utilice shadcn/ui

   Los starters de React + Tailwind de Bolt funcionan bien. Si el proyecto aún no ha sido inicializado con shadcn, ejecute primero npx shadcn@latest init en la terminal de Bolt.

2. 2

   Instalar el conjunto de tokens

   Ejecute el comando de registro del kit en la terminal de Bolt. Este escribe cada rol semántico, tanto claro como oscuro, en su tema, de modo que los componentes que ya referencian bg-primary se repinten sin necesidad de ser editados.

   Copy

   npx shadcn add https://identityforge.io/r/ambient-sage.json

3. 3

   Coloque el brief en el repositorio, no en el chat

   Este es el paso que la gente suele omitir. La CLI escribe un archivo DESIGN.md completo en el proyecto, por lo que las reglas sobreviven a un nuevo chat, a una recarga y a la siguiente persona que abra el proyecto.

   Copy

   npx --yes identityforge@latest apply ambient-sage

4. 4

   Hacer el prompt basándose en el sistema

   Ahora construya normalmente y nombre la restricción explícitamente las primeras veces.

   Copy

   Build a landing page using only the theme's design tokens
   and the rules in DESIGN.md. Do not add a new colour or font.

Esto surge siempre y es un instinto razonable. El repositorio es la fuente de verdad, así que lo lógico es dirigir al agente hacia él. Sin embargo, hay dos obstáculos.

El primero es práctico: un repositorio no es un sistema de diseño en un formato que un agente pueda aplicar. Son miles de archivos, la mayoría irrelevantes para una decisión de estilo, con las reglas reales distribuidas entre una configuración de Tailwind, un proveedor de temas, algunos archivos CSS y la memoria colectiva del equipo. La compilación existe precisamente porque algo debe reducir todo eso a tokens, un catálogo de componentes y un conjunto de restricciones.

El segundo es que un repositorio responde a *qué existe* y no a *qué hacer*. Contiene un Button con cinco variantes; no indica qué variante corresponde a una acción destructiva, que nunca debe poner dos acentos en una pantalla, o qué ocurre en modo oscuro en una superficie que aún no tiene variante oscura. Esos son juicios de valor, residen en la prosa y, si nadie los escribe, el agente aportará los suyos propios: de forma plausible, pero diferente cada vez.

Analizamos 299 archivos DESIGN.md públicos para ver con qué frecuencia se escriben esos juicios. El 76% enumera solo preferencias y nunca una prohibición. El 69% nunca menciona el modo oscuro. El 86% indica valores hexadecimales puros sin ningún rol semántico asociado, lo que significa que la pregunta "¿de qué color es un botón desactivado?" no tiene respuesta alguna en el archivo.

Por lo tanto: enlace el repositorio si la herramienta lo permite, pero siga escribiendo las reglas. El contenido de un archivo completo se detalla en qué es un DESIGN.md.

Si opta por la vía nativa y se pregunta si debe proporcionar a Bolt un paquete npm, una estructura de carpetas o un enlace a la documentación, la respuesta sincera es que depende de la herramienta que esté alimentando, y las herramientas difieren genuinamente:

• Bolt compila a partir de su librería de componentes y su sitio web del sistema de diseño, y se resincroniza cuando estos cambian.
• v0 requiere un paquete instalable: npm, un .tgz o un directorio de fuentes con su propio package.json, y creará uno a partir de fuentes menos estructuradas si no dispone de él.
• Lovable requiere componentes de React, entregados como un proyecto dedicado de Lovable, y los copia en los repositorios conectados.
• Los agentes de código no requieren ninguna de las opciones anteriores: necesitan un archivo de tokens y un brief escrito dentro del repositorio.

El único artefacto que aceptan las cuatro herramientas es el par al que todas ellas acaban reduciendo la información: un conjunto completo de tokens semánticos y las reglas escritas que lo acompañan. Producir estos primero no le cuesta nada si posteriormente publica un paquete, y es la única versión que funciona hoy en día en un plan gratuito.

El elemento del registro en https://identityforge.io/r/<slug>.json contiene cada rol semántico, por lo que Bolt nunca improvisa los valores que una paleta simple deja sin definir: texto atenuado, bordes, estados hover y active, ring, destructive, series de gráficos, y todos ellos de nuevo en modo oscuro. Entregar tres colores de marca define tres valores y deja aproximadamente veinticinco abiertos. Consulte explicación de tokens de color semánticos.

• Dejar el brief en el chat. Las compilaciones largas recortan el contexto. Un DESIGN.md en el proyecto no se recorta.
• Asumir que un sistema precargado puede ajustarse a su marca. Están diseñados para ser de solo lectura.
• Sincronizar solo cuando algo parece incorrecto. Para entonces, Bolt habrá estado generando contenido a partir de una instantánea obsoleta durante semanas.
• Dar a Bolt colores sin roles. Una paleta no puede responder a cómo debe verse un control deshabilitado, por lo que Bolt elige: y lo hace de forma distinta en cada pantalla.
• Omitir el modo oscuro. No es una inversión del modo claro, y es donde la improvisación se hace evidente primero.