---
type: SOP
asset_id: SOP-EL-SkillsAlta-v03
version: v03
status: Vigente
owner: Victor Heredia
sherpa_owner: Jay
ratificador: Victor Heredia (L3+)
fecha_creacion: 2026-06-18
fecha_ultima_actualizacion: 2026-07-11
intellbank: IB-EL-EmpowerLabs
subbank: CP-EL-Control-Planes
proposito: El ciclo de vida completo de una skill — crear, guardar, compartir y mantener el banco actualizado. v03 agrega la automatización del ciclo con /sx-publicador, el capítulo de maestros /sx- (admin-exclusivos) y el protocolo de renombrados.
supersede: SOP-EL-SkillsAlta-v02 (v02 documentaba el ciclo 100% manual; v03 lo automatiza con /sx-publicador y agrega el canal de maestros)
relacionados:
  - CP-EL-SkillsRegistry-v01 (el banco / inventario)
  - MPB-EL-SkillsPlaybook-v01 (conceptos y tips por nivel)
  - SPEC-EL-WORX-GitMarketplace-AutoUpdate-v01 (infra git + auto-update + CI)
  - SX-MastersPack/sx-publicador (el brazo que automatiza las fases 2-4)
  - TP-EL-PluginMarketplace-Handoff-v01 (publicación al equipo)
tags: [SOP, skills, ciclo-de-vida, crear, guardar, compartir, mantener, marketplace, plugin, publicador, sx, glosario]
---

# SOP · Ciclo de vida de una Skill · v03
## Crear · Guardar · Compartir · Mantener — de la idea al equipo, ahora con publicador

> **Regla raíz #1 (arquitectura):** el **marketplace** de plugins vive en su **propio repo git,
> FUERA del vault** Intellibanks. NUNCA dentro del vault: la sincronización mutila los archivos
> ocultos (`.claude-plugin`→`archivo.claude-plugin`, `plugin.json`→`plugin_json.md`) y rompe los plugins.
>
> **Regla raíz #2 (caché):** se edita la **FUENTE** (el repo git), nunca el **caché instalado**
> (`.remote-plugins/`). Editar el caché rompe el descubrimiento de comandos.
>
> **Regla raíz #3 (v03 — automatización):** las fases 2-4 se ejecutan con **`/sx-publicador`** —
> el maestro empaqueta, valida, hace el bump y publica con confirmación humana antes del push.
> Lo manual queda como respaldo/detalle; el camino por defecto es el publicador.
>
> **Qué SÍ va en el vault:** el **banco/registry** y este playbook — son `.md` normales y sincronizan bien.

---

## Mapa del ciclo (4 fases + el brazo que las corre)

```
1. CREAR     → detectar patrón · decidir tipo · generar · Gate G0        (humano + generadores)
2. GUARDAR   → colocar en la FUENTE (repo git) · subir versión           ┐
3. COMPARTIR → empaquetar (.plugin) · publicar (git push) · instalar     ├─ /sx-publicador (L2)
4. MANTENER  → actualizar · registrar en banco · retirar viejo · verificar┘
```

---

# FASE 1 · CREAR

### 1.1 Detectar el candidato
Un flujo que repites **≥3 veces** con la misma estructura es candidato a skill.

### 1.2 Decidir el tipo
- **Skill** — dispara sola por su `description` (capacidades que el modelo activa por contexto).
- **Comando** (`/nombre`) — lo disparas tú explícitamente.
- **SVA / UltraSherpaX** — súper asistente (shell × Brain Code); se fabrica con `/sx-fabricador-usherpax`.
- **DirectorX** — líder de unidad de negocio (clase /dx-); se fabrica con `/sx-fabricador-directorx` desde SPEC ratificada.

### 1.3 Decidir el plugin destino
| Si es… | Plugin | Marketplace |
|---|---|---|
| Operación WORX del día a día | `worx-empowerlabs` | equipo |
| Producto WikiX | `worx-wikix` | equipo |
| Cognición / súper asistente (SVA) | `worx-ultrasherpas` | equipo |
| Gobernanza interna (sk-) | `worx-governance` | equipo |
| Base org-agnóstica (individual) | `worx-core` | equipo |
| **Maestro /sx- (admin-exclusivo)** | **canal masters — ver §Maestros** | **solo admin** |
| Dominio nuevo que no encaja | plugin nuevo en el marketplace | equipo |

### 1.4 Gate G0 — ¿ya existe?
Consulta `CP-EL-SkillsRegistry-v01` antes de crear. Si ya existe → versiónala, no dupliques.

### 1.5 Generar
Motor según el tipo: `skill-creator` (genéricas) · `/sx-fabricador-usherpax` (SVAs) · `/sx-fabricador-directorx` (DirectorX) · `sk-bcdistiller` (Brain Codes) · o el `.md` del comando a mano. **La `description` es el disparador** — inclúyele las frases reales del usuario. SKILL.md corto; detalle pesado en `references/`.

---

# FASES 2-4 · EL CAMINO POR DEFECTO: `/sx-publicador`

Invoca **`/sx-publicador`** con lo que cambió. Él ejecuta el pipeline completo:

