---
type: PLAN
asset_id: PLAN-XX-BMF-EcosistemaSkills-v02
version: v02
status: Draft · para ratificación Victor (L3+)
owner: Victor Heredia
sherpa: Jay
ratificador: Victor Heredia
intellibank: IB-XX-Maestro
subbank: IPI-XX-IP-Infraestructura / IPI-XX-BMF-Engine
supersedes: PLAN-XX-BMF-EcosistemaSkillsPluginsMarketplaces-v01 (re-anclado al documento correcto de Victor)
proposito: >
  Plan del ecosistema de Skills · Plugins · Marketplaces de EmpowerLabs, estructurado 1:1 sobre el
  outline de Victor (RTF "Intellibanks PlugIns Ultra Sherpas Skills"). Responde sus preguntas
  abiertas con propuestas concretas: quién crea skills, sintaxis, reglas, registro, procesos de
  validación/búsqueda/publicación/auditoría, infraestructura, mejores prácticas y next steps.
disparador: RTF de Victor 2026-07-11 + seed empowerlabs-masters. Corrige el foco del v01 (que se fue a marketplaces de 4 tiers).
relacionado:
  - CP-EL-SkillsRegistry-v01 · SOP-EL-SkillsAlta-v01 (registro + alta existentes)
  - PP-XX-BMF-FuerzaLaboralAgentica-Arquitectura-v01 (ontología · agentes)
  - CP-XX-BMF-RegistroAgentico-v01 · SX-MastersPack · sx-publicador · sx-consejero
  - SPEC-EL-WORX-GitMarketplace-AutoUpdate-v01 (distribución git)
  - sk-ibhealth (auditoría de salud de skills) · skill-creator (creación) · sk-consejero (búsqueda/recomendación)
gate_g0: PASS — sobre el RTF de Victor + registro/alta/masters/git-marketplace ya en el vault
fecha_creacion: 2026-07-11
tags: [PLAN, skills, plugins, marketplace, sintaxis, registro, validacion, auditoria, playbook, gobernanza, democratizado]
---

# Plan · Ecosistema de Skills de EmpowerLabs
## Estructurado sobre tu outline — quién crea, cómo se nombran, dónde viven, cómo se validan y auditan

> **Nota de reencuadre (honesto).** El v01 estaba grounded pero apuntó a la **estrategia de marketplaces de 4 tiers** y a la factoría admin `/sx-`. Tu documento pide algo más operativo y para el equipo: **el sistema de cómo hacemos, nombramos, registramos, validamos y mantenemos skills día a día**. Este v02 sigue tu outline sección por sección y responde cada pregunta abierta con una propuesta concreta + marca las **decisiones que solo tú tomas**.

---

## 1. Mindset

- **Modo ecosistema, no banco.** Una skill no es un archivo suelto: es un componente con dueño, sintaxis, versión, valor y gobernanza, que vive en un sistema que lo produce, valida, publica y retira.
- **Sistema Operativo Organizacional (SOOI).** El ecosistema de skills es una pieza del SOOI: cómo la organización instala y opera capacidad. Empata con WORX (una skill es una capacidad del método) y con la Fuerza Laboral Agéntica (una skill + harness = un agente).
- **Principio rector:** *democratizar la creación, gobernar la promoción.* Que todos puedan crear; que solo lo validado se publique y se vuelva canónico.

---

## 2. Estructura

### 2.1 Gobernanza — ¿quién puede crear skills? → **TODOS, en 3 carriles**
Tu nota decía "TODOS". La propuesta que hace eso seguro:

| Carril | Quién | Qué crea | Gobernanza |
|---|---|---|---|
| **L0 · Borrador personal** | Cualquiera del equipo | Skill en su espacio, para su uso | Libre (no publicada) |
| **L1 · Skill de equipo** | Cualquiera, tras pasar el **validador** | Skill compartida en el marketplace de equipo | Valida el validador + owner del dominio |
| **L2/L3 · Skill canónica / cliente** | Promovida desde L1 | Skill que entra al Registro canónico o se distribuye a cliente | Ratifica senior del dominio / Victor (L3) |

> **Decisión tuya:** confirmar estos 3 carriles y quién es "owner de dominio" (ej. Anahí=dgen, Alex=infra, Jay=método).

### 2.2 Sintaxis (nomenclatura)
Tu convención, formalizada — **skills** con prefijo por origen + dominio:

- `sk-{dominio}-{especialidad}` → skills de EmpowerLabs. Ej. `sk-dg-linkedin-inbound` (dg = demand gen), `sk-bcsave`, `sk-ibhealth`.
- `wx-{comando}` → skills/comandos del método WORX (org-agnóstico). Ej. `wx-arrancaroom`, `wx-mindia`.
- **Dominios** (el `{dominio}`): `dg` (demand gen), `mx` (método), `px` (producto), `tx` (técnico), `gov` (gobernanza)… lista cerrada en el Registro.

