¿Qué significa la opción 'Implementar internamente'?

Si la funcionalidad necesaria es pequeña (menos de 50 líneas) puede justificar no añadir una dependencia y mantener el código en casa.

¿Qué criterios deben verificarse con prioridad?

Prioriza seguridad y licencia; revisa vulnerabilidades conocidas y compatibilidad de licencia antes de cualquier decisión.

¿Cómo debe documentarse la decisión?

Deja constancia del análisis, criterios verificados, alternativas consideradas y datos que respalden la recomendación para futuras revisiones.

evaluate-dependencies

Scanned

npx machina-cli add skill 686f6c61/alfred-dev/evaluate-dependencies --openclaw

Files (1)

SKILL.md

3.3 KB

Evaluar dependencias

Resumen

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.

Proceso

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:
- Añadir: la dependencia pasa todos los criterios y aporta valor significativo.
- Rechazar: no pasa criterios críticos (vulnerabilidades, licencia, abandono).
- Implementar internamente: la funcionalidad es suficientemente simple como para no justificar una dependencia.
Documentar la decisión. Dejar constancia del análisis para que futuras evaluaciones no repitan el trabajo.

Criterios de éxito

Se han verificado todos los criterios técnicos de la tabla.
Se han buscado al menos 2 alternativas (incluida la implementación interna).
La licencia es compatible con el proyecto.
No hay vulnerabilidades críticas conocidas sin parche.
La recomendación está justificada con datos, no con opiniones.

Source

git clone https://github.com/686f6c61/alfred-dev/blob/main/skills/arquitectura/evaluate-dependencies/SKILL.mdView on GitHub

Overview

Este skill analiza una dependencia externa antes de añadirla al proyecto. Compara el coste y los riesgos frente a implementación interna para emitir una recomendación fundamentada (añadir, rechazar o implementar internamente).

How This Skill Works

Se evalúan criterios técnicos clave: tamaño del bundle, capacidad de tree-shaking, mantenimiento activo, issues y PRs, vulnerabilidades, licencia, dependencias transitivas, documentación y tests. También se busca alternativas más ligeras y se considera la implementación interna si la funcionalidad es pequeña, para, finalmente, emitir la recomendación y documentar la decisión.

When to Use It

Evaluar una nueva dependencia para resolver un problema concreto y estimar el coste de adoptarla.
Comparar una dependencia existente con una implementación interna o con alternativas más ligeras.
Antes de aceptar dependencias con posibles vulnerabilidades o licencias dudosas.
Cuando el tamaño del bundle o el rendimiento son críticos (frontend).
Al planificar dependencias para una base de código con necesidad de mantenimiento a largo plazo.

Quick Start

Step 1: Identifica la necesidad concreta y cuánto código propio ahorra.
Step 2: Evalúa criterios técnicos clave (tamaño, tree-shaking, mantenimiento, vulnerabilidades, licencia) y busca al menos 2 alternativas.
Step 3: Emite la recomendación (Añadir, Rechazar o Implementar internamente) y documenta la decisión.

Best Practices

Definir criterios mínimos de seguridad, licencia y mantenimiento antes de evaluar.
Verificar vulnerabilidades y parches usando fuentes como Snyk o GitHub Advisory.
Buscar al menos 2 alternativas, incluyendo la opción de implementación interna.
Evaluar el impacto de dependencias transitivas y la madurez del proyecto.
Documentar la decisión con datos, criterios verificados y ejemplos.

Example Use Cases

Comparar date-fns vs moment para manejo de fechas y elegir la opción más ligera.
Elegir got en lugar de axios si solo se necesita HTTP básico.
Evaluar una librería de UI con muchas dependencias versus una solución interna simple.
Revisar la licencia de una dependencia para un proyecto propietario (MIT/Apache vs GPL).
Usar bundlephobia para estimar el tamaño del bundle antes de decidir.

Frequently Asked Questions

Add this skill to your agents