Sketch
Usa 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 enviable.
Cárgala cuando el usuario diga cosas como "bosqueja esta pantalla", "muéstrame cómo se vería X", "compara el diseño A vs B", "dame 2-3 opciones para esta UI", "déjame ver algunas variantes", "maqueta esto antes de construirlo".
Cuándo NO usarla
- El usuario quiere un componente de producción — usa
claude-designo constrúyelo adecuadamente - El usuario quiere un artefacto HTML pulido de una sola vez (página de aterrizaje, deck) —
claude-design - El usuario quiere un diagrama —
excalidraw,architecture-diagram - El diseño ya está decidido — simplemente constrúyelo
Si el usuario tiene el sistema GSD completo instalado
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: directorio persistente .planning/sketches/ con MANIFEST, análisis en modo frontier, auditorías de consistencia entre bocetos pasados e integración con el resto de GSD. Esta habilidad es la versión independiente ligera — bocetos únicos sin la maquinaria de estado.
Método principal
recopilar → variantes → comparación → elegir ganadora (o iterar)
1. Recopilar (omitir si el usuario ya ha dado suficiente información)
Antes de generar variantes, obtén tres cosas — una pregunta a la vez, no todas juntas:
- Feeling. "¿Qué sensación debería transmitir? Adjetivos, emociones, un ambiente." — "tranquilo, editorial, como Linear" te dice más que "minimalista".
- Referencias. "¿Qué aplicaciones, sitios o productos capturan la sensación que imaginas?" — las referencias reales superan a las descripciones abstractas.
- Acción principal. "¿Qué es lo más importante que hace un usuario en esta pantalla?" — las variantes deben servir bien todas; si no lo hacen, son solo decoración.
Reflexiona brevemente cada respuesta antes de la siguiente pregunta. Si el usuario ya ha dado las tres de antemano, salta directamente a las variantes.
2. Variantes (2-3, nunca 1, rara vez 4+)
Produce 2-3 variantes de una sola vez. Cada variante es un archivo HTML completo e independiente. No describas las variantes — constrúyelas. El objetivo es la comparación.
Cada variante debe adoptar una postura de diseño diferente, no valores de píxeles distintos. Tres buenos ejes de variantes:
- Densidad: compacto / aireado / ultra-denso (elige dos polos contrastantes)
- Énfasis: contenido primero / acción primero / herramienta primero
- Estética: editorial / utilitario / lúdico
- Distribución: una columna / barra lateral / panel dividido
- Base: basado en tarjetas / contenido simple / estilo documento
Elige un eje y sepárate de él. Dos variantes que solo difieren en el color de acento son esfuerzo desperdiciado — el usuario no puede distinguirlas.
Nombres de las 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. Hazlas HTML real
Cada variante es un único archivo HTML autocontenido:
<style>en línea — sin paso de compilación, sin CSS externo- Fuentes del sistema o una fuente de Google mediante
<link> - Tailwind vía CDN (
<script src="https://cdn.tailwindcss.com"></script>) está bien - Contenido falso realista — oraciones reales, nombres reales, no "Lorem ipsum"
- Interactivas: enlaces cliqueables, hovers reales, al menos una transición de estado (abrir/cerrar, filtrar, alternar). Una imagen estática congelada es peor que una animada descuidada.
Ábrelo en un navegador. Si se ve roto, arréglalo antes de mostrarlo al usuario.
Verifica visualmente las variantes — 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="¿Se ve este diseño limpio y legible? ¿Algún error visible (texto superpuesto, elementos sin estilo, imágenes rotas)?")
browser_vision devuelve una descripción de IA de lo que realmente hay en la página más una ruta de captura de pantalla — detecta errores de diseño 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ó). Arregla y vuelve a navegar hasta que cada variante se vea bien.
Reseteo CSS por defecto + pila de fuentes del sistema para arranques 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:
## Variante: {nombre de la postura}
### Postura de diseño
Una frase sobre el principio que impulsa esta variante.
### Decisiones clave
- Distribución: ...
- Tipografía: ...
- Color: ...
- Interacción: ...
### Compensaciones
- Fuerte en: ...
- Débil en: ...
### Mejor para
- El tipo de usuario o caso de uso al que esta variante realmente sirve
5. Comparación
Después de construir todas las variantes, preséntalas como una comparación. No solo las enumeres — opina:
## Tres opciones para la pantalla de inicio
| Dimensión | Calm editorial | Utilitarian dense | Playful split |
|-----------|----------------|-------------------|---------------|
| Densidad | Baja | Alta | Media |
| Visibilidad de la acción principal | Baja | Alta | Media |
| Facilidad de escaneo | Alta | Media | Baja |
| Sensación | Tranquila, confiable | Afilada, tipo herramienta | Acogedora, enérgica |
**Mi opinión:** Utilitarian dense para usuarios avanzados, calm editorial para audiencias centradas en contenido. Playful split es la más débil — intenta hacer ambas y no se compromete con ninguna.
Deja que el usuario elija una ganadora, 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), coloca 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 sobretokenices un boceto desechable — tres colores y una fuente suelen ser suficientes.
Barra de interactividad
Un boceto es suficientemente interactivo cuando el usuario puede:
- Hacer clic en una acción principal y algo visible ocurre (cambio de estado, modal, toast, fingir navegación)
- Ver una transición de estado significativa (filtrar una lista, cambiar un modo, abrir/cerrar un panel)
- Pasar el ratón sobre indicadores reconocibles (botones, filas, pestañas)
Más que eso es sobrediseñar algo desechable. Menos que eso es una captura de pantalla.
Modo frontier (elegir 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 combinado
- Pantallas no bocetadas — referenciadas pero nunca exploradas
- Cobertura de estados — el camino feliz está bocetado, pero no vacío / cargando / error / 1000 elementos
- Brechas responsivas — validado en un viewport; ¿se mantiene en móvil / ultraancho?
- Patrones de interacción — existen diseños estáticos; transiciones, arrastre, comportamiento de scroll no
Propón 2-4 candidatos nombrados. Deja que el usuario elija.
Salida
- Crea
sketches/(o.planning/sketches/si el usuario sigue las convenciones GSD) en la raíz del repositorio - Una subcarpeta por variante:
NNN-postura-nombre/index.html+README.md - Indica al usuario cómo abrirlos:
open sketches/001-calm-editorial/index.htmlen macOS,xdg-openen Linux,starten Windows - Mantén las variantes desechables — un boceto que sentiste que debías conservar debe promoverse a código real del proyecto, no conservarse como 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", "## Variante: Calm editorial\n...")
browser_navigate(url="file://$(pwd)/sketches/001-calm-editorial/index.html")
browser_vision(question="¿Cómo se ve esto? ¿Algún problema de diseño obvio?")
Repite para cada variante, luego presenta la tabla comparativa.
Atribución
Adaptado del flujo de trabajo /gsd-sketch del proyecto GSD (Get Shit Done) — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done). El sistema GSD completo incluye estado de boceto persistente, referencias de patrones de tema/variante y flujos de trabajo de auditoría de consistencia; instala con npx get-shit-done-cc --hermes --global.