senior-frontend: la skill que obliga a Claude Code a probar tu interfaz antes de decir «listo»

senior-frontend es una skill gratuita (MIT) para Claude Code que cambia cómo el agente construye interfaces: antes de escribir lee tus componentes y tus tokens, hace la lista de estados (cargando, vacío, error, contenido largo), usa HTML semántico y accesible, diseña a 375 px y, sobre todo, abre la página en un navegador real antes de decir que está terminada. Viene en el catálogo aitmpl.com del proyecto claude-code-templates y lleva más de 31.000 descargas (si no lo conoces, mira cómo elegir agentes de aitmpl sin instalar uno peligroso).

La pusimos a prueba con el mismo prompt dos veces, con y sin la skill, en una página de "miembros del equipo" con búsqueda y botón de quitar. Con la skill el resultado salió más accesible y más usable en el móvil por 0,06 USD y 16 segundos más. También encontramos un fallo de foco que tenían las dos versiones y que ni la skill ni su verificador detectaron, y te contamos cómo cazarlo.

Qué es la skill senior-frontend y de dónde sale

Una skill es una carpeta con un SKILL.md que Claude Code carga cuando la tarea encaja con su descripción. Si nunca has instalado una, empieza por qué son las skills de Claude Code y cómo instalarlas.

senior-frontend vive en el repositorio davila7/claude-code-templates, la colección de agentes, comandos y skills que alimenta aitmpl.com. Lo que analizamos:

• Versión 2.0.0, una reescritura completa de la skill original (commit 30f72e1 de main, 11 de noviembre de 2026).
• Licencia MIT (Copyright (c) 2025 Daniel Ávila). El SKILL.md también declara license: MIT.
• 6 archivos, 686 líneas: el SKILL.md (181 líneas), dos referencias, un aviso de licencias y dos scripts de Node.
• Fuentes declaradas en references/NOTICE.md: las Web Interface Guidelines y las agent-skills de Vercel, y las web-quality-skills de Addy Osmani, todas MIT. Es una de las pocas skills del catálogo que cita con commit exacto de dónde saca cada regla.

Su descripción está escrita para activarse a menudo: "You MUST use this whenever you build, change or review user interface code, including small UI tweaks and when the user is in a hurry". Es decir, se carga también para cambios pequeños, que es justo cuando más se olvidan los estados de error.

Qué trae: los 7 pasos y el verificador

El SKILL.md es un procedimiento de siete pasos con una regla central: la interfaz no está terminada hasta que la ves funcionar en un navegador, incluidos los caminos de error. Un typecheck que pasa no dice si el botón se alcanza con Tab o si un nombre largo rompe el diseño en el móvil.

1. Leer el proyecto antes de escribir. Stack y versiones (React 18 y 19 cambian forwardRef, use y las actions), componentes existentes, tokens de diseño, capa de datos y scripts. Pide permiso antes de añadir dependencias.
2. Listar los estados. Una tabla con lo que el usuario debe ver en carga, vacío, error, éxito, acción pendiente, contenido largo y fallo parcial.
3. La plataforma primero. <button> para acciones, <a> para navegar, <label> en cada campo, aria-live para resultados asíncronos, foco visible y confirmación o deshacer en todo borrado.
4. Estado aburrido. Derivar en lugar de sincronizar, efectos solo para hablar con el exterior, nada de componentes definidos dentro de otros y nada de optimizar sin medir.
5. Diseño que aguanta contenido real. Primero a 375 px, sin scroll horizontal, min-width: 0 en hijos flex con texto, objetivos táctiles de al menos 24 px (44 px en acciones principales) y respeto a prefers-reduced-motion.
6. Verificar. typecheck, lint, test y build, y después el verificador incluido contra tu servidor de desarrollo.
7. Informar. Qué construyó, qué estados cubrió, qué verificó y qué no pudo verificar.

Cierra con una lista de "red flags": un <button> nuevo en un proyecto que ya tiene Button, errores que solo llegan a console.error, un <div> con onClick, un useEffect que copia props en estado o un borrado sin confirmación.

El verificador check_ui.mjs

scripts/check_ui.mjs abre la página en Chromium con Playwright a 375 y 1280 px y devuelve un JSON con:

• captura de pantalla completa por cada ancho;
• errores de consola y scroll horizontal (con los elementos que se salen);
• botones y enlaces sin nombre accesible, o varios con el mismo nombre ("Delete" repetido doce veces);
• campos sin <label>, imágenes sin alt o sin width/height, y elementos con cursor de mano que no son botones;
• un recorrido con Tab que lista cada parada y si muestra foco visible;
• las violaciones WCAG 2.2 AA de axe-core, si lo tienes instalado en el proyecto.

node .claude/skills/senior-frontend/scripts/check_ui.mjs "http://localhost:5173/" --out .ui-check

