falconair/wireframes

¿Qué hace wireframes?

Resumen

Una propuesta de UI es una imagen, no un párrafo de prosa. Dibuja cada cambio como un wireframe económico: el Ahora junto al Propuesto, barras grises para todo lo que permanece igual, etiquetas reales solo en los elementos bajo discusión y una frase de por qué. No reproduce el aspecto real de la app: sin colores de marca, sin fuentes reales, sin fidelidad de píxeles. El usuario ve el cambio de un vistazo y dibujarlo cuesta pocos tokens.

Cuándo no usarlo: el cambio es puramente visual (color, contraste, fuentes, tokens de espaciado); descríbelo o muestra CSS real. O el usuario ya ha decidido y te pidió que lo construyas, así que constrúyelo. O nada sobre layout, controles o flujo cambia.

El resultado

Un único archivo HTML auto-contenido, construido así:

1. Ruta: docs/mockups/YYYY-MM-DD-<tema>.html en el proyecto, para que los mockups se guarden junto con el código y puedan committearse. Si el proyecto ya guarda mockups en otra carpeta mockups/, usa esa en su lugar.
2. Cabecera: copia todo desde <!doctype html> hasta </style></head><body> en kit.html textualmente. Cambia solo <title>. Usa solo las clases del kit. El style inline es para tamaño y espaciado (width, height, margin, la posición de un .menu), nunca color.
3. <h1> y una línea .lede.
4. Una sección por cambio: <h2>N · resultado en palabras del usuario</h2>, luego un layout:

Situación	Layout	Etiquetas
Algo existe y debe cambiar	.pair: Ahora, luego Propuesto	.lbl.b "Ahora: qué está mal" · .lbl.g "Propuesto: qué cambia"
La solución no está decidida	.opts: 2-3 opciones, con un pequeño .solo Ahora encima si existe	.lbl.o "A · nombre (recomendado)"; .why "+ ganancia · − costo"
No existe nada aún	.solo: solo Propuesto	.lbl.g; callouts numerados .n explicados en .why
Un elemento a través de estados o anchos	.strip: un frame por estado	.lbl "Vacío", "Cargando", "Error", "Teléfono"…; como máximo un .why debajo de la tira

5. Cada lado de un .pair, y cada opción, lleva una etiqueta (máximo 10 palabras), su frame o frames y una frase .why. Usa dos frames en un lado cuando el cambio es una secuencia (menú, luego el toast que le sigue).

Lee kit.html una vez: debajo del CSS tiene un ejemplo práctico de cada layout y un índice de todas las clases.

Reglas de dibujo

• Texto real solo donde está la decisión: el control cambiado, sus vecinos inmediatos y el nombre de la app o la ruta de navegación para orientación. Todo lo demás es .box (línea de texto, establece width), .img (imagen o gráfico) o una .row de barras grises.
• Marca el único control que cambia: .bad (rojo discontinuo) sobre el problema en Ahora, .good (verde sólido) sobre el cambio en Propuesto y sobre lo que distingue cada opción. No marques nada en un .strip. Delinea el control, nunca una barra de ancho completo ni un frame entero, porque los frames recortan los delineados en sus bordes.
• Algo que falta: dibuja un hueco discontinuo vacío donde debería estar (<span class="in bad">no hay búsqueda aquí</span>), no un delineado en un elemento cercano.
• Ajusta unos 800px: cada columna de .pair mide unos 380px, así que limita una .bar a unos 5 elementos.
• Tipo de app: web o escritorio → .f; pantallas estrechas o móvil nativo → .phone; terminal UI → .f.mono.pad con líneas de texto reales y barras grises para la salida sin cambios.
• Preguntas abiertas van en el .why de ese lado, formuladas como pregunta.
• Presupuesto: a 15 KB por archivo o menos. Una sección de más de 1.5 KB dibuja contenido sobre el que nadie decide, así que reemplaza ese contenido por barras grises.

Verifícalo antes de mostrar

Si hay disponible una herramienta de navegador que pueda hacer capturas de pantalla, abre el archivo y mira. En la aplicación de escritorio de Claude, eso significa mcp__Claude_Browser__preview_start con url: file://<ruta absoluta>, luego mcp__Claude_Browser__computer con acción screenshot. Si el navegador rechaza el archivo local, trata la página como no vista (ver más abajo). Comprueba que cada delineado esté sobre su elemento previsto, que nada esté recortado o envuelto y que las superposiciones no oculten lo que explican. Corrige y vuelve a mirar.

Sin herramienta de captura (CLI, headless, subagente), relee el marcado contra esas comprobaciones y di en la entrega que la página no ha sido vista.

Entrégalo

En el chat, escribe solo:

• el archivo como un enlace en markdown relativo a la raíz del proyecto;
• una línea por sección: número, título y estado ("listo", "elige A/B/C" o la pregunta abierta);
• las decisiones que necesitas: una frase cada una, tu elección y la razón principal única.

Los dibujos y sus líneas .why llevan los detalles y las compensaciones, así que no los describas de nuevo. Espera las elecciones del usuario antes de construir. Sin un usuario a quien preguntar (subagente, headless), devuelve las mismas tres cosas y detente.

Errores comunes

Error	En su lugar
Etiquetar cada elemento	Etiqueta solo lo que toca la decisión
Reestilizar para que coincida con la app	CSS del kit textual; barras grises
Un párrafo por dibujo en el chat	Enlace, una línea por sección, decisiones