[FEATURE] Refactorizar skills-map a arquitectura de plugins autosuficientes

[Angelito91]

Is your feature request related to a problem? Please describe.

📌 Problema

El archivo skills-map.ts (1300 líneas) mezcla todo en un monolito:

• Tecnologías frontend, backend, mobile, cloud
• Lógica de detección
• Skills y configuraciones

Dificulta:

• ❌ Agregar nuevas tecnologías
• ❌ Conflictos de merge en equipo
• ❌ Mantener código escalable

Describe the solution you'd like

✅ Solución: Plugins Autosuficientes

Dividir en módulos independientes donde cada categoría tiene todo integrado: detección, skills y configuración.

Estructura Nueva

skills-map/
├── types.ts                    (interfaces compartidas)
├── loader.ts                   (orquestador)
├── categories/
│   ├── frontend/
│   │   ├── config.ts          (FRONTEND_PACKAGES, patrones)
│   │   ├── detect.ts          (detectFrontend())
│   │   ├── skills.ts          (FRONTEND_TECHNOLOGIES)
│   │   └── index.ts
│   ├── backend/
│   │   ├── config.ts
│   │   ├── detect.ts
│   │   ├── skills.ts
│   │   └── index.ts
│   ├── mobile/, cloud/, data/, auth/, testing/, other/
│   │   └── (misma estructura)
└── combos/
    └── index.ts               (combos de skills)

---

🎯 Cómo Funciona

Cada categoría es completamente independiente:

frontend/config.ts
├─ PACKAGES: ["react", "vue", "svelte"]
├─ CONFIG_FILES: ["react.config.js"]
└─ EXTENSIONS: [".jsx", ".tsx"]

frontend/detect.ts
└─ detectFrontend(projectDir, pkg)
   Busca en: packages → config files → extensiones

frontend/skills.ts
└─ FRONTEND_TECHNOLOGIES: [
     { id: "react", skills: [...] },
     { id: "vue", skills: [...] }
   ]

El loader.ts orquesta todo:

detectAllTechnologies() → ejecuta todos los detectores en paralelo

---

✨ Ventajas

Aspecto	Beneficio
Independencia	Cada módulo = su lógica completa
Escalabilidad	Agregar React Native = nueva carpeta, sin tocar nada
Paralelismo	Equipos pueden trabajar en categorías diferentes
Mantenibilidad	Cambiar detección de React = solo frontend/detect.ts
Testing	Testear detectFrontend() sin tocar backend

---

📋 Plan de Trabajo

• Crear skills-map/ con estructura base
• Mover types.ts y constants.ts
• Crear categories/frontend/, backend/, mobile/, etc.
• Implementar detect.ts, skills.ts, config.ts en cada categoría
• Crear loader.ts con orquestación
• Actualizar lib.ts para usar nuevo sistema
• Eliminar skills-map.ts antiguo
• Tests & validación

---

🚀 Resultado

• Modularidad: 8 carpetas pequeñas en lugar de 1 archivo de 1300 líneas
• Crecimiento: Escalable a miles de skills sin problemas
• Colaboración: Equipos pueden agregar skills sin conflictos

Describe alternatives you've considered

No response

[tonyblu331]

Esto ya se discutio en el issue #62 , es interesante ver que el mismo aún sigue siendo algo que se evalua, pero puedes revisar la discusión acá. Aparte no creo que un loader.ts sea necesario, sería añadir una capa de abstración de forma innecesaria. Pero se entiende la semántica la cual propones.

De paso creo que tienes la issue duplicada con la #88 asi que te sugieriria consolidarlas en una y borrar la otra.

[Angelito91]

Esto ya se discutio en el issue #62 , es interesante ver que el mismo aún sigue siendo algo que se evalua, pero puedes revisar la discusión acá. Aparte no creo que un loader.ts sea necesario, sería añadir una capa de abstración de forma innecesaria. Pero se entiende la semántica la cual propones.

De paso creo que tienes la issue duplicada con la #88 asi que te sugieriria consolidarlas en una y borrar la otra.

Okey 👍 Ya elimine el issue #88. Revise el issue #62 es prácticamente la misma esencia. Ya que el proyecto por la escala que va a tener, necesita separar y usar una mejor arquitectura. Pues seguramente van a ver personas que quieran agregar más tecnologías. En mi caso quería contribuir en agregar C++ y me di cuenta de lo unido que esta toda la lógica, lo que hace que las PR sean difíciles de hacer y revisar

[tonyblu331]

De momento la solución que se sugirió por parte de @midudev fue la de implementar testing y mejorar los guardrails, en el mismo explicó el porqué. El PR #76 una vez aprobado, incluiría el testing para estos escenarios.

[Angelito91]

Excelente veo que agregaste un contributing #76. De todas forma la solución de @midudev va ser una curita para lo que se viene 🙂👍

[midudev]

/oc summarize

[opencode-agent]

Summary: Refactor skills-map to Plugin Architecture

Problem: skills-map.ts is a 1300-line monolith mixing all technology categories (frontend, backend, mobile, cloud) with detection logic, skills, and configs in one file. This makes adding technologies, reviewing PRs, and maintaining code difficult.

Proposed Solution: Split into self-sufficient plugin modules:

skills-map/
├── types.ts, loader.ts
├── categories/frontend/, backend/, mobile/, cloud/, etc.
│   └── config.ts, detect.ts, skills.ts, index.ts
└── combos/

Status: Controversial. Maintainer @midudev prefers improving testing/guardrails (PR #76) over architectural refactoring. Issue #88 was duplicated and deleted. Discussion continues in issue #62.

opencode session  |  github run