bishoe01/blueprint-extractor

Extract

Crea un DESIGN.md fundamentado a partir de un sitio web público. Extrae patrones de diseño observables; no clones el sitio como código ejecutable ni afirmes que son directrices oficiales de la marca.

Comportamiento del Comando

Cuando el usuario escriba /extract <url>, trátalo como una solicitud para ejecutar este flujo de trabajo inmediatamente.

Si el usuario escribe solo /extract, pide la URL pública HTTPS y no comiences la extracción hasta que la proporcione.

Salida predeterminada:

• paquete de evidencia: .blueprint-extractor/<slug>/
• documento final: DESIGN.md en el proyecto actual del usuario a menos que solicite otra ruta

Flujo de Trabajo

1. Valida la URL objetivo.
2. Crea una carpeta de evidencia en .blueprint-extractor/<slug>/ dentro del proyecto del usuario.
3. Reúne evidencia a partir de los datos públicos de la página:
   • título HTML y metadatos
   • CSS vinculado e inline
   • estilos calculados de elementos representativos
   • captura de pantalla de escritorio a 1440x900 cuando las herramientas de navegador estén disponibles
   • captura de pantalla móvil a 390x844 cuando las herramientas de navegador estén disponibles
4. Extrae tokens concretos únicamente del CSS obtenido, estilos calculados o capturas de pantalla registradas.
5. Escribe blueprint.json y sources.json antes de redactar la prosa final.
6. Sintetiza DESIGN.md usando el contrato exacto de 9 secciones en references/DESIGN_TEMPLATE.md.
7. Realiza una pasada de autoevaluación antes de finalizar:
   • mejora la utilidad de implementación con recetas de componentes observadas;
   • mejora el lenguaje temático cualitativo cuando esté respaldado por capturas de pantalla;
   • separa la evidencia extraída del comportamiento inferido por captura y las guías de implementación;
   • elimina afirmaciones amplias sobre el producto que no sean visibles o estén presentes en el CSS extraído;
   • preserva el dominio, la arquitectura de información y los flujos de trabajo principales del proyecto objetivo; transfiere solo el lenguaje visual;
   • abstrae los componentes del dominio fuente antes de reutilizarlos, por ejemplo, "lista de reproducción" a "lista de colección" o "arte de álbum" a "miniatura visual";
   • mantén los ejemplos no respaldados fuera de DESIGN.md a menos que estén marcados como cualitativos o inferidos.
8. Valida el Markdown final contra la plantilla y la evidencia.
9. Informa la ruta de salida y cualquier advertencia de confianza en la respuesta final.

Seguridad de URL

Rechaza la solicitud con una breve explicación cuando la URL sea insegura o esté fuera del alcance:

• no es https://
• localhost, bucle local, IP privada, enlace local o nombre de host privado
• contenido protegido por autenticación o muro de pago
• respuesta no HTML
• inalcanzable, vacía o redirige demasiadas veces
• solicitud para eludir el inicio de sesión, extraer paneles privados, extraer Figma o clonar código ejecutable

No sigas formularios, flujos de inicio de sesión, flujos de pago, acciones destructivas o páginas específicas de usuario.

Extracción

Si scripts/extract-blueprint.mjs existe y las dependencias están disponibles, ejecútalo primero y usa sus artefactos como fuente de verdad. Si no está disponible, usa las herramientas de navegador, HTTP y sistema de archivos disponibles para reunir evidencia equivalente manualmente.

Prefiere evidencia determinista sobre la adivinanza visual:

• Los colores deben provenir de CSS, estilos calculados, atributos SVG o capturas de pantalla muestreadas.
• Las familias tipográficas deben provenir de CSS, estilos calculados o @font-face.
• Los puntos de interrupción deben provenir de media queries o estar explícitamente marcados como inferidos de capturas de pantalla.
• El espaciado, radio, sombras, bordes y movimiento deben citar CSS o estilos calculados.
• Si solo hay capturas de pantalla disponibles, mantén las observaciones cualitativas y evita tokens numéricos inventados.

Lee references/EXTRACTION_SCHEMA.md antes de crear o editar blueprint.json y sources.json. Lee references/FAILURE_MODES.md cuando la extracción sea parcial o esté bloqueada. Lee references/QUALITY_CHECKLIST.md antes de tratar un DESIGN.md generado como un buen ejemplo o salida de calidad de publicación.