Y su relación con los **agentes** (skill + harness + Brain Code), para que no se confundan:

| Prefijo | Es | Nivel |
|---|---|---|
| `sk-` / `wx-` | **Skill** (capacidad, sin harness) | Componente |
| `/sh-` | Sherpa (skill + harness) | Agente de tarea |
| `/ux-` | UltraSherpaX (compuesto) | Agente especialista |
| `/dx-` | DirectorX (mandato permanente) | Agente líder |
| `/sx-` | Maestros (forjan/gobiernan) | Admin |

> Regla simple: **quitas el harness y es un `sk-`; se lo pones y es un `/sh-`.** Misma columna, dos formas.

### 2.3 Cuáles son las reglas
1. Naming BMF válido **antes** de escribir (`sk-`/`wx-` + dominio).
2. `SKILL.md` **regla limpia**: sin ángulos (el validador lo lee como XML) — usar `{llaves}`; `description` en una línea; texto plano.
3. **Una responsabilidad por skill** (compactas — ver §5).
4. Toda skill lleva **tripleta** (Owner·Sherpa·Ratificador) y estado.
5. La **fuente de verdad** vive en el vault; el plugin/marketplace es proyección publicable (nunca al revés).
6. El marketplace **nunca dentro del vault** (la sync corrompe dotfiles) — repos git aparte.

### 2.4 Tipos
- Por **origen:** EmpowerLabs (`sk-`) · WORX (`wx-`) · externas (`/z-`, los 70 specialists).
- Por **función:** creación · gobernanza/auditoría · dominio (dgen, editorial…) · maestras (`/sx-`).
- Por **madurez:** L0 borrador · L1 equipo · L2/L3 canónica/cliente.

### 2.5 Registro — dónde vive y qué info tiene
- **Dónde:** `CP-EL-SkillsRegistry-v01` (skills) — hermano del `CP-XX-BMF-RegistroAgentico` (agentes). Fuente de verdad única; el marketplace se deriva de él.
- **Qué campos:** `id · tipo · dominio · dueño · estado(L0–L3) · versión(SemVer) · gatillos · valor/prioridad · dependencias · eval(estado) · repo/plugin destino · fecha`.

---

## 3. Procesos (el corazón operativo)

| Proceso | Propuesta | Con qué se hace |
|---|---|---|
| **Dueño del proceso** | Un rol **Curador de Skills** (arranque: Jay + owners de dominio) responsable de creación·mantenimiento·gestión | rol formal (ROL-) |
| **Validación** (sintaxis, prioridad, valor, filtrar/evaluar) | Un **validador** obligatorio en el alta: revisa naming, regla-limpia, una-responsabilidad, gatillos, valor×esfuerzo, y que no haya artefactos de sync | **`sk-skillvalidator`** (nuevo) — envuelve el eval de `skill-creator` + el CI del seed |
| **Búsqueda de skills** | "¿qué skill uso para X?" → recomendación desde el Registro | **`sk-consejero`** (ya existe, advisory) |
| **Publicación** | Empaqueta, valida, bump SemVer, push a marketplace git | **`sx-publicador`** (ya existe) → `SPEC-GitMarketplace-AutoUpdate` |
| **Skill validador especializado** (tu "checar cualquier cosa que no esté bien") | = `sk-skillvalidator`; se invoca en alta **y** en auditoría periódica | invocación `/sk-skillvalidator {ruta|dominio}` |
| **Auditoría** (que todo esté en orden) | Barrido de salud: duplicados, rutas muertas, copias rogue, drift de versión, huérfanos | **`sk-ibhealth`** (ya existe, audita skills) + `sk-skillvalidator` |

> Falta construir solo **`sk-skillvalidator`**; el resto ya existe y solo se conecta.

---

## 4. Infraestructura

- **Protocolo de gestión:** fuente en el vault → `sx-publicador` → repo git por tier → auto-update (`GITHUB_TOKEN`) → CI valida (Action del seed).
- **Cuándo se actualiza:** al hacer **bump de SemVer** en `plugin.json` (dispara auto-update). Cadencia: publicación por lotes (no cada cambio).
- **Cómo se notifica:** al equipo, vía el **Buzón** (`MSG- informar`) + el tablero HOY cuando hay una skill/plugin nuevo o versión.

---

## 5. Diseño y construcción — mejores prácticas (skills "compactas")

