dependency-update
$
npx mdskill add 686f6c61/alfred-dev/dependency-updateAudit dependencies for CVEs and propose safe updates.
- Detects outdated packages, vulnerabilities, and end-of-life software.
- Integrates with npm, pip, cargo, Dependabot, and Renovate.
- Prioritizes fixes based on severity, impact, and breaking changes.
- Generates actionable reports with specific update recommendations.
SKILL.md
.github/skills/dependency-updateView on GitHub ↗
--- name: dependency-update description: "Revisar dependencias desactualizadas, con CVEs o end-of-life, y proponer actualizaciones seguras. También: actualizar paquetes, actualizar dependencias, Dependabot, Renovate, versión desactualizada, breaking changes." --- # Actualización segura de dependencias ## Resumen Este skill revisa las dependencias del proyecto para detectar versiones desactualizadas, vulnerabilidades conocidas (CVEs) y paquetes en end-of-life. No se trata de actualizar todo ciegamente: cada actualización se evalúa por riesgo, impacto y necesidad antes de proponerla. Las dependencias desactualizadas son una de las principales fuentes de vulnerabilidades. Pero una actualización precipitada puede romper el proyecto. El equilibrio es actualizar lo necesario, cuando es seguro hacerlo. ## Proceso ### Paso 1: inventariar dependencias Según el runtime del proyecto: **Node/npm:** ```bash npm outdated npm audit ``` **Python/pip:** ```bash pip list --outdated pip-audit ``` **Rust/Cargo:** ```bash cargo outdated cargo audit ``` ### Paso 2: clasificar por urgencia | Categoría | Descripción | Acción | |-----------|-------------|--------| | **Crítica** | CVE con severidad alta/crítica en producción | Actualizar inmediatamente | | **Alta** | CVE con severidad media o dependencia en end-of-life | Planificar actualización esta semana | | **Media** | Versión major desactualizada sin CVE conocido | Evaluar breaking changes y planificar | | **Baja** | Versión minor/patch desactualizada sin CVE | Actualizar cuando sea conveniente | ### Paso 3: evaluar cada actualización Para cada dependencia que necesite actualización: - **Breaking changes**: leer el changelog entre la versión actual y la nueva. Hay breaking changes? - **Compatibilidad**: es compatible con el resto del stack? (versión de Node, otras dependencias). - **Tamaño del cambio**: minor/patch suelen ser seguros. Major requiere más cuidado. - **Tests**: hay tests que cubran el uso de esta dependencia? Si no, escribirlos antes de actualizar. ### Paso 4: proponer el plan de actualización Generar un informe con: 1. **Resumen**: número de dependencias desactualizadas por categoría. 2. **Actualizaciones críticas**: lista con CVE, severidad y versión objetivo. 3. **Actualizaciones recomendadas**: lista con razón y riesgo estimado. 4. **Actualizaciones pospuestas**: las que no merece la pena actualizar ahora y por qué. ### Paso 5: ejecutar las actualizaciones Si el usuario aprueba: - Actualizar una dependencia a la vez (no todas de golpe). - Ejecutar los tests después de cada actualización. - Si los tests fallan, investigar y corregir antes de continuar. - Commitear cada actualización por separado para facilitar rollback. ## Qué NO hacer - No actualizar todas las dependencias de golpe. Si algo se rompe, no sabrás qué lo causó. - No ignorar las dependencias de desarrollo. Pueden inyectar código en el build. - No forzar actualizaciones a major version sin evaluar breaking changes. - No descartar CVEs por ser de severidad baja: el contexto del proyecto puede elevar su impacto. ## Clarificación Este skill ejecuta actualizaciones concretas. Para auditar el estado de las dependencias primero, usar `dependency-audit`.
More from 686f6c61/alfred-dev
- acceptance-criteriaGenerar criterios de aceptación en formato Given/When/Then. Activar cuando el usuario quiera definir criterios de aceptacion, usar formato Given When Then, escribir en Gherkin, saber como determinar que algo esta terminado o establecer una definicion de hecho.
- architecture-docsUsar para documentar la arquitectura del sistema. Activar ante: documentar arquitectura, diagrama del sistema, como funciona el proyecto, vision general tecnica
- bundle-sizeAnalizar y reducir el tamaño de bundles frontend. Activar cuando el bundle sea grande, se quiera reducir tamaño, aplicar tree shaking, configurar lazy loading, usar webpack analyzer o analizar el peso de la aplicacion.
- choose-stackUsar para evaluar y elegir tecnologías con matriz de decisión ponderada. Activar cuando el usuario quiera elegir tecnología, comparar frameworks, decidir entre alternativas técnicas, construir una matriz de decisión, evaluar stack, seleccionar base de datos, elegir lenguaje o comparar herramientas.
- ci-cd-pipelineConfigurar pipeline CI/CD adaptado al proyecto. Activar cuando el usuario quiera configurar CI, crear GitHub Actions, configurar GitLab CI, montar un pipeline de despliegue, automatizar tests o implementar integracion continua.
- code-review-responseUsar al recibir feedback de code review para responder técnicamente. Activar cuando el usuario quiera responder a comentarios de PR, gestionar feedback de code review, resolver comentarios de un revisor, o cuando el revisor pide cambios en el código.
- compliance-checkUsar para verificar cumplimiento RGPD, NIS2 y CRA. También: verificar RGPD, cumplimiento normativo, NIS2, CRA, Cyber Resilience Act, protección de datos, regulación europea.
- copy-reviewRevisar textos publicos: claridad, tono, ortografia y CTAs. Activar ante: revisar textos, mejorar copy, tono de comunicacion, textos de la web, landing page copy
- dependency-strategyEstrategia integral de gestion de dependencias: inventario, evaluacion de riesgo, politica de actualizaciones y documentacion. Usar para auditar el estado global de las dependencias del proyecto.
- deploy-configConfigurar despliegue según hosting. Activar cuando el usuario quiera desplegar en Vercel, Railway, AWS, configurar hosting, preparar para produccion o gestionar variables de entorno de despliegue.