FReptar0/design-guard

Genera un archivo DESIGN.md completo para un proyecto web usando Google Stitch.

Instrucciones

0. Verificación de descubrimiento (DEBE ejecutarse antes que cualquier otra cosa):
   • Verifica si el directorio .dg-research/ existe y contiene archivos JSON.
   • SI .dg-research/ NO existe Y el usuario ha mencionado un nombre de negocio, empresa, marca, cafetería, restaurante, tienda o entidad del mundo real específico:
     • DETENTE. Indica al usuario: "Recomiendo ejecutar /dg-discover primero para investigar [nombre del negocio]. Esto produce un DESIGN.md basado en datos reales del mercado y la competencia, en lugar de valores por defecto de la IA. ¿Quieres que ejecute /dg-discover en su lugar?"
     • Solo continúa con /dg-design si el usuario indica explícitamente que quiere omitir la investigación.
   • SI .dg-research/ existe con archivos JSON: Lee .dg-research/latest.json para obtener el brief del negocio, el análisis de la competencia y los colores de la marca. Estos datos de investigación son tu FUENTE PRINCIPAL para el contexto del negocio — utilízalos por encima de cualquier contexto a nivel de proyecto proveniente de CLAUDE.md. Procede al paso 1.
   • SI la solicitud del usuario es genérica (no se menciona un negocio específico, p. ej., "haz un sitio portafolio" o "crea un panel SaaS"): procede directamente al paso 1. La investigación es para negocios reales, no para proyectos genéricos.

Aislamiento de Contexto (CRÍTICO — leer antes de generar)

Al generar un DESIGN.md, distingue entre dos contextos:

1. Proyecto anfitrión — el código base en el que te estás ejecutando (Design Guard). CLAUDE.md describe ESTE proyecto. Su modelo de negocio, características, comandos CLI, conteo de pruebas y arquitectura técnica se refieren a Design Guard, NO al negocio objetivo del usuario.

2. Negocio objetivo — el negocio para el cual el usuario quiere un DESIGN.md. Esto proviene de:

   • El brief de marca que proporciona el usuario (Paso 1)
   • Los datos de investigación en .dg-research/latest.json (si están disponibles desde /dg-discover — esta es tu FUENTE PRINCIPAL)
   • Resultados de WebSearch/WebFetch sobre el negocio objetivo

Reglas:

• SI el negocio objetivo es DIFERENTE de Design Guard:

  • NO uses descripciones del negocio, listas de características, estadísticas ni detalles técnicos de CLAUDE.md
  • NO hagas referencia a comandos CLI, conteo de pruebas, TypeScript, Node.js, MCP o Stitch como características del negocio objetivo
  • NO describas el objetivo como "código abierto", "inteligencia de diseño" ni ninguna frase del Resumen del Proyecto de CLAUDE.md
  • Cada hecho sobre el negocio en el DESIGN.md debe provenir del brief del usuario o de los datos de investigación
  • Si ya existe un DESIGN.md en la raíz del proyecto, NO copies sus colores, fuentes o contexto de negocio en el nuevo — genera todo desde cero a partir del brief y la investigación

• SI el negocio objetivo ES el propio Design Guard:

  • CLAUDE.md es una fuente válida de contexto del negocio — utilízalo junto con el brief del usuario

• SIGUE SIEMPRE la especificación de 8 secciones del DESIGN.md y las reglas de validación de CLAUDE.md, independientemente del negocio objetivo. Las reglas de FORMATO siempre aplican; el contexto de NEGOCIO es lo que se aísla.

1. Si el usuario proporcionó un brief de marca como argumento, úsalo. De lo contrario, pide:

   • Nombre de la empresa/producto
   • Industria o dominio
   • Audiencia objetivo
   • Dirección estética (p. ej., "corporativo premium", "startup divertida", "SaaS minimalista")

2. Genera un DESIGN.md con exactamente estas 8 secciones:

   1. Tema Visual y Ambiente — 2-3 frases evocadoras que describan la estética general. Usa adjetivos y referencias específicos, no términos genéricos.
   2. Paleta de Colores y Roles — Tabla Markdown con columnas: Rol, Nombre, Hex, Uso. Mínimo 5 roles (Primario, Secundario, Superficie, Sobre-Superficie, Error). Todos los colores como valores hexadecimales, nunca descripciones como "azul confiable". Dale a cada color un nombre descriptivo (p. ej., "Azul Marino Profundo", no solo "Primario").
   3. Tipografía — Familias de fuentes de Google Fonts (evita Inter, Poppins como principal — indican diseño generado por IA). Tamaños en rem/px, pesos como números (400/600/700), alturas de línea. Incluye encabezado, cuerpo y mono. Usa una combinación serif/sans-serif para crear contraste.
   4. Espaciado y Diseño — Unidad base (p. ej., 4px), escala, ancho máximo de contenido, sistema de cuadrícula, puntos de ruptura.
   5. Patrones de Componentes — Al menos 3 componentes (botones, tarjetas, entradas, etc.) con reglas de estructura y estilo. Varía los estilos de radio de borde y sombra.
   6. Iconografía — Estilo (contorno/sólido/duotono), tamaño por defecto, biblioteca de origen.
   7. Directrices de Imágenes — Estilo fotográfico, estilo de ilustración, relaciones de aspecto. Sé específico sobre qué comunica el contenido visual.
   8. Qué Hacer y Qué No Hacer — Al menos 3 de cada uno. DEBE incluir estos valores por defecto anti-genéricos:

   Qué Hacer

   • Usa diseños asimétricos o no estándar para al menos una sección de características
   • Varía los tamaños de las tarjetas y el espaciado para crear un ritmo visual
   • Usa exclusivamente la paleta de colores especificada (sin colores elegidos por IA)
   • Mantén un alto contraste (mínimo 4.5:1) para todo el texto
   • Varía los fondos de las secciones (alterna entre superficies claras y oscuras)

   Qué No Hacer

   • No uses Inter, Poppins ni sans-serif del sistema como fuente principal
   • No uses degradados de púrpura a azul en ninguna parte
   • No uses radio de borde uniforme (>12px) en todos los elementos
   • No uses cuadrículas estándar de tres columnas con iconos como la segunda sección de la página
   • No centres texto del cuerpo con más de 2 líneas
   • No uses ilustraciones genéricas de stock (blobs 3D, formas abstractas)

3. Reglas de validación:

   • Todos los colores deben ser valores hexadecimales (#RRGGBB)
   • Tamaños de fuente solo en rem o px
   • Al menos 5 roles de color, 3 patrones de componente, 3 Qué Hacer y 3 Qué No Hacer
   • Mantén el total por debajo de ~3000 tokens (Stitch lo lee como contexto en cada generación)

4. Si DESIGN.md ya existe, pregunta antes de sobrescribir.

5. Escribe el archivo en DESIGN.md en la raíz del proyecto.

6. Después de escribir, verifica si existe un sistema de diseño de Stitch usando mcp__stitch__list_design_systems. Si el usuario tiene un proyecto de Stitch:

   • Ofrece crear un sistema de diseño con mcp__stitch__create_design_system
   • O actualizar uno existente con mcp__stitch__update_design_system
   • Aplica el sistema de diseño al proyecto con mcp__stitch__apply_design_system para que todas las generaciones futuras lo respeten

7. Próximo paso: Sugiere ejecutar /dg-generate para crear la primera pantalla usando el nuevo sistema de diseño.

Referencia: Consulta docs/design-md-guide.md para la especificación completa.