Creador de maquetas HTML

Boceto

Utiliza esta habilidad cuando el usuario quiera ver una dirección de diseño antes de comprometerse con una — explorando una idea de UI/UX como maquetas HTML desechables. El objetivo es generar 2-3 variantes interactivas para que el usuario pueda comparar direcciones visuales lado a lado, no producir código listo para producción.

Carga esta habilidad cuando el usuario diga cosas como "bocetear esta pantalla", "muéstrame cómo podría verse X", "compara el layout A vs B", "dame 2-3 enfoques de esta UI", "déjame ver algunas variantes", "maqueta esto antes de que lo construya".

Cuándo NO usar esto

• El usuario quiere un componente de producción — usa claude-design o constrúyelo correctamente
• El usuario quiere un artefacto HTML pulido de un solo uso (página de aterrizaje, presentación) — claude-design
• El usuario quiere un diagrama — excalidraw, architecture-diagram
• El diseño ya está decidido — simplemente constrúyelo

Si el usuario tiene instalado el sistema GSD completo

Si gsd-sketch aparece como una habilidad hermana (instalada mediante npx get-shit-done-cc --hermes), prefiere gsd-sketch para el flujo de trabajo completo: .planning/sketches/ persistente con MANIFEST, análisis en modo frontera, auditorías de consistencia entre bocetos previos, e integración con el resto de GSD. Esta habilidad es la versión ligera independiente — bocetos de un solo uso sin la maquinaria de estado.

Método principal

intake  →  variants  →  head-to-head  →  pick winner (or iterate)

1. Entrada (omítelo si el usuario ya te ha dado suficiente)

Antes de generar variantes, obtén tres cosas — una pregunta a la vez, no todas a la vez:

1. Sensación. "¿Qué sensación debería transmitir? Adjetivos, emociones, una vibración." — "tranquilo, editorial, como Lineal" te dice más que "minimalista".
2. Referencias. "¿Qué aplicaciones, sitios o productos capturan la sensación que estás imaginando?" — las referencias reales superan las descripciones abstractas.
3. Acción principal. "¿Cuál es la cosa más importante que un usuario hace en esta pantalla?" — las variantes deberían servir a esto bien; si no lo hacen, son solo decoración.

Reflexiona brevemente sobre cada respuesta antes de la siguiente pregunta. Si el usuario ya te ha dado las tres por adelantado, salta directamente a las variantes.

2. Variantes (2-3, nunca 1, raramente 4 o más)

Produce 2-3 variantes de una sola vez. Cada variante es un archivo HTML completo e independiente. No describas las variantes — constrúyelas. El punto es la comparación.

Cada variante debe adoptar una postura de diseño diferente, no diferentes valores de píxeles. Tres buenos ejes de variación:

• Densidad: compacto / aireado / ultra-denso (elige dos polos contrastantes)
• Énfasis: contenido primero / acción primero / herramienta primero
• Estética: editorial / utilitario / lúdico
• Layout: columna única / barra lateral / panel dividido
• Base: basado en tarjetas / contenido desnudo / estilo documento

Elige un eje y separa a partir de él. Dos variantes que difieren solo en el color de acento son un esfuerzo desperdiciado — el usuario no puede distinguirlas.

Nombrado de variantes: describe la postura, no el número.

sketches/
├── 001-calm-editorial/
│   ├── index.html
│   └── README.md
├── 001-utilitarian-dense/
│   ├── index.html
│   └── README.md
└── 001-playful-split/
    ├── index.html
    └── README.md

3. Hazlos HTML reales

Cada variante es un único archivo HTML autocontenido:

• <style> en línea — sin paso de construcción, sin CSS externo
• Fuentes del sistema o una fuente de Google Fonts vía <link>
• Tailwind vía CDN (<script src="https://cdn.tailwindcss.com"></script>) está bien
• Contenido falso realista — frases reales, nombres reales, no "Lorem ipsum"
• Interactivo: enlaces clicables, hovers reales, al menos una transición de estado (abrir/cerrar, filtrar, alternar). Una imagen estática congelada es un peor prototipo que uno con animación descuidada.

Ábrelo en un navegador. Si se ve roto, arréglalo antes de mostrárselo al usuario.

Verifica las variantes visualmente — usa las herramientas de navegador de Hermes. No solo escribas HTML y esperes que se renderice; carga cada variante y mírala:

browser_navigate(url="file:///absolute/path/to/sketches/001-calm-editorial/index.html")
browser_vision(question="Does this layout look clean and readable? Any visible bugs (overlapping text, unstyled elements, broken images)?")

browser_vision devuelve una descripción de IA de lo que hay realmente en la página más una ruta de captura de pantalla — detecta errores de layout que la inspección pura del código fuente pasa por alto (por ejemplo, una importación de fuente que falló silenciosamente, un contenedor flex que colapsó). Corrige y vuelve a navegar hasta que cada variante se vea bien.