1. Localiza el repo local del marketplace (fuera del vault) · verifica limpio y al día.
2. Detecta cambios (alta / edición / **renombrado** / retiro) por plugin.
3. Sincroniza fuente → repo (skills a `{plugin}/skills/`, comandos a `{plugin}/commands/`).
4. **Valida** (checklist anti-corrupción: 1 `plugin.json` por plugin · JSON válidos · cero `archivo.*`/`*_json.md` · regla limpia · sin secretos).
5. **Bump SemVer obligatorio** por plugin cambiado + README.
6. Commit convención `{plugin}@{version}: {cambio}` → **confirmación humana** → push (o entrega los comandos para Terminal si no hay credenciales en la sesión).
7. Verifica CI verde · el equipo recibe por autoUpdate o `/plugin marketplace update`.
8. Actualiza `CP-EL-SkillsRegistry` + dashboard · recuerda retirar cachés viejos.

**Protocolo de renombrados (lección del caso `/sx-fabricador` → `/sx-fabricador-usherpax`):** renombrar = alta del nuevo **+ retiro del viejo** en el repo Y en los cachés instalados. Si el viejo queda, el equipo opera con dos versiones y el viejo puede recrear rutas obsoletas.

*El detalle manual de cada fase (por si el publicador no está disponible) queda en `SOP-EL-SkillsAlta-v02` §F2-F4 — sigue siendo válido como respaldo.*

---

# MAESTROS /sx- · Distribución admin-exclusiva

Los maestros de clase `/sx-` (consejero, fabricadores, curadores, publicador) **actúan sobre el sistema** y son admin-exclusivos por canon (`CP-XX-BMF-NomenclaturaInvocacion`): **jamás se publican al marketplace del equipo.**

- **Fuente canónica:** `IB-XX-Maestro/.../IPI-XX-BMF-Engine/SX-MastersPack/` (vault — solo la fuente `.md`; ahí la sync no daña porque no lleva dotfolders).
- **Canal de distribución (ratificado Victor L3+ 2026-07-11):** repo privado separado **`empowerlabs/empowerlabs-masters`** con marketplace propio y plugin único `worx-masters`. Token de lectura solo en la máquina admin. Mismo mecanismo de auto-update que el marketplace del equipo — exclusividad real.
- **Flujo:** fuente canónica en el SX-MastersPack del vault → `/sx-publicador` sincroniza al repo masters → bump → push → auto-update en la máquina de Victor.

---

## Conceptos + estructura del plugin

**Los tres, sin confundir:** **Plugin** = la caja que instalas (agrupa comandos + skills) · **Comando** (`/nombre`) = acción que tú disparas (vive en `commands/`) · **Skill** = capacidad que dispara sola por su `description` (vive en `skills/`).

**La anatomía que TODO plugin debe tener:**
```
{plugin}/
├── .claude-plugin/
│   └── plugin.json        ← manifiesto (name · version · description · author · keywords). ÚNICO archivo aquí.
├── commands/
│   └── {nombre}.md        ← un archivo = un /comando
├── skills/
│   └── {slug}/
│       ├── SKILL.md       ← frontmatter (name + description) + instrucciones
│       └── references/    ← opcional: detalle pesado
└── README.md
```

## Recomendaciones de eficiencia (tokens) al escribir skills

El `SKILL.md` se carga **entero** en cada disparo — cada línea se paga siempre.

1. **Corto por diseño** — detalle pesado a `references/`. 2. **`description` = disparador**, con frases reales. 3. **Imperativo y terso.** 4. **No repitas contexto** que el SherpaX ya tiene. 5. **Tablas > prosa.** 6. **Referencia por ruta, no inline.** 7. **Un skill = un trabajo.** 8. **Determinista → script.** 9. **Cierra con la acción concreta.**

## Checklist de alta (copia y marca)
- [ ] F1 · Tipo + plugin destino (¿equipo o masters?) · Gate G0 · `description` con frases-disparador
- [ ] F2-F4 · Corrido con `/sx-publicador`: sync a fuente · validación PASS · bump · push confirmado · CI verde
- [ ] Registrado en registry + dashboard · viejo retirado (repo + cachés) · verificado en sesión nueva

## Anti-patrones (lo que rompe el sistema)
- ❌ Marketplace/plugins **dentro del vault** → la sync los corrompe.
- ❌ Editar el caché `.remote-plugins/` a mano.
- ❌ Subir el zip del marketplace al instalador de UN plugin ("Found 2 plugin.json").
- ❌ Descomprimir plugins en Google Drive (mutila dotfolders).
- ❌ Olvidar el bump de `version` → el equipo no recibe nada.
- ❌ Renombrar sin retirar el viejo → dos versiones corriendo.
- ❌ Publicar maestros /sx- al marketplace del equipo → rompe la admin-exclusividad.
- ❌ Push sin validación PASS → plugin roto distribuido a todo el equipo en minutos.
- ❌ Olvidar registrar en el banco.

*Glosario completo de términos: ver `SOP-EL-SkillsAlta-v02` §Glosario (sigue vigente).*

## CHANGELOG
| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-06-18 | Creación. 7 pasos + checklist + anti-patrones. Asumía marketplace dentro del vault. |
| v02 | 2026-07-07 | Reescritura en 4 fases. Corrección raíz: marketplace FUERA del vault. Glosario. |
| v03 | 2026-07-11 | **Automatización:** fases 2-4 corren con `/sx-publicador` (valida, bump, push con confirmación). Capítulo **Maestros /sx-** (admin-exclusivos, canal de distribución pendiente L3 — recomendación repo separado). Protocolo de **renombrados** (caso fabricador). Fabricadores actualizados en F1 (usherpax + directorx). Ratificación Victor L3+. |