Reglas de Síntesis

Usa el idioma solicitado por el usuario. Si no se solicita ningún idioma, escribe DESIGN.md en inglés.

El DESIGN.md final debe contener exactamente estas secciones H2, en este orden:

1. 1. Tema Visual y Atmósfera
2. 2. Paleta de Colores y Roles
3. 3. Reglas Tipográficas
4. 4. Estilos de Componentes
5. 5. Principios de Diseño
6. 6. Profundidad y Elevación
7. 7. Qué Hacer y Qué No Hacer
8. 8. Comportamiento Responsivo
9. 9. Guía de Indicaciones para el Agente

No agregues una sección de Fuentes, Confianza o Apéndice a DESIGN.md. Coloca las advertencias de confianza en la respuesta final del asistente o en el paquete de evidencia.

Cada token concreto en DESIGN.md debe ser rastreable hasta blueprint.json. Marca los hallazgos inciertos como observaciones cualitativas en lugar de valores exactos.

No conviertas el documento final en un volcado de tokens seco. Transforma la evidencia en guías de diseño reutilizables:

• Nombra el arquetipo del sitio solo cuando sea visible desde la página capturada, como "shell de panel", "página editorial de aterrizaje", "catálogo de comercio", "reproductor multimedia" o "sitio de documentación".
• Trata las marcas famosas de forma conservadora: no importes patrones de producto conocidos, tradición de marca o afirmaciones de sistema oficial a menos que la página capturada, CSS o muestras calculadas los respalden.
• Preserva el modelo de dominio, la estructura de información y los flujos de trabajo del usuario de la aplicación objetivo. El sitio fuente proporciona lenguaje visual, no permiso para convertir el proyecto objetivo en la categoría de producto del sitio fuente.
• Separa los rasgos de diseño transferibles de los objetos de dominio no transferibles del sitio fuente. Transfiere color, tipografía, espaciado, densidad, forma, capas de superficie y sensación de interacción; no transfieras objetos de dominio como pistas, listas de reproducción, carritos, páginas de documentación, paneles o flujos de pago a menos que el usuario solicite explícitamente esa estructura de producto.
• Cuando un componente fuente sea útil, exponlo como un patrón neutral de dominio: "barra lateral de colección/navegación" en lugar de "barra lateral de lista de reproducción", "elemento de contenido repetido" en lugar de "fila de pista", "miniatura visual o bloque de acento" en lugar de "arte de álbum".
• Preserva la distinción entre tokens observados, comportamiento de diseño inferido por captura de pantalla y guías de implementación en la prosa.
• Convierte los componentes recurrentes observados en recetas compactas: propósito, superficie, tipografía, espaciado, radio, borde/sombra, interacción.
• Prefiere patrones que se generalicen en toda la página por encima de valores decorativos puntuales.
• Distingue los puntos de interrupción extraídos de los puntos de interrupción de conveniencia de implementación.
• Usa 7. Qué Hacer y Qué No Hacer para restricciones concisas que eviten malas interpretaciones probables, incluyendo el uso excesivo de colores de acento, añadir componentes no compatibles, importar el modelo de dominio del sitio fuente o cambiar la categoría de producto del proyecto objetivo.
• Haz que 9. Guía de Indicaciones para el Agente sea práctica: referencia rápida de colores, ejemplos de indicaciones para componentes y guías de iteración cuando la evidencia lo respalde.
• Mantén la guía inspirada en el original y lista para implementación sin instruir a un agente para clonar el sitio objetivo.

Validación

Antes de finalizar:

• Confirma que DESIGN.md exista en la ruta de salida prevista.
• Confirma que los nombres y el orden de las secciones H2 coincidan con references/DESIGN_TEMPLATE.md.
• Confirma que cada color hexadecimal, familia tipográfica, punto de interrupción, radio, sombra y valor de espaciado aparezca en blueprint.json o esté explícitamente marcado como inferido/cualitativo.
• Confirma que la salida cumpla con references/QUALITY_CHECKLIST.md al crear un ejemplo o candidato de publicación.
• Si la validación falla, corrige la evidencia o degrada los valores no compatibles antes de presentar el resultado.