Slice Mockup a HTML

¿Qué hace Slice Mockup a HTML?

Copia un mockup a HTML fielmente; no lo rediseñes. Un resultado correcto, superpuesto al mockup, muestra casi ninguna diferencia. La creatividad, las "mejoras" y las características extra cuentan como errores.

Flujo de trabajo (en orden, no saltar pasos)

1. Recibir el mockup

Confirma que el mockup realmente existe (revisa /mnt/user-data/uploads y la conversación); si no, pídelo, nunca adivines. Si tiene muchas páginas/frames, pregunta cuál construir.

Formatos admitidos: PNG, SVG, Figma vía MCP (JPG se trata como PNG). Para cualquier otro formato, pide al usuario que exporte PNG o SVG. Cómo leer cada entrada está en references/mockup-audit.md. Para Figma, carga la habilidad figma:figma-design-to-code antes de llamar get_design_context.

2. Hacer las dos preguntas

Haz ambas juntas, antes de la auditoría y antes de codificar. Omite una pregunta si el usuario ya la respondió. Usa ask_user_input_v0 si está disponible (una llamada, dos preguntas); de lo contrario, pregunta en texto plano breve.

1. Formato de salida: Archivo único (HTML, CSS, JS inline en un index.html, más assets/) o Archivos separados (index.html, css/style.css, js/main.js, más assets/)
2. CSS: Vanilla CSS, Bootstrap vía CDN o Tailwind vía CDN

Después de las respuestas, lee references/output-structure.md y el archivo correspondiente: references/vanilla.md, references/bootstrap.md o references/tailwind.md. No leas los otros dos.

3. Auditar antes de codificar

Lee references/mockup-audit.md y produce la especificación de auditoría (lienzo, contenedor, rejilla, colores, fuentes, espaciado, radio, sombras, assets, interacciones visibles), cada valor marcado como medido o estimado. Muestra al usuario un resumen solo si se necesita una decisión (fuente no identificable, asset faltante); de lo contrario, continúa.

4. Escribir el código

• Reglas: references/responsive-and-fidelity.md (perfecto en píxeles y responsivo), references/code-standards.md (HTML semántico, BEM), references/anti-slop.md (prohibiciones). Aplícalas mientras escribes, no después.
• Los valores en el ancho del mockup deben coincidir exactamente con la auditoría (px, no redondeados a una escala de framework).
• JS solo para componentes interactivos visibles en el mockup, siguiendo la prueba de contenido en anti-slop.md (construye el comportamiento cuando el mockup tenga el contenido necesario, de lo contrario mantenlo estático e infórmalo); sin bibliotecas adicionales más allá de las que requiere el framework elegido.

5. Verificar

Sigue los pasos de verificación en references/responsive-and-fidelity.md, luego ejecuta la comprobación final en references/anti-slop.md. Si el sandbox no puede renderizar, dilo claramente.

6. Entregar

Guarda en /mnt/user-data/outputs// y comparte con present_files. Para más de un archivo, empaqueta un solo .zip con la estructura de carpetas intacta (para que las rutas de assets sigan siendo válidas) y también presenta index.html.

Luego da un reporte de máximo unas 6 líneas, solo lo que el usuario necesita saber: fuentes no identificadas y sus sustitutos, valores estimados, assets placeholder, iconos que no pudieron recrearse o exceden el presupuesto de tamaño, comportamiento interactivo implementado o dejado estático por falta de contenido, y partes de tableta/móvil derivadas porque el mockup carece de ellas. Sin sugerencias de características, ideas de mejora o autoevaluación.

Principios fundamentales

• Fidelidad ante todo. Si el mockup se ve débil, cópialo tal cual.
• No agregues nada ausente del mockup; no adivines en silencio: cada suposición con impacto visual va en el reporte.
• Copia el texto exactamente, incluyendo mayúsculas, puntuación y números; marca el texto ilegible.