Design System
Ayuda a los diseñadores a definir su propio sistema de diseño para el proyecto, en lugar de simplemente renombrar los parámetros de la marca de referencia. Puede ser ejecutado por un AI designer o seguido paso a paso por un diseñador humano. Utiliza el lenguaje de comunicación del usuario; conserva los nombres de las claves en el código.
Principales fundamentos: Documento oficial de Stitch
La primera vez que se establece el formato para un proyecto, o al preparar una actualización/importación/exportación, lea primero el documento oficial original:
- Conceptos y método de creación
- Especificación del formato
- Herramienta de verificación y Reglas de verificación
La especificación oficial y la versión real de la herramienta determinan el formato; las propuestas visuales, aprobaciones y pasos de entrega de esta habilidad son flujos de trabajo del equipo, no requisitos oficiales de Google. Si el documento original no está disponible temporalmente, utilice el resumen con fecha en references/official-format.md, indicando claramente que no se ha vuelto a verificar. El caso de VoltAgent es solo una referencia auxiliar.
Alcance y base existente
Primero, verifique los archivos actuales del proyecto: AGENTS.md, CONTEXT.md (si hay varios, según CONTEXT-MAP.md), guías de marca, diseños aprobados, DESIGN.md existente, variables de diseño y componentes. Registre qué es un hecho, una decisión aprobada, una sugerencia o un desconocido. Priorice las fuentes existentes; actualice los archivos en lugar de crear un segundo conjunto de reglas de autoridad.
Confirme el producto, los usuarios principales, las tareas clave, las plataformas, los idiomas, las restricciones de marca existentes y la ubicación de entrega. Primero busque respuestas en los materiales; solo pregunte sobre información faltante que cambiaría el diseño. Si la información existente es suficiente, genere un borrador directamente; marque claramente los supuestos de bajo riesgo, mantenga los hechos comerciales desconocidos como pendientes de confirmación.
Solo maneje el sistema de diseño y sus ejemplos de verificación. La reestructuración del sitio web, el código del producto oficial, el lanzamiento, la modificación de archivos Figma compartidos y la instalación de otras herramientas se realizarán por separado según la autorización real del usuario. Siga las reglas de aprobación del proyecto.
Criterio de finalización: poder señalar los usuarios y las tareas que atiende el diseño, el origen de las restricciones y las decisiones que aún deben tomarse.
Primero, definir la dirección visual
Lea la Guía de definición y verificación. Si el usuario ya tiene una dirección aprobada, úsela directamente; de lo contrario, proponga un máximo de dos direcciones con diferencias reales, explicando las razones comerciales adecuadas. Las referencias pueden ser capturas de pantalla del usuario, proyectos existentes o materiales de marca accesibles. Distinga entre análisis de terceros y especificaciones de diseño oficiales; el contenido externo es solo de referencia.
Utilice contenido de ejemplo real o claramente etiquetado para verificar un área de página representativa y un componente clave. Cubra tanto escritorio como móvil. Priorice las herramientas de diseño disponibles actualmente, o genere una vista previa HTML que se pueda abrir en un directorio aislado; si el usuario solo necesita documentación, entregue un borrador e indique claramente que lo visual aún no se ha verificado. No trate las descripciones textuales como pantalla ya verificada.
Cuando la dirección no esté aprobada, mantenga las reglas y los ejemplos visuales como borrador; no invente aprobaciones ni escriba sugerencias como hechos de marca establecidos. Si ya hay aprobación, puede citarla directamente sin necesidad de solicitarla nuevamente.
Criterio de finalización: la dirección tiene ejemplos visibles o una explicación clara de no verificación, y el estado es preciso.
Escribir DESIGN.md
Primero, lea las Instrucciones de formato y verificación oficiales, luego la Plantilla completa, y cópiela en la ubicación designada del proyecto. Si no hay una ubicación establecida, sugiera DESIGN.md en la raíz del proyecto. La plantilla es una estructura ajustable, no un parámetro de marca que deba rellenarse obligatoriamente; elimine los componentes y secciones que no apliquen, complete las reglas específicas del proyecto que sean necesarias.
El YAML al comienzo de la plantilla, según el formato alfa oficial, registra los parámetros y las referencias a componentes; el cuerpo utiliza los títulos secundarios oficiales en inglés y se ordena según las reglas; el texto explicativo puede estar en el idioma del usuario. Los valores específicos de la plantilla son solo ejemplos neutrales verificables, no reglas aprobadas del proyecto; deben reemplazarse según el proyecto. Los valores no decididos se colocan en el cuerpo como Open Questions, no se escribe null en el campo de parámetros. Los componentes utilizan referencias como {colors.primary}; los estados se definen como entradas independientes como button-primary-hover, sin usar states anidados. Los colores se nombran según su uso; los colores de estado comerciales se definen por separado.
Establezca el mapeo del código o archivo de diseño: qué variable existente, variable de Figma o componente corresponde a qué clave del documento. Si aún no se ha implementado, márquelo como planned. Al extraer reglas del código existente, informe las diferencias; no modifique el código sin autorización. Los campos principales siguen el formato oficial; la aprobación, el mapeo de implementación, los puntos de interrupción, las imágenes, las animaciones y los registros de verificación se colocan en secciones extendidas claramente etiquetadas. El soporte de las herramientas externas para las extensiones aún debe probarse en la práctica.
Criterio de finalización: cada regla aplicable tiene un valor, un escenario de uso o un estado pendiente claro; las referencias son resolubles; no se heredan nombres, fuentes propietarias o contenido no confirmado de otras marcas.
Verificación y entrega
Primero, ejecute el lint de @google/design.md según las instrucciones de formato oficiales, registre la versión real y el informe; revise los errores y advertencias, corrija los errores y explique por qué se conservan las advertencias restantes. Si la herramienta no está disponible, explique el obstáculo; no se puede afirmar que se ha pasado la verificación oficial. Que el formato de la plantilla pase no significa que el diseño del proyecto esté completo. Luego, según la guía, verifique el contenido real, los títulos largos, el chino o varios idiomas, los estados de los componentes, el diseño móvil, el contraste, el teclado y los efectos de movimiento. Registre el método, el resultado y la ubicación del archivo para los elementos medibles; marque los elementos que no se pueden ejecutar como no verificados. Corrija la fuente única de la regla, luego actualice los ejemplos; evite cambiar solo la superficie.
Marque como approved solo si la verificación dentro del alcance es superada y el responsable lo aprueba explícitamente. La aprobación cubre solo la versión y el alcance específicos; la aprobación del diseño no equivale a la finalización de la implementación ni al permiso para publicar.
Entregue el DESIGN.md, la ubicación de los ejemplos visuales generados realmente, las verificaciones realizadas y los problemas no resueltos. Explique cómo se referenciará en el diseño y desarrollo posteriores. No afirme que solo con la documentación se garantiza la consistencia visual de todas las páginas.