audit

Visión general de audit skill

Qué hace audit skill

La audit skill ejecuta una UX Audit técnica sobre trabajo frontend ya implementado y convierte los hallazgos en un informe estructurado. Revisa calidad medible en accesibilidad, rendimiento, theming, comportamiento responsive y anti-patterns de implementación; después puntúa cada área y clasifica los problemas por severidad de P0 a P3.

Quién debería instalar audit

Esta audit skill encaja especialmente bien para frontend engineers, design engineers, UX engineers y agentes de IA que revisan una página, un componente o una funcionalidad antes del lanzamiento. Resulta especialmente útil cuando necesitas una auditoría repetible en lugar de un prompt vago del tipo “revisa esta UI”.

El trabajo real que resuelve

La mayoría de usuarios no necesitan feedback general. Necesitan una auditoría que:

• se centre en problemas respaldados por el código
• separe los defectos críticos de los detalles de acabado
• evite ponerse a corregir cosas antes de tiempo
• deje un informe listo para handoff y para trabajo de implementación posterior

Ese es el valor central aquí: una revisión de calidad técnica que puedes ejecutar antes de pedirle a otra skill o agente que haga cambios.

Qué diferencia a esta audit de un prompt genérico

La principal diferencia es la disciplina de alcance. La skill trata explícitamente la auditoría como una revisión técnica, no como una crítica de gusto visual. Pide un análisis diagnóstico en cinco dimensiones, usa un modelo de puntuación consistente y espera un informe basado en severidad con plan de acción. Eso hace que los resultados sean más fáciles de comparar entre páginas y más fáciles de convertir en tareas posteriores.

Advertencia clave antes de adoptarla

Esta skill depende de contexto previo. Sus propias instrucciones exigen invocar primero $frontend-design y, si aún falta contexto de diseño, ejecutar $teach-impeccable antes de la auditoría. Si te saltas esa preparación, la calidad de la salida bajará porque la auditoría se apoya en principios de diseño compartidos y en reglas de recopilación de contexto.

Cómo usar audit skill

Instalación de audit y contexto de configuración

Instala la audit skill desde el repositorio pbakaus/impeccable en tu entorno de skills:

npx skills add pbakaus/impeccable --skill audit

Como esta skill vive en .codex/skills/audit, la decisión práctica de instalarla tiene menos que ver con dependencias y más con encaje en tu flujo de trabajo. Debes contar con usarla dentro de un entorno que admita invocación de skills y skills relacionadas del mismo repositorio.

Lee primero este archivo

Empieza por:

• SKILL.md

Ese archivo contiene casi todo el comportamiento importante: prerrequisitos, alcance de la auditoría, puntuación y estilo de informe esperado. No hay scripts auxiliares ni archivos de referencia visibles en esta carpeta de la skill, así que la mayor parte de la guía de uso está en el documento principal de la skill.

Prerrequisito obligatorio antes de ejecutar audit

No llames a audit en frío. La skill indica que primero hay que invocar $frontend-design porque ahí están los principios de diseño, los anti-patterns y el protocolo de recopilación de contexto que utiliza esta auditoría. Si todavía no existe contexto de diseño, ejecuta $teach-impeccable antes de audit.

En la práctica, la secuencia es:

1. recopilar el contexto de diseño y producto
2. establecer qué página o componente se va a revisar
3. ejecutar audit
4. usar el informe para impulsar correcciones con otra tarea o skill

Qué entrada necesita audit skill

La audit skill funciona mejor cuando le das un objetivo concreto junto con contexto de revisión. Las buenas entradas suelen incluir:

• la página, ruta, componente o flujo exactos
• la ubicación del código o los archivos implicados
• los dispositivos objetivo
• detalles del framework o stack, si son relevantes
• restricciones conocidas como CSS legacy, límites del design system o presupuestos de rendimiento
• si la revisión es previa al lanzamiento, centrada en regresiones o exploratoria

Una solicitud débil sería “audita mi app”. Una solicitud sólida sería “run an audit for the checkout page on mobile and desktop, focusing on accessibility, loading behavior, and responsive breakpoints.”

