| name | ux-critique |
| description | Critica UX de una pantalla, imagen, URL o HTML; aplica Nielsen 10, heuristicas AI opcionales, prioriza hallazgos y guarda en .ux/critique/<slug>.md. |
Critica de UX sobre una pantalla (imagen, URL, o HTML pegado). Aplica Nielsen 10 + heuristicas de AI cuando corresponde, cubre 7 dimensiones, prioriza hallazgos por severidad. Los argumentos del skill son el target a criticar y pueden venir vacios.
Skill interactivo.
Pre-flight
1. Detectar tipo de target
Trim de los argumentos del skill. Guardar como TARGET.
2. Preguntar contexto
Que pantalla es? (1 linea — ej. "login para empresas", "checkout de e-commerce", "dashboard de metricas")
Guardar CONTEXT.
La pantalla incluye features de AI (chat, autocomplete con LLM, outputs generativos)? (si/no, default: no)
Guardar HAS_AI. Si si, se aplican heuristicas extra de AI.
3. Derivar slug
Derivar <slug> desde CONTEXT (kebab-case, max 40 chars). Se usa para guardar el archivo en .ux/critique/<slug>.md.
Fase 1 — Cargar el target
TYPE=image
Leer la imagen directamente con Read (la procesa visualmente).
TYPE=url
Dos pasos en paralelo:
- WebFetch del HTML — obtener estructura y contenido textual.
- Screenshot con playwright MCP:
playwright/browser_navigate <URL>
playwright/browser_resize 1280 800
playwright/browser_take_screenshot — guardar como ./tmp-ux-critique-desktop.png
playwright/browser_resize 375 800
playwright/browser_take_screenshot — guardar como ./tmp-ux-critique-mobile.png
playwright/browser_close
Si playwright no esta disponible, avisar al usuario que se trabaja solo con HTML (sin vision).
TYPE=html
El HTML viene en los argumentos del skill o como paste. Renderizarlo mentalmente; si tiene componentes complejos, recomendar guardarlo a archivo y correr con TYPE=url file:///....
Fase 2 — Evaluar por 7 dimensiones
Para cada dimension, generar hallazgos. Cada hallazgo tiene:
- Severidad:
urgente | importante | menor | nit
- Donde: ubicacion en la pantalla (header, formulario, boton principal, etc.)
- Problema: que esta mal en 1-2 lineas
- Fix: accion concreta sugerida
1. Claridad (Nielsen #2, #6)
- El proposito de la pantalla es obvio en 5 segundos?
- Labels y CTAs usan lenguaje del usuario, no de la empresa?
- Hay items ambiguos o redundantes?
2. Jerarquia
- El item mas importante se distingue visualmente?
- La grilla / spacing respeta agrupacion logica?
- F-pattern / Z-pattern de lectura coherente con prioridad?
3. Affordance (Nielsen #6)
- Los elementos clickeables se ven clickeables?
- Estados de hover / focus presentes?
- Iconos sin label son interpretables solos?
4. Feedback (Nielsen #1)
- Hay loading states donde se esperan operaciones >300ms?
- Acciones destructivas tienen confirmacion o forma de deshacer?
- Errores se muestran cerca de la causa, no en banner global ambiguo?
5. Prevencion de errores (Nielsen #5)
- Formularios validan in-line, no solo al enviar?
- Acciones irreversibles (borrar, enviar, pagar) tienen friccion proporcional?
- Defaults seguros (ej. "guardar como borrador" vs "publicar")?
6. Accesibilidad (Nielsen #4 + WCAG 2.2 AA)
- Contraste ≥4.5:1 (texto normal), ≥3:1 (texto grande)?
- Focus visible en todos los interactivos?
- Touch target ≥24×24 CSS px (24 minimo, 44-48 recomendado mobile)?
- Heading hierarchy correcta?
- Labels en inputs (formales o
aria-label)?
- Alt text en imagenes con contenido?
7. Percepcion de performance
- Hay skeletons / placeholders donde puede haber loading?
- Imagenes con
loading="lazy" (si se ve en el HTML)?
- Animaciones respetan
prefers-reduced-motion?
Bonus — heuristicas de AI (solo si HAS_AI=true)
Aplicar adicionalmente:
- Transparencia: el usuario sabe que esta interactuando con AI? Sabe que puede y que no puede?
- Control sobre delegacion: puede el usuario corregir, deshacer, ajustar el output?
- Manejo de incertidumbre: outputs probabilisticos se muestran como tal (confianza, "sugerencia", "tal vez")?
- Recuperacion: si el AI se equivoca, hay camino claro de correccion?
Fase 3 — Estructurar reporte
## Critica de UX: <CONTEXT>
**Target**: <descripcion del target — path / URL / HTML>
**Vision usada**: <true (imagen + screenshots) | false (solo HTML)>
**Recall declarado**: ~50-80% — esta critica no es exhaustiva, prioriza hallazgos visibles.
## Resumen
- Total hallazgos: <N>
- Urgentes: <N> | Importantes: <N> | Menores: <N> | Nits: <N>
## Hallazgos por dimension
### 1. Claridad
- [<sev>] **<donde>** — <problema>
- Fix: <accion concreta>
- [<sev>] **** —
Fix:
(igual)
(igual)
(igual)
(igual)
(igual — incluir referencia al criterio especifico ej. "WCAG 1.4.3 Contrast")
(igual)
(igual)
[] :
...
Recall ~50-80% — herramientas automaticas no cubren todo lo que cubre un experto humano.
---
Fase 4 — Confirmar y guardar
Preguntar: Confirmás que guardo el output en .ux/critique/<slug>.md? (si/no, default: si). Si acepta, si la carpeta .ux/critique/ no existe, crearla con mkdir -p .ux/critique/ antes de escribir. Luego crear el archivo con el tool de edicion seguro disponible.
Fase 5 — Reportar
Reportar skill, tipo de target, si se uso vision, total de hallazgos, conteo de urgentes e importantes, file resultante y si se guardo.
Result
skill: /ux-critique
saved: <true | false>
file: .ux/critique/<slug>.md
target_type: <image | url | html>
vision_used: <true | false>
has_ai_features: <true | false>
findings_total: <N>
findings_urgent: <N>
findings_important: <N>
MUST DO
- Cubrir las 7 dimensiones en orden.
- Asignar severidad a cada hallazgo.
- Incluir un "Fix" accionable por hallazgo (no vaguedades).
- Declarar limitaciones de la critica (recall, falta de imagen/HTML).
- Aplicar heuristicas de AI solo si
HAS_AI=true.
- Guardar en
.ux/critique/<slug>.md.
MUST NOT DO
- No prometer recall del 100% — declarar limite ~50-80%.
- No usar TYPE=url sin intentar al menos WebFetch del HTML.
- No omitir el "Top 5 fixes prioritarios".
- No mezclar critica con auditoria de accesibilidad —
/ux-a11y-audit cubre eso en profundidad.
- No usar
gh ni depender de GitHub.
- No persistir nada en auto-memory.
