--- type: PG asset_id: PG-MTX-SkillsEcosistema-v01 version: v01 status: N1 sembrado — anti-jerga PASS · N2/N3 en borrador owner: Juan Carlos Angeles Ramírez verificado_por: JuanCarlosX verificado_fecha: 2026-07-20 intellibank: IB-MTX-MatriX nodo_map: "4.5" exposicion: "🔒 interna (llega a N3)" fuente_canonica: CP-XX-BMF-OntologiaSoftware-v01 · PLAN-XX-BMF-EcosistemaSkills-v02 nodo_grafo: "sin nodo propio en v01.3 — ver N3 (decisión abierta)" base: PLAN-MTX-MatriX-MasterPlan-v01 §2.3 (anatomía canónica) --- # Ecosistema de skills y plugins ## 1 · Tarjeta resumen > **¿Qué es en una frase?** La forma ordenada en que la empresa crea, revisa y reparte las habilidades de sus asistentes de inteligencia artificial, para que la capacidad crezca sin volverse un desorden. > **Familia:** D4 · Infraestructura y memoria — la capa de software del sistema operativo > **Metáfora:** es como la tienda de aplicaciones de un teléfono: cualquiera puede programar una app, pero solo las revisadas llegan a la tienda. ## 2 · Nivel 1 · 🌱 Esencial El ecosistema de skills y plugins es la forma ordenada en que la empresa crea, revisa y reparte las habilidades de sus asistentes de inteligencia artificial. Una **habilidad** (o *skill*) es un instructivo que le enseña al asistente a hacer un trabajo concreto: redactar la minuta del día, revisar la salud de los archivos o preparar un reporte. Un **paquete** (o *plugin*) agrupa varias habilidades relacionadas y se instala de una sola vez. Es como la tienda de aplicaciones de un teléfono. Cualquiera puede programar una app, pero no cualquier app llega a la tienda: antes pasa por una revisión. Aquí funciona igual. Cualquier persona del equipo puede crear una habilidad, y solo las que pasan la revisión se comparten con los demás. Esa es la regla que sostiene todo: se abre la creación y se cuida la publicación. Hay tres escalones. En el primero, cualquiera crea una habilidad para su propio uso. En el segundo, si pasa la revisión, se comparte con el equipo. En el tercero, si demuestra su valor, se vuelve oficial o se entrega a un cliente. Cada habilidad lleva su etiqueta: quién la hizo, qué versión es, qué cosas puede tocar y de dónde vino. Las que llegan de fuera esperan en una zona aparte y no se usan hasta ser revisadas. Así se evita el problema clásico de la copia vieja que revive sola y rompe algo. Lo que se gana es simple. Cuando alguien resuelve bien un problema, esa solución se empaqueta y queda disponible para todos, en vez de vivir en la cabeza de una sola persona. ## 3 · Nivel 2 · 🛠 Implementador El principio de operación es **democratizar la creación, gobernar la promoción**. Todos crean; solo lo validado se publica. Se opera con cuatro piezas: **1. Los tres carriles de creación.** Definen quién puede publicar qué y quién autoriza: | Carril | Quién | Qué crea | Gobernanza | |---|---|---|---| | **L0 · Borrador personal** | Cualquiera del equipo | Habilidad en su espacio, para su uso | Libre (no publicada) | | **L1 · Skill de equipo** | Cualquiera, tras pasar el validador | Habilidad compartida en el marketplace del equipo | Valida el validador + el dueño del dominio | | **L2/L3 · Canónica o de cliente** | Se promueve desde L1 | Habilidad oficial del registro, o distribuida a un cliente | Ratifica el senior del dominio / Victor (L3) | Dueños de dominio ratificados: `dg`→Anahí · `tx`→Alex · `mx`→Jay+Victor · `px`→Victor · `gov`→Jay · legal→Victor. **2. La sintaxis.** `sk-{dominio}-{especialidad}` para las habilidades de EmpowerLabs y `wx-{comando}` para las del método WORX (que es org-agnóstico). Dominios vivos: `dg` (demand gen) · `mx` (método) · `px` (producto) · `tx` (técnico) · `gov` (gobernanza). Regla para no confundir habilidad con agente: **quitas el harness y es un `sk-`; se lo pones y es un `/sh-`** — misma columna, dos formas. **3. Las reglas de construcción.** Naming válido antes de escribir · una responsabilidad por habilidad (si hace dos cosas, son dos) · `SKILL.md` compacto con el detalle pesado en `references/` · la `description` con gatillos claros es el 80% de que dispare bien · determinista donde se pueda (scripts para lo mecánico, el modelo para el juicio) · la fuente de verdad vive en el vault y el marketplace es su proyección publicable, nunca al revés. **4. El ciclo de vida.** Crear con `skill-creator` → validar con `sk-skillvalidator` → dar de alta en el registro (`CP-EL-SkillsRegistry-v01`) → publicar con `sx-publicador` (bump de versión → push al repo git → auto-update) → notificar por el buzón y el tablero HOY → auditar periódicamente con `sk-ibhealth` (duplicados, rutas muertas, copias rogue, desactualización). > **Regla de infraestructura:** los marketplaces viven **fuera** del vault. La sincronización corrompe carpetas ocultas y archivos sueltos de código — es la misma lección del scanner del buzón. Pieza faltante hoy: `sk-skillvalidator` (aprobada, pendiente de construir por Jay/Alex). Mientras no exista, la validación se hace a mano contra las reglas de arriba. ## 4 · Nivel 3 · 🔬 Ingeniería — INTERNO **Principio rector de la ontología:** *todo lo que el OS ejecuta debe ser tan direccionable y gobernable como todo lo que el OS escribe.* La capa de documentos ya tenía BMF (`TIPO-ENTIDAD-Proyecto-Nombre-vNN`) y los agentes ya tenían carriles de invocación; a la capa de software le faltaba identidad de catálogo. `CP-XX-BMF-OntologiaSoftware-v01` la define tratando cada pieza como un **XAsset** sobre la misma espina BMF. **Dos ejes ortogonales.** Identidad de catálogo (`asset_id`, ej. `SKL-EL-Sys-IBHealth-v02`) para registry, gobernanza, versión y procedencia; y handle de invocación (`/sk-ibhealth`) para el usuario. La Nomenclatura de Invocación gobierna el eje 2; esta ontología gobierna el eje 1. **Cuatro TIPOs de software:** `MKT` marketplace (repo git contenedor) · `PLG` plugin (bundle distribuible) · `SKL` skill (unidad auto-disparable) · `CMD` comando (invocación explícita). `MKT`/`PLG` no llevan dominio; `SKL`/`CMD` sí. Dos atributos gobernados en frontmatter: `funcion` (vocab cerrado de 6 — `Forge` produce activos · `Gov` mantiene el sistema · `Flow` ritmo diario · `Lens` analiza solo-lectura · `Mind` carga contexto · `Ultra` súper asistente compuesto) y `dominio` (`dgen·sales·prod·ops·kz·pub·gov·sys·doc·hr`, extensible con ratificación L3). **Portafolio de marketplaces como estados de confianza,** no como contenedores: `MKT-EL-WORXOS` (producto, shippable a cliente, `/wx-`) · `MKT-EL-Interno` (plomería del equipo, `/sk-`) · `MKT-EL-Biblioteca` (externos curados y auditados, `/z-`) · **Cuarentena** (banda de entrada, no instalable). Regla dura: el equipo nunca instala directo de un repo público — solo de la Biblioteca curada (patrón *golden repo* / pull-through cache, estilo Artifactory-Nexus). **Ciclo de procedencia** — la madurez es legible en la ENTIDAD del asset ID: `crudo` (upstream, en Cuarentena, sin auditar) → `curado` (`Z`, carril `/z-`, auditado pero "no es nuestro todavía") → `forjado` (`EL`, carriles `/sh- /ux- /sk- /wx-`, reconstruido con cognición + harness + gobernanza WORX). Consistente con el UpgradePipeline: **upgrade ≠ migración** — pasar de `Z` a `EL` es creación de valor, no re-aliasar. **Sello de auditoría como dato, no como promesa.** Todo `SKL`/`PLG` lleva hoja de procedencia en frontmatter (mini-SBOM estilo SLSA): `origen · fuente · licencia · madurez · estado · permisos{escribe,red,borra} · auditoria{fecha,por,veredicto,version_auditada}`. La compuerta para subir a Biblioteca exige los 5 criterios: estructura válida · seguridad (sin código malicioso, sin red no declarada, sin exfiltración) · sin rutas muertas ni hardcode de sesión · licencia compatible registrada · reclasificación a `SKL-Z--` con procedencia completa. Sin los 5, no sube. **Cinco patrones adoptados de cadenas de suministro maduras:** (1) **yank/deprecate** de npm-crates.io — `estado: yanked` + auto-update la retira sola; resuelve la clase entera de bugs *"skill vieja que revive"* (caso Reinventaverse). (2) **Manifiesto de permisos** por skill, menor privilegio por defecto, verificado en la auditoría — cierra el control de acceso cliente vs interno. (3) **Canales de madurez opt-in** estilo Debian: `stable` (solo forjado) o `edge` (incluye curado reciente). (4) **Firma + log de transparencia** (Sigstore/cosign) — da verificación de integridad y alerta si la sync mutila un archivo. (5) **CODEOWNERS por dominio** — la tripleta aplicada al código y automatizada en el gate. **Estado de las fuentes (ratificación diferida):** `CP-XX-BMF-OntologiaSoftware-v01` está en **Propuesta canónica pendiente de ratificación L3 de Victor**, con 5 decisiones abiertas (§9: ratificar los 6 tipos de `funcion` y el vocab de `dominio`; confirmar ENTIDAD `Z`; set inicial de marketplaces; si `sk-skillaudit` es skill nueva o módulo de `sk-ibhealth`; prioridad de adopción de los 5 patrones — recomendado yank y permisos primero). `PLAN-XX-BMF-EcosistemaSkills-v02` está en Draft, pero sus decisiones §9 **sí** fueron ratificadas por Victor el 11-jul (3 carriles, sintaxis, construir el validador, benchmark). N1/N2 son pedagógicos y estables; al ratificarse la ontología conviene revisar drift. **Nota de vocabulario (drift entre las dos fuentes):** el PLAN usa dominios `dg·mx·px·tx·gov` y la ontología usa `dgen·sales·prod·ops·kz·pub·gov·sys·doc·hr`. Son dos listas distintas para el mismo atributo. Queda marcado como NEXT de reconciliación en el paquete final — la página presenta la del PLAN en N2 (es la ratificada y la que el equipo usa hoy) y la de la ontología en N3. **Nodo del grafo:** no existe nodo propio para esta página en `ARQ-EL-Ecosistema-ModeloGrafo-v01` v01.3 (27 nodos). Es una decisión de diseño abierta —si la capa de software merece nodo en el grafo de *portafolio*— y se deja a criterio de JC/Victor en la revisión general, sin crearlo unilateralmente. Referencia completa: `CP-XX-BMF-OntologiaSoftware-v01` · `PLAN-XX-BMF-EcosistemaSkills-v02` · `MI-XX-BMF-EcosistemaSkills-Benchmark-v01` · WikiX [[Ontologia-Agentica]] · [[Registro-Agentico]]. ## 5 · Casos de uso 1. **Alguien del equipo automatiza algo suyo y termina sirviendo a todos.** Nace como borrador personal (L0). Pasa el validador, se comparte con el equipo (L1) y, si demuestra valor, se vuelve oficial (L2/L3). La solución deja de vivir en la cabeza de una persona. 2. **Llega una habilidad de fuera y no se instala a ciegas.** Entra a Cuarentena, se audita contra los 5 criterios, y solo entonces sube a la Biblioteca curada con su hoja de procedencia. El equipo nunca instala directo de un repo público. 3. **Una versión sale mala y se retira sin perseguir a nadie.** Se marca `estado: yanked` y el auto-update la quita sola de las instalaciones — en vez de pedirle a cada persona que la desinstale a mano. ## 6 · Verifica tu comprensión 1. **¿Cuál es la regla que sostiene todo el ecosistema?**
Ver respuestaDemocratizar la creación y gobernar la promoción: cualquiera puede crear una habilidad, pero solo lo que pasa la validación se publica y se vuelve compartido u oficial. Se organiza en tres carriles (L0 personal · L1 equipo · L2/L3 canónica o de cliente).
2. **¿Por qué las habilidades que vienen de fuera no se usan de inmediato?**
Ver respuestaPorque entran a una zona de espera (Cuarentena) y no se instalan hasta ser auditadas: estructura válida, seguridad, sin rutas muertas, licencia compatible y reclasificación con hoja de procedencia. Solo lo auditado sube a la Biblioteca curada, y el equipo nunca instala directo de un repo público.
3. **¿Qué diferencia hay entre una habilidad (`sk-`) y un agente (`/sh-`)?**
Ver respuestaEl harness. Una habilidad es la capacidad sola — el instructivo. Al ponerle el harness (el envoltorio que la hace correr como agente) se vuelve un Sherpa. Misma columna, dos formas: quitas el harness y es `sk-`; se lo pones y es `/sh-`.
## 7 · Conexiones - Relacionado: [[PG-MTX-IntelliBanks-v01]] (donde vive la fuente de verdad que el marketplace proyecta) · [[PG-MTX-SherpaX-v01]] (quien ejecuta las habilidades) · [[PG-MTX-Gobernanza-v01]] (naming, tripleta y niveles L0-L3 aplicados aquí al código) · [[PG-MTX-SherpaTeamsX-v01]] (habilidad + harness = agente) - Nodo del grafo: sin nodo propio en v01.3 — decisión de diseño abierta (ver N3) - Fuente canónica: [[CP-XX-BMF-OntologiaSoftware-v01]] · [[PLAN-XX-BMF-EcosistemaSkills-v02]] - Referencia completa (WikiX): [[Skills-Home]] · [[Ontologia-Agentica]] · [[Registro-Agentico]] · [[Naming-Convention]] ## 8 · Ficha | Campo | Valor | |---|---| | Dueño de la página | Juan Carlos Angeles Ramírez | | Verificado | 2026-07-20 por JuanCarlosX (contra ambas fuentes canónicas) | | Anti-jerga | PASS 2026-07-20 | | Fuente canónica | CP-XX-BMF-OntologiaSoftware-v01 (Propuesta · pend. ratificación L3) · PLAN-XX-BMF-EcosistemaSkills-v02 (Draft · decisiones §9 ratificadas 11-jul) | | Nodo del MAP | 4.5 | | Exposición | 🔒 interna (llega a N3) | | Versión | v01 | --- *PG-MTX-SkillsEcosistema-v01 · IB-MTX-MatriX/Pages/ · D4 · Infraestructura y memoria · Owner: Juan Carlos · Sherpa: JuanCarlosX · 2026-07-20*