From alfred-dev
Evaluates dependencies before npm/pip install: assesses bundle size, tree-shaking, maintenance, vulnerabilities, docs, alternatives, and recommends add, reject, or implement internally.
npx claudepluginhub 686f6c61/alfred-dev --plugin alfred-devThis skill uses the workspace's default tool permissions.
Este skill analiza una dependencia externa antes de añadirla al proyecto. Cada dependencia es código de terceros que se incorpora a la cadena de suministro del software, con sus implicaciones de seguridad, mantenimiento y tamaño. La pregunta no es solo "resuelve mi problema" sino "el coste de adoptarla es menor que el coste de implementarla internamente".
Evaluates packages, manages dependencies, and addresses supply chain security for npm/pip/cargo/bundler/Go. Use for auditing packages, reviewing lockfiles, checking vulnerabilities, comparing alternatives, assessing trustworthiness.
Audits project dependencies from package.json, requirements.txt, go.mod, Gemfile for CVEs, outdated packages, transitive issues, licenses, and supply chain risks. Provides severity assessments, remediation suggestions, and prioritized reports.
Audits project dependencies for CVEs, outdated versions, incompatible licenses, and abandoned packages using npm audit, pip-audit, cargo audit, govulncheck, composer audit. Blocks releases on critical/high vulns.
Share bugs, ideas, or general feedback.
Este skill analiza una dependencia externa antes de añadirla al proyecto. Cada dependencia es código de terceros que se incorpora a la cadena de suministro del software, con sus implicaciones de seguridad, mantenimiento y tamaño. La pregunta no es solo "resuelve mi problema" sino "el coste de adoptarla es menor que el coste de implementarla internamente".
El resultado es una recomendación fundamentada: añadir la dependencia, rechazarla o implementar la funcionalidad internamente.
Identificar la necesidad concreta. Qué problema resuelve la dependencia. Cuánto código propio ahorra. Si es una utilidad puntual o una pieza central de la arquitectura.
Evaluar los criterios técnicos:
| Criterio | Qué verificar |
|---|---|
| Tamaño del bundle | Peso en KB/MB. Impacto en tiempos de carga si es frontend. Usar herramientas como bundlephobia para npm. |
| Tree-shaking | Se puede importar solo lo necesario o es todo-o-nada. |
| Mantenimiento activo | Fecha del último commit, frecuencia de releases, número de mantenedores. Un solo mantenedor es un riesgo. |
| Issues y PRs | Ratio de issues abiertas vs cerradas. PRs pendientes sin revisar durante meses. |
| Vulnerabilidades | Historial de CVEs. Comprobar en bases de datos de vulnerabilidades (Snyk, GitHub Advisory). |
| Licencia | Compatible con la licencia del proyecto. MIT y Apache 2.0 suelen ser seguras. GPL puede ser problemática en proyectos propietarios. |
| Dependencias transitivas | Cuántas dependencias arrastra consigo. Cada una es un vector de riesgo adicional. |
| Documentación | Calidad de la documentación y ejemplos. Una librería mal documentada genera deuda técnica. |
| Tests | Cobertura de tests del proyecto. Un proyecto sin tests es un riesgo. |
Buscar alternativas más ligeras. Antes de adoptar una dependencia pesada, verificar si existe una alternativa más pequeña que cubra el caso de uso específico. Por ejemplo: date-fns en vez de moment, got en vez de axios si solo se necesita HTTP básico.
Evaluar la opción de implementación interna. Si la funcionalidad necesaria es pequeña (menos de 50 líneas de código), puede merecer la pena implementarla internamente en vez de añadir una dependencia. Sopesar el coste de mantenimiento propio frente al riesgo de dependencia externa.
Emitir la recomendación. Una de tres opciones:
Documentar la decisión. Dejar constancia del análisis para que futuras evaluaciones no repitan el trabajo.
Este skill evalúa una dependencia concreta antes de añadirla. Para auditar las dependencias existentes del proyecto, usar dependency-audit.