Convierte un objetivo difuso en un prompt de auditoría útil

Un buen prompt de uso de audit debe nombrar el objetivo, delimitar el alcance y pedir salida estructurada. Por ejemplo:

• “Run the audit skill on the pricing page. Review accessibility, performance, theming consistency, responsive behavior, and implementation anti-patterns. Score each dimension 0-4, list P0-P3 issues, and end with an action plan. Do not fix anything yet.”
• “Use audit for the settings modal component. Check keyboard support, semantic structure, focus handling, contrast, theme token usage, and mobile layout failure points.”

Esto funciona mejor que un prompt genérico de revisión porque encaja con el modelo de reporte de la skill.

Qué comprueba realmente la audit

Según las instrucciones de la skill, la auditoría cubre cinco dimensiones:

• accessibility
• performance
• theming
• responsive design
• anti-patterns

La sección de accessibility es la más explícita en el contenido fuente e incluye contraste, ARIA, navegación por teclado, HTML semántico, texto alternativo y problemas de formularios. Eso te indica que la skill está orientada a la implementación y probablemente genere defectos concretos en lugar de consejos abstractos.

Formato de salida esperado y por qué importa

El valor de esta audit skill no está solo en la checklist. También está en la forma de la salida:

• revisión por dimensiones
• puntuación 0-4 por dimensión
• etiquetas de severidad P0-P3
• plan accionable

Esa estructura ayuda al triaje. Los equipos pueden separar blockers de lanzamiento de mejoras para backlog sin tener que releer todo el informe.

Mejor flujo de trabajo para usar audit

Un flujo práctico sería así:

1. preparar el contexto de diseño con las skills prerrequisito
2. elegir una sola página, funcionalidad o componente
3. aportar alcance de implementación y restricciones
4. ejecutar la audit skill
5. revisar puntuaciones y severidades
6. convertir el plan de acción en tickets o en un prompt posterior de corrección

Esta skill es más efectiva cuando se ejecuta sobre superficies acotadas. Si intentas auditar un producto entero en una sola pasada, los hallazgos se vuelven más superficiales y la priorización empeora.

Cuándo usar audit para trabajo de UX Audit

Usa audit for UX Audit cuando necesites evidencia de implementación para detectar problemas de calidad UX. Tiene muy buen encaje para:

• revisiones de preparación para lanzamiento
• comprobaciones de regresión después de un rediseño
• comparar calidad técnica entre distintas páginas
• identificar defectos de accesibilidad y responsive antes de test con usuarios
• generar una lista de defectos para que otro agente la corrija

Encaja peor en preguntas puramente de research, como arquitectura de información, claridad del mensaje o exploración visual de marca.

Límites y casos en los que no encaja

No es una skill de crítica de diseño ni una skill de corrección. Documenta problemas en lugar de resolverlos. Si tu objetivo real es “hacer que esta página se vea mejor”, instálala solo si además quieres un inventario técnico de defectos. Si tu objetivo es “reescribir el componente ahora”, este paso de auditoría puede ser innecesario salvo que el riesgo de calidad sea alto.

Preguntas frecuentes sobre audit skill

¿Esta audit skill es apta para principiantes?

Sí, siempre que ya sepas qué superficie quieres revisar. La skill ofrece un marco de auditoría claro, pero quien empieza puede pasar por alto el paso de contexto previo. Si ignoras $frontend-design y $teach-impeccable cuando hacen falta, la auditoría puede volverse genérica o inconsistente.

¿Necesito todo el repositorio impeccable?

Para esta skill, la dependencia principal es conceptual más que basada en muchos archivos. La carpeta visible de audit solo expone SKILL.md, pero las instrucciones dependen de forma explícita de otras skills del mismo repositorio. Por eso, probablemente te convenga acceso al repositorio completo, no solo a este archivo aislado.

¿En qué mejora audit frente a pedirle a una IA que revise mi UI?

Un prompt normal suele mezclar gusto subjetivo de diseño con defectos técnicos. Esta audit skill impone un alcance más estrecho, dimensiones consistentes y salida puntuada. Eso normalmente produce mejor triaje, mejor comparabilidad entre auditorías y menos tiempo perdido discutiendo comentarios vagos.