1. **Una responsabilidad** — si hace dos cosas, son dos skills.
2. **Compacta** — `SKILL.md` corto; el detalle pesado va en `references/` (progressive disclosure), no en el cuerpo.
3. **Description-first** — la `description` con gatillos claros es el 80% de que dispare bien.
4. **Regla limpia** — sin ángulos; `{llaves}`.
5. **Determinista donde se pueda** — scripts para lo mecánico; el LLM para el juicio.
6. **Cómo se generan:** con `skill-creator` (crea/edita/evalúa) → pasa por `sk-skillvalidator` → alta en Registro (`SOP-EL-SkillsAlta`) → publicación.

---

## 6. Proceso de trabajo para CONSTRUIR esto (tu método WORX aplicado)

El outline ya trae el método; lo hacemos explícito como las fases del proyecto:
1. **Analizar el proceso actual** (as-is: registro, alta, masters, git-marketplace — ya inventariado aquí).
2. **Visualizar el futuro** (demanda: 6→100 personas creando skills; requerimiento: gobernanza que escale).
3. **Estructura tipo SOOI** (esta ontología + sintaxis + registro).
4. **Propuesta + Spec inicial** (este PLAN → SPEC del validador y del registry) — el "lenguaje IA" como competencia clave.
5. **Benchmark** de casos similares (marketplaces de skills/plugins 2026, gobernanza de agentes) → adoptar lo probado.
6. **Adoptar ideas probadas** e iterar.

---

## 7. Resultado (lo que produce el proyecto)

- **Skill para crear** → `skill-creator` (existe) + `sk-skillvalidator` (nuevo) = crear-con-gobernanza.
- **Estructura** → ontología con sintaxis (§2) canonizada en `CP-XX-BMF-OntologiaAgentica` + esta convención de skills.
- **Registry** → `CP-EL-SkillsRegistry` al día, con los campos de §2.5.
- **Ecosistema** → skills → plugins → marketplace de equipo, operable por todos con gobernanza.

---

## 8. Next Steps (los que listaste, con dueño)

- [ ] **Proceso para actualizar todo** — SOP de publicación (bump→push→auto-update→notificar). *Owner: Alex + Jay.*
- [ ] **Actualizar el marketplace** con sus plugins/skills actuales (empezar por el de equipo). *Alex.*
- [ ] **Guía del equipo para arrancar a primera hora** — quick-start de 1 página. *Jay.*
- [ ] **Documentación del proceso** — este PLAN + SOP + el playbook. *Jay.*
- [ ] **Doc de implementación con clientes** — cómo se instala el ecosistema de skills en un cliente. *Victor + Jay.*
- [ ] **Proceso para seleccionar/filtrar/auditar skills** — `sk-skillvalidator` + `sk-ibhealth`. *Jay.*
- [ ] **Actualizar el Playbook de Skills** + **Playbook del equipo (instrucciones)**. *Jay.*
- [ ] **Habilidad + proceso para crear/actualizar/mantener** — cierra con `skill-creator`+validador+registry. *Jay.*
- [ ] Construir **`sk-skillvalidator`** (única pieza faltante). *Jay/Alex.*

---

## 9. Decisiones — RATIFICADAS por Victor (2026-07-11, L3+)
1. ✅ **"Todos crean" en 3 carriles** (L0 borrador · L1 equipo validada · L2/L3 canónica-cliente). **Owners de dominio ratificados (12-jul):** dg→Anahí · tx→Alex · mx→Jay+Victor · px→Victor · gov→Jay · legal→Victor.
2. ✅ **Sintaxis ratificada:** `sk-{dominio}-{especialidad}` (EmpowerLabs) + `wx-` (WORX); dominios `dg·mx·px·tx·gov` (lista viva en el Registro).
3. ✅ **Aprobado construir `sk-skillvalidator`** — la pieza faltante.
4. ✅ **Benchmark con deep-research** en curso (→ `MI-XX-BMF-EcosistemaSkills-Benchmark-v01`); **diseño fino con Fable** aprobado. *Nota de modelo: este room corre en Opus; el diseño fino se puede ejecutar aquí (Opus, apto para arquitectura) o en un room con el modelo Fable — ver nota al pie.*

## CHANGELOG
| Versión | Fecha | Cambio |
|---|---|---|
| v02 | 2026-07-11 | Re-anclado al RTF de Victor. Plan estructurado 1:1 sobre su outline (mindset/estructura/procesos/infra/diseño/método/resultado/next steps); democratización en 3 carriles, sintaxis sk-/wx- vs agentes, registro, validador nuevo, auditoría con piezas existentes. Supersede al v01 (que sobre-rotó a marketplaces de 4 tiers). |
| v01 | 2026-07-11 | (superseded) Enfoque en 4 tiers de marketplace desde el seed admin. |