| name | ux-copy-review |
| description | Revisa microcopy, labels, errores, empty states y tono en HTML, imagen o paste; propone reescrituras y guarda en .ux/copy/<slug>.md. |
Review de microcopy y claridad linguistica: button labels, mensajes de error, empty states, helper text, consistencia de tono. Audita HTML, imagen, o paste directo. Devuelve hallazgos + reescrituras sugeridas. Los argumentos del skill son el target y pueden venir vacios.
Skill interactivo.
Pre-flight
1. Detectar tipo de target
Mismo flujo que /ux-critique / /ux-a11y-audit:
- Path HTML o directorio
- Path imagen (vision-only)
- URL (WebFetch + screenshot)
- Paste directo de copy (lista de strings)
2. Preguntar contexto
Que pantalla / producto es? (1 linea — afecta el tono esperado)
Guardar CONTEXT.
3. Preguntar tono target
Tono deseado:
1) Sobrio / profesional (para empresas)
2) Amigable / cercano (consumidor final, productividad)
3) Tecnico / preciso (devtools, infraestructura)
4) Juguetón / informal (consumidor final, comunidad)
5) Otra
Guardar TONE.
4. Preguntar idioma
Idioma del copy a revisar:
1) Español (default)
2) Ingles
3) Mixto (auditar consistencia idiomatica como hallazgo aparte)
Guardar LANG.
5. Derivar slug
Derivar <slug> desde CONTEXT (kebab-case, max 40 chars). Se usa para guardar en .ux/copy/<slug>.md.
Fase 1 — Extraer strings del target
Segun tipo:
- HTML: parsear y extraer texto de
<button>, <a>, <label>, <input placeholder>, <h*>, <p> en areas interactivas, aria-label, title, mensajes de error inline, empty states (texto en areas vacias).
- Imagen: leer los textos visibles. Listarlos en orden de jerarquia visual.
- Paste: el usuario ya proveyo las strings.
Mostrar al usuario:
Encontre <N> strings a revisar. Procedo con la auditoria? (si/no)
Fase 2 — Auditar cada string
Para cada string, evaluar:
Claridad
- El significado es inmediato (5 segundos)?
- Tiene jerga interna o tecnicismos innecesarios?
- Ambiguedad (puede interpretarse de 2 maneras)?
- Negacion doble o lenguaje pasivo cuando activo sirve mejor?
Brevedad
- Numero de palabras razonable para el tipo de string (button label: 1-3, error: 1 oracion, empty state: 1-2 oraciones, tooltip: 1 frase)?
- Hay palabras decorativas removibles ("simplemente", "facilmente", "por favor" en exceso)?
Consistencia de tono
- Encaja con
TONE declarado?
- Hay strings que rompen el tono (ej. tono sobrio con un "¡Ups!" jocoso)?
Orientacion a la accion (especialmente botones principales / CTAs)
- Verbos en imperativo + objeto claro? (ej. "Crear cuenta" > "Cuenta nueva")
- Evitar "OK" / "Submit" / "Continue" cuando hay verbo especifico (mejor "Crear cuenta", "Guardar cambios").
Mensajes de error especificamente
- Le dice al usuario QUE fallo (no solo "Error")?
- Le dice CÓMO arreglarlo?
- No culpa al usuario ("Has hecho X mal" → "Esto necesita Y").
- No expone detalles internos (stack traces, codigos crudos).
Empty states especificamente
- Explica POR QUE esta vacio?
- Sugiere COMO llenarlo (boton principal explicito)?
- Tiene tono apropiado (no jocoso si el tono es sobrio).
Accesibilidad / labels
aria-label redundante con texto visible? (debe coincidir o el visible debe estar incluido en el label).- Placeholders usados como label (anti-pattern)?
Fase 3 — Generar reescrituras
Por cada string con hallazgos, proponer 1-3 reescrituras alternativas. No solo 1 — dar opciones al usuario para elegir.
Ej:
Original: "Submit"
Hallazgos: [menor] generico, no dice que hace, viola orientacion a la accion
Reescrituras:
a) "Crear cuenta"
b) "Continuar al checkout"
c) "Enviar mensaje"
Fase 4 — Estructurar reporte
## Copy review: <CONTEXT>
**Target**: <descripcion>
**Tono deseado**: <TONE>
**Idioma**: <LANG>
**Strings auditados**: <N>
## Resumen
| Categoria | Count |
|-----------|-------|
| Problemas de claridad | <N> |
| Problemas de brevedad | <N> |
| Quiebres de tono | <N> |
| Orientacion a la accion | <N> |
| Problemas en mensajes de error | <N> |
| Problemas en empty states | <N> |
| Problemas de labels accesibles | <N> |
| Strings ok | <N> |
## Hallazgos por string
### "<string original>"
- **Donde**: <ubicacion>
- **Hallazgos**:
- [<sev>]
[]
:
a) ""
b) ""
c) "" (opcional)
:
(repetir por cada string con hallazgos)
""
""
...
---
Fase 5 — Confirmar y guardar
Preguntar: Confirmás que guardo el output en .ux/copy/<slug>.md? (si/no, default: si). Si acepta, si la carpeta .ux/copy/ no existe, crearla con mkdir -p .ux/copy/ antes de escribir. Luego crear el archivo con el tool de edicion seguro disponible.
Fase 6 — Reportar
Reportar skill, tipo de target, tono, idioma, strings auditados, total de hallazgos, strings con reescrituras, file resultante y si se guardo.
Result
skill: /ux-copy-review
saved: <true | false>
file: .ux/copy/<slug>.md
target_type: <html | image | url | paste>
tone: <TONE>
lang: <LANG>
strings_audited: <N>
findings_total: <N>
strings_with_rewrites: <N>
MUST DO
- Extraer strings del target antes de auditar.
- Proponer 1-3 reescrituras por string con hallazgos (no 1 sola).
- Marcar patrones detectados (problemas repetidos entre strings).
- Validar consistencia de tono en el conjunto.
- Para errores y empty states: aplicar checks especificos.
- Guardar en
.ux/copy/<slug>.md.
MUST NOT DO
- No reescribir strings que no tienen problemas (no introducir cambios cosmeticos).
- No proponer reescrituras que rompan el
TONE declarado.
- No omitir strings ok (mostrarlos como confirmacion).
- No mezclar copy review con
/ux-critique — el copy review es enfoque linguistico, mas profundo.
- No usar
gh ni depender de GitHub.
- No persistir nada en auto-memory.
