From alfred-dev
Evaluates technology stacks using weighted decision matrix. Compares frameworks, languages, databases via scored criteria like performance, ecosystem, maintenance, security. For objective tech selection.
npx claudepluginhub 686f6c61/alfred-dev --plugin alfred-devThis skill uses the workspace's default tool permissions.
Este skill evalúa alternativas tecnológicas de forma estructurada mediante una matriz de decisión ponderada. El objetivo es eliminar el sesgo de "lo que ya conozco" o "lo que está de moda" y sustituirlo por una evaluación objetiva basada en criterios relevantes para el proyecto concreto.
Analyzes technical decisions like library selections, architecture patterns, and stack choices via multi-agent research, tradeoffs, and two-part executive reports.
Recommends full technology stacks for new projects based on requirements, team expertise, and constraints like scale, performance, budget, and time-to-market.
Analyzes technical decisions like library selection, architecture patterns, and tech stacks using multi-source research, tradeoff scoring, and conclusion-first reports.
Share bugs, ideas, or general feedback.
Este skill evalúa alternativas tecnológicas de forma estructurada mediante una matriz de decisión ponderada. El objetivo es eliminar el sesgo de "lo que ya conozco" o "lo que está de moda" y sustituirlo por una evaluación objetiva basada en criterios relevantes para el proyecto concreto.
La elección de stack es una de las decisiones más costosas de revertir, por lo que merece un análisis riguroso. Este skill produce un documento que justifica la decisión y sirve como referencia futura para el equipo.
Consultar el stack actual del proyecto. Consultar el stack detectado en la configuración de Alfred (detect_stack) como punto de partida. Si no está disponible, detectar manualmente revisando los ficheros de configuración del proyecto (package.json, Cargo.toml, pyproject.toml, etc.). Partir del contexto existente evita proponer tecnologías incompatibles con lo que ya hay.
Recopilar requisitos del proyecto. Antes de evaluar tecnologías, entender qué se necesita: tipo de aplicación, escala esperada, equipo disponible, restricciones de tiempo, presupuesto y requisitos regulatorios.
Definir los criterios de evaluación y sus pesos. Los criterios dependen del contexto, pero considerar siempre:
| Criterio | Peso sugerido | Descripción |
|---|---|---|
| Rendimiento | Variable | Latencia, throughput, uso de memoria según las necesidades del proyecto. |
| Ecosistema | Alto | Librerías, frameworks, herramientas disponibles. |
| Curva de aprendizaje | Variable | Tiempo que necesita el equipo para ser productivo. |
| Mantenimiento | Alto | Facilidad de actualizar, depurar y evolucionar. |
| Seguridad | Alto | Historial de vulnerabilidades, prácticas del ecosistema. |
| Comunidad | Medio | Tamaño, actividad, calidad de documentación. |
| Coste operativo | Variable | Infraestructura, licencias, herramientas de pago. |
| Madurez | Medio | Estabilidad de la API, versionado, backwards compatibility. |
El usuario asigna los pesos finales. Si no lo hace, usar los sugeridos justificando la elección.
Identificar al menos 3 alternativas. Para cada capa del stack (lenguaje, framework, base de datos, etc.), proponer un mínimo de 3 opciones viables. Incluir siempre al menos una opción "conservadora" (probada y estable) y una "emergente" (más moderna pero con menos recorrido).
Evaluar cada alternativa contra los criterios. Puntuar de 1 a 5 cada criterio para cada alternativa. Multiplicar por el peso. Documentar la justificación de cada puntuación, no solo el número.
Calcular la puntuación total ponderada. Sumar los valores ponderados y ordenar las alternativas de mayor a menor.
Analizar los resultados cualitativamente. La puntuación más alta no siempre es la mejor opción. Considerar factores difíciles de cuantificar: experiencia del equipo, alineación con el ecosistema existente, riesgos de vendor lock-in.
Emitir una recomendación con justificación. Indicar la opción recomendada, por qué se elige y qué riesgos se asumen. Si la decisión es ajustada, indicarlo explícitamente.
Documentar como ADR. Si la decisión es significativa, generar un ADR (Architecture Decision Record) con el skill write-adr para que quede constancia en el repositorio.
Registrar la elección en la memoria del proyecto con memory_log_decision. Esto permite que futuros skills consulten qué tecnologías se han elegido y por qué, sin necesidad de buscar el documento original.