القائمة
Usar para verificar que cambios nuevos no rompen funcionalidad existente. También: algo se ha roto, cambio rompe funcionalidad, verificar que no hay regresión, tests de regresión.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Alias global /alfred para abrir el asistente contextual de Alfred Dev sin escribir el namespace completo. Activar solo cuando el usuario invoque explicitamente /alfred.
Protocolo de respuesta ante incidentes en produccion: triaje, mitigacion, causa raiz y postmortem. Usar ante caidas, errores criticos, incidentes de seguridad o degradacion de servicio.
Usar para refactorizar código con tests como red de seguridad. Activar cuando el usuario quiera limpiar código, reducir complejidad, extraer función, mejorar nombres, eliminar duplicación, resolver un code smell o reorganizar la estructura interna sin cambiar comportamiento.
Generar Dockerfile optimizado. Activar cuando el usuario quiera crear contenedor, generar imagen Docker, configurar Docker Compose, contenerizar aplicacion o crear un Dockerfile multi-stage.
Planificar y ejecutar releases: inventario de cambios, versionado semantico, changelog, notas de release y publicacion. Usar antes de cada version nueva.
Auditar accesibilidad WCAG 2.1 nivel AA con checklist y correcciones. Activar ante: accesibilidad web, WCAG, lector de pantalla, contraste, navegacion por teclado, a11y
| name | regression-check |
| description | Usar para verificar que cambios nuevos no rompen funcionalidad existente. También: algo se ha roto, cambio rompe funcionalidad, verificar que no hay regresión, tests de regresión. |
Este skill verifica que los cambios recientes no han roto funcionalidad que antes funcionaba correctamente. Las regresiones son uno de los tipos de bug más frustrantes: algo que el usuario daba por hecho deja de funcionar sin razón aparente. Este proceso las detecta antes de que lleguen a producción.
El enfoque es sistemático: se analiza el impacto del cambio, se ejecutan los tests relevantes y se verifica la integración con el resto del sistema.
Analizar el alcance del cambio. Entender qué se ha modificado:
Mapear las áreas de impacto potencial. Un cambio en un módulo base puede afectar a todo lo que depende de él. Trazar el árbol de dependencias hacia arriba:
Módulo cambiado --> Módulos que lo importan --> Módulos que importan a esos
Cuanto más profundo en el árbol, mayor es el área de impacto.
Ejecutar los tests del área afectada. En orden:
Si hay tests que fallan, analizar la causa:
Identificar lagunas de testing. Si hay áreas afectadas por el cambio que no tienen tests:
Verificar integración. Más allá de los tests automatizados, verificar manualmente o con tests exploratorios que los flujos principales siguen funcionando. Prestar especial atención a:
Documentar el resultado. Registrar: qué se verificó, qué pasó, qué quedó sin verificar y por qué.