¿Puede audit corregir problemas automáticamente?

No. La skill está diseñada para diagnosticar y reportar. Eso es una ventaja, no una limitación, si quieres un handoff limpio entre revisión e implementación. Usa el informe para impulsar una tarea de corrección separada.

¿Qué debería auditar primero?

Empieza por una superficie de alto impacto:

• hero y navegación de la homepage
• flujo de signup o checkout
• pantalla de entrada al dashboard
• componentes compartidos como modals, forms y tables

Estas áreas suelen exponer rápido problemas de accesibilidad, responsive y rendimiento, así que hacen más útil la primera auditoría.

¿Cuándo no debería usar esta audit skill?

Omite esta auditoría si:

• solo quieres ideas subjetivas de diseño
• no tienes una implementación concreta que inspeccionar
• necesitas research de producto completo en lugar de revisión técnica
• vas a lanzar un prototipo rápido y no necesitas informes con puntuación

Cómo mejorar audit skill

Dale a la audit un objetivo más acotado

La forma más rápida de mejorar la salida de audit es reducir el alcance. Pide una sola ruta, un único flujo o una familia de componentes. “Audit the account deletion flow” producirá hallazgos más sólidos que “audit the whole app.”

Aporta el contexto que la skill espera

Como esta audit depende de contexto de diseño frontend, proporciónale desde el principio la información de fondo que falte:

• objetivo del usuario en esa pantalla
• modelo de interacción esperado
• prioridades por dispositivo
• reglas de theme o design system
• restricciones de negocio

Esto reduce falsos positivos y ayuda a que la auditoría juzgue los anti-patterns según la intención real.

Pide solo hallazgos respaldados por evidencia

Si quieres una guía de audit más sólida en la práctica, pide explícitamente evidencia observable. Por ejemplo, solicita que el agente cite el elemento, patrón, estado o comportamiento detrás de cada hallazgo. Eso mantiene el informe más pegado a la realidad de implementación y hace más fácil verificarlo.

Mejora la calidad de la severidad con contexto de lanzamiento

Las etiquetas de severidad funcionan mejor cuando defines el impacto. Indica a la auditoría si el objetivo es:

• public marketing page
• authenticated product UI
• checkout or conversion flow
• internal tool
• mobile-first experience

Un keyboard trap en checkout debería clasificarse de forma distinta a una inconsistencia cosmética de espaciado en una pantalla de administración.

Fallos habituales al usar audit

Los problemas más comunes son:

• saltarse las skills prerrequisito obligatorias
• auditar demasiada superficie a la vez
• pedir correcciones en vez de diagnóstico
• no dar contexto de dispositivo o viewport
• tratar preferencias subjetivas de diseño como si fueran defectos técnicos

Estos problemas suelen derivar en informes con más ruido, peor priorización o alcance mezclado.

Entradas más sólidas que mejoran la calidad de salida

Los mejores prompts incluyen detalles como:

• “focus on keyboard navigation and forms”
• “treat mobile Safari as a priority”
• “check theme token consistency in dark mode”
• “flag only measurable anti-patterns”
• “score each dimension and end with top 5 fixes by impact”

Estos detalles mejoran la auditoría porque orientan dónde hace más falta profundidad.

Cómo iterar después de la primera audit

Después de la primera pasada, no vuelvas a ejecutar exactamente el mismo prompt amplio. En su lugar:

1. corrige o selecciona los problemas de mayor severidad
2. vuelve a ejecutar audit sobre la misma superficie acotada
3. pide comprobaciones más profundas en la dimensión con peor puntuación
4. compara los cambios de puntuación y los hallazgos P0-P1 que sigan sin resolverse

Así conviertes la audit skill en una puerta de control de calidad repetible, no en un informe puntual.

Combina audit con trabajo posterior de implementación

La audit skill es más potente cuando se usa como fase de diagnóstico dentro de un flujo de dos pasos. Primero, genera el informe. Después, usa ese informe como entrada estructurada para una pasada separada de implementación. Esto preserva la objetividad de la auditoría y evita que “revisar mientras editas” oculte defectos importantes.