Leímos los dos scripts completos antes de ejecutarlos: solo escriben dentro de la carpeta --out, no hacen peticiones salvo a la URL que les pasas y no instalan nada. Si no encuentran Playwright, salen con código 2 y lo dicen.

Instalar senior-frontend en Claude Code

Desde la raíz de tu proyecto, con el instalador del catálogo (versión 1.33.1 de claude-code-templates en el momento de escribir):

npx claude-code-templates@latest --skill development/senior-frontend

Copia la carpeta en .claude/skills/senior-frontend/. Si prefieres no ejecutar un paquete de npm, copia a mano la carpeta del repositorio: son seis archivos de texto. Antes de instalar cualquier skill de un catálogo, pásale SkillSpector para escanearla; la ficha de aitmpl.com dice que su análisis no encontró nada, pero aclara que fue parcial.

Para el verificador necesitas Node 18+ y Playwright en el proyecto (pnpm add -D playwright y pnpm exec playwright install chromium). axe-core es opcional (pnpm add -D axe-core).

La prueba: el mismo prompt con y sin la skill

Preparamos dos carpetas idénticas con un api.js falso: fetchMembers() tarda 600 ms y falla si la URL lleva ?fail=1, y removeMember(id) siempre falla para el miembro 3, que además tiene un nombre y un correo larguísimos. Solo una de las carpetas tenía la skill en .claude/skills/. A las dos les dimos el mismo prompt con Claude Code en modo headless (claude -p, Sonnet 5.5):

Build a "Team members" page in index.html (plain HTML, CSS and JavaScript
modules, no dependencies, no build step). Use fetchMembers() and
removeMember(id) from ./api.js (do not modify api.js). The page shows the list
with name, email and role, a search box to filter by name, and a button on
each row to remove that member. Keep it short.

El prompt no menciona estados de error, accesibilidad ni móvil a propósito: es lo que pide alguien con prisa.

Primera sorpresa: el modelo sin skill ya hizo un trabajo decente. Cubrió carga, vacío y error, puso role="status" y un nombre accesible distinto en cada botón. Los modelos actuales conocen estas reglas; lo que la skill añade es aplicarlas todas cada vez, también en lo que nadie pidió: la confirmación antes de borrar, los objetivos táctiles de 44 px, el foco visible y el anuncio para lectores de pantalla.

Lo que dijo el verificador

Pasamos check_ui.mjs a las dos páginas: 0 avisos en ambas, sin scroll horizontal, sin errores de consola y con foco visible en las seis paradas del recorrido con Tab (el buscador y los cinco botones). En una página tan pequeña el verificador no separa las dos versiones; su valor está en proyectos reales, donde sí aparecen imágenes sin tamaño, div clicables y campos sin etiqueta.

El fallo que nadie vio: el foco perdido

Después probamos lo que el verificador no prueba: quitar a alguien usando solo el teclado. En las dos versiones, al pulsar Enter sobre "Remove Ada Lovelace", el foco acaba en <body>. Quien navega con teclado o lector de pantalla vuelve al principio de la página tras cada borrado.

Lo curioso es que la versión con skill sí escribió código para mover el foco, como pide el paso 3. Pero después de enfocar el siguiente botón, el bloque finally volvía a llamar a render(), que reemplaza toda la lista y con ella el botón enfocado. La skill no lo vio porque en nuestra prueba headless no le dimos permiso para lanzar comandos: intentó arrancar python3 -m http.server y el verificador, se le denegó, y lo dijo sin rodeos en su informe: "Not verified: none of the above has been run. I haven't tried the keyboard flow…". La versión sin skill también avisó de que no la había abierto, pero no listó qué quedaba sin probar.

El arreglo son seis líneas: un solo render() al final y el foco después.

async function remove(m) {
  if (!confirm(`Remove ${m.name} from the team?`)) return;
  rowErrors.delete(m.id); pending.add(m.id); render();
  try {
    await removeMember(m.id);
    members = members.filter((x) => x.id !== m.id);
    status.textContent = `${m.name} removed.`;
  } catch (err) {
    rowErrors.set(m.id, `Could not remove ${m.name}: ${err.message}`);
  }
  pending.delete(m.id);
  render();
  const again = [...list.querySelectorAll("button")]
    .find((b) => b.getAttribute("aria-label") === `Remove ${m.name}`);
  (again || list.querySelector("button") || q).focus();
}

Con el cambio, nuestro script de Playwright confirmó que tras quitar a Ada el foco pasa a "Remove Grace Hopper", y que si el borrado falla se queda en el botón de esa fila. Durante la petición el foco sigue perdiéndose un instante porque la lista se repinta con el botón desactivado; para evitarlo habría que actualizar la fila en lugar de repintar la lista entera.