Reset CSS por defecto + pila de fuentes del sistema para inicios rápidos:

<style>
  * { box-sizing: border-box; margin: 0; padding: 0; }
  body {
    font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
                 "Helvetica Neue", Arial, sans-serif;
    -webkit-font-smoothing: antialiased;
    color: #1a1a1a;
    background: #fafafa;
    line-height: 1.5;
  }
</style>

4. README de la variante

El README.md de cada variante responde:

## Variant: {stance name}

### Design stance
One sentence on the principle driving this variant.

### Key choices
- Layout: ...
- Typography: ...
- Color: ...
- Interaction: ...

### Trade-offs
- Strong at: ...
- Weak at: ...

### Best for
- The kind of user or use case this variant actually serves

5. Comparación directa

Después de que todas las variantes estén construidas, preséntalas como una comparación. No solo las enumeres — opina:

## Three takes on the home screen

| Dimension | Calm editorial | Utilitarian dense | Playful split |
|-----------|----------------|-------------------|---------------|
| Density   | Low            | High              | Medium        |
| Primary action visibility | Low | High | Medium |
| Scan-ability | High | Medium | Low |
| Feel | Calm, trusted | Sharp, tool-like | Inviting, energetic |

**My take:** Utilitarian dense for power users, calm editorial for content-forward audiences. Playful split is weakest — tries to do both and commits to neither.

Deja que el usuario elija un ganador, o combine dos en un híbrido, o pida otra ronda.

Tematización (cuando el proyecto tiene una identidad visual)

Si el usuario tiene un tema existente (colores, fuentes, tokens), pon los tokens compartidos en sketches/themes/tokens.css e impórtalos con @import en cada variante. Mantén los tokens mínimos:

/* sketches/themes/tokens.css */
:root {
  --color-bg: #fafafa;
  --color-fg: #1a1a1a;
  --color-accent: #0066ff;
  --color-muted: #666;
  --radius: 8px;
  --font-display: "Inter", sans-serif;
  --font-body: -apple-system, BlinkMacSystemFont, sans-serif;
}

No sobre-tokenices un boceto desechable — tres colores y una fuente suelen ser suficientes.

Barra de interactividad

Un boceto es suficientemente interactivo cuando el usuario puede:

1. Hacer clic en una acción principal y que ocurra algo visible (cambio de estado, modal, notificación, amago de navegación)
2. Ver una transición de estado significativa (filtrar una lista, alternar un modo, abrir/cerrar un panel)
3. Pasar el ratón sobre elementos reconocibles (botones, filas, pestañas)

Más que eso es sobre-ingeniería para algo desechable. Menos que eso es una captura de pantalla.

Modo frontera (decidiendo qué bocetar a continuación)

Si ya existen bocetos y el usuario dice "¿qué debería bocetar a continuación?":

• Brechas de consistencia — dos variantes ganadoras de diferentes bocetos tomaron decisiones independientes que aún no se han compuesto juntas
• Pantallas no bocetadas — referenciadas pero nunca exploradas
• Cobertura de estados — camino feliz bocetado, pero no vacío / carga / error / 1000 elementos
• Brechas responsive — validado en un viewport; ¿se mantiene en móvil / ultra ancho?
• Patrones de interacción — existen layouts estáticos; las transiciones, el arrastre, el comportamiento del scroll no

Propón 2-4 candidatos con nombre. Deja que el usuario elija.

Salida

• Crea sketches/ (o .planning/sketches/ si el usuario está usando convenciones GSD) en la raíz del repositorio
• Un subdirectorio por variante: NNN-nombre-postura/index.html + README.md
• Dile al usuario cómo abrirlos: open sketches/001-calm-editorial/index.html en macOS, xdg-open en Linux, start en Windows
• Mantén las variantes desechables — un boceto que sentiste la necesidad de preservar debería promocionarse a código real del proyecto, no conservarse como un activo

Secuencia de herramientas típica para una variante:

terminal("mkdir -p sketches/001-calm-editorial")
write_file("sketches/001-calm-editorial/index.html", "<!doctype html>...")
write_file("sketches/001-calm-editorial/README.md", "## Variant: Calm editorial\n...")
browser_navigate(url="file://$(pwd)/sketches/001-calm-editorial/index.html")
browser_vision(question="How does this look? Any obvious layout issues?")

Repite para cada variante, luego presenta la tabla de comparación.

Atribución

Adaptado del flujo de trabajo /gsd-sketch del proyecto GSD (Haz la Mierda) — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done). El sistema GSD completo incluye estado persistente de bocetos, patrones de referencia de temas/variantes y flujos de trabajo de auditoría de consistencia; instálalo con npx get-shit-done-cc --hermes --global.