القائمة
Usar para generar un plan de testing priorizado por riesgo. También: plan de testing, qué probar, priorizar tests por riesgo, estrategia de testing, cobertura de tests.
التثبيت باستخدام 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 | test-plan |
| description | Usar para generar un plan de testing priorizado por riesgo. También: plan de testing, qué probar, priorizar tests por riesgo, estrategia de testing, cobertura de tests. |
Este skill produce un plan de testing estructurado y priorizado por riesgo. No se trata de probar todo con la misma intensidad, sino de concentrar el esfuerzo donde más impacto tiene: las áreas críticas del sistema que, si fallan, causan mayor daño al usuario o al negocio.
El plan cubre desde tests unitarios hasta tests end-to-end, pasando por integración, edge cases y escenarios negativos. El resultado es un documento accionable que guía el esfuerzo de testing.
Identificar el alcance. Definir qué se va a probar: una feature nueva, un módulo refactorizado, el sistema completo, o un área específica. El alcance determina la profundidad del plan.
Analizar el riesgo de cada área. Para cada componente o funcionalidad, evaluar:
Clasificar cada área como crítica, alta, media o baja prioridad de testing.
Definir las categorías de tests:
Asignar prioridad a cada test:
| Prioridad | Criterio | Ejemplo |
|---|---|---|
| Crítica | Fallo = pérdida de datos o dinero | Test de transacciones, test de backup |
| Alta | Fallo = servicio no disponible | Test de autenticación, test de endpoints principales |
| Media | Fallo = mala experiencia de usuario | Test de validación de formularios, test de paginación |
| Baja | Fallo = molestia menor | Test de formato de fecha, test de ordenación |
Estimar el esfuerzo. Para cada grupo de tests, estimar el tiempo necesario para escribirlos. Esto ayuda a planificar sprints y a negociar alcance si hay restricciones de tiempo.
Documentar el plan. Utilizar templates/test-plan.md si existe. El documento debe ser una referencia viva que se actualiza conforme el proyecto evoluciona.
Registrar las decisiones de estrategia de testing en la memoria del proyecto con memory_log_decision. Esto incluye qué áreas se han priorizado, qué se ha descartado y por qué, para que el plan se mantenga coherente entre sesiones.
Consultar el stack detectado en la configuración de Alfred para seleccionar automáticamente el framework de testing adecuado (Jest, Vitest, pytest, etc.) y adaptar las recomendaciones al ecosistema del proyecto.