La lección es la regla central de la propia skill: deja que Claude Code abra el navegador. En una sesión normal te pedirá permiso para arrancar el servidor y ejecutar el verificador; acéptalo, y pídele además el paso 4 del apartado de verificación: forzar el error, buscar algo que no existe, borrar el último elemento y recorrerlo todo con el teclado.

Cuánto cuesta usar senior-frontend

El sobrecoste viene de leer el SKILL.md (unos 9 KB) y de los turnos extra de verificación; la salida fue el doble de tokens (3.908 frente a 1.942). Seis céntimos por componente es poco comparado con una revisión de accesibilidad hecha a mano, y menos que descubrir en producción que un cliente no puede usar tu formulario desde el móvil.

Para gastar lo mínimo: deja la skill instalada en los proyectos con interfaz y usa Sonnet o Haiku para los cambios pequeños. La skill no depende del modelo más caro: sus reglas son concretas y comprobables.

senior-frontend frente a otras skills de frontend

• [impeccable](/blog/impeccable-skill-diseno-web-claude-code) se centra en el aspecto visual: tipografía, color, composición y evitar el diseño genérico de IA. senior-frontend se centra en que funcione: estados, accesibilidad, teclado y móvil. Se complementan.
• [webapp-testing](/blog/probar-web-playwright-claude-code-webapp-testing), de Anthropic, enseña a Claude a escribir y ejecutar pruebas con Playwright. senior-frontend trae un verificador ya hecho y un procedimiento de construcción; webapp-testing sirve para los flujos que el verificador no cubre, como el foco tras un borrado.
• frontend-design, de las skills oficiales de Anthropic, da dirección estética. Igual que impeccable, no verifica nada en el navegador.

Errores frecuentes

Playwright not found. Add it to the project as a dev dependency (and download its Chromium build), or install it globally. El verificador no encuentra Playwright. Instálalo en el proyecto con pnpm add -D playwright y descarga el navegador con pnpm exec playwright install chromium. Sale con código 2.

page.goto: net::ERR_CONNECTION_REFUSED El servidor de desarrollo no está arrancado o está en otro puerto. Ojo: en este caso el script sale con código 0 y el error queda dentro del JSON, en widths.<ancho>.error. Lee el informe; no te fíes solo del código de salida.

axe: "axe-core not installed (optional)" No es un error: solo indica que no hay comprobación WCAG automática. Añade axe-core como dependencia de desarrollo si la quieres.

La skill dice "Not verified" en su informe. No pudo abrir el navegador, normalmente porque denegaste el comando del servidor o el modo de permisos lo bloquea. Ejecuta tú el verificador o vuelve a darle permiso.

Rutas de la skill. El ejemplo del SKILL.md asume .claude/skills/senior-frontend/. Si la instalaste como skill de usuario, la ruta es ~/.claude/skills/senior-frontend/scripts/check_ui.mjs.

Preguntas frecuentes

¿Sirve solo para React?

No. Su descripción cita React, Next.js, Vue, Svelte, Astro y HTML/CSS/Tailwind, y nuestra prueba fue HTML y JavaScript sin framework. La referencia react-patterns.md sí es específica de React.

¿Puedo usar senior-frontend en un proyecto comercial?

Sí. Es MIT: puedes usarla, modificarla y redistribuirla conservando el aviso de copyright y la licencia. Las partes adaptadas de Vercel y Addy Osmani también son MIT y su aviso está en references/NOTICE.md.

¿Hace más lento a Claude Code?

En nuestra prueba, de 17 a 33 segundos y de 3 a 9 turnos. Casi todo el tiempo extra es verificación, que es lo que quieres que haga.

¿Funciona con Codex u otros agentes?

El SKILL.md es Markdown con instrucciones generales, así que cualquier agente que lea skills o instrucciones de proyecto puede seguirlo. El verificador es un script de Node independiente del agente.

¿Sustituye a una auditoría de accesibilidad?

No. Cubre lo que se puede comprobar de forma automática y con el teclado, y deja sin ver cosas como el foco tras un borrado si no las pruebas a propósito. Para un producto público, añade pruebas con lector de pantalla real.

Conclusión

senior-frontend no hace que Claude escriba un HTML más bonito: hace que aplique siempre lo que ya sabe sobre estados, accesibilidad y móvil, y que diga con claridad qué no ha probado. Por seis céntimos por componente compensa tenerla instalada en cualquier proyecto con interfaz. Su regla central es la que importa: déjale abrir el navegador y prueba tú también el teclado, porque ni la skill ni su verificador cazaron el foco perdido hasta que lo probamos a mano.

Siguiente paso: para automatizar justo esas pruebas de teclado y de flujos, mira cómo probar tu web con Playwright y webapp-testing.