---
type: MPB
asset_id: MPB-EL-SkillsPlaybook-v01
version: v01
status: Draft
owner: Victor Heredia
sherpa_owner: Jay
ratificador: Victor Heredia (L3+)
fecha_creacion: 2026-06-17
fecha_ultima_actualizacion: 2026-06-17
intellbank: IB-EL-EmpowerLabs
subbank: CP-EL-Control-Planes
proposito: Playbook interno — qué son las skills, cómo se generan, y cómo usarlas en 3 niveles
relacionados:
  - CP-EL-SkillsRegistry-v01 (qué tenemos)
  - PLAN-EL-UltraSherpaX-v01 (cómo se potencian)
tags: [MPB, playbook, skills, skill-creator, worx, bmf, formacion]
---

# MasterPlaybook · Skills en EmpowerLabs
## Qué son, cómo se generan, y cómo dominarlas en 3 niveles

> **Para quién:** todo el equipo EmpowerLabs que opera bajo WORX. Léelo una vez completo;
> vuelve a la sección de tu nivel cuando vayas a crear o mejorar una skill.

---

## 1. Qué es una skill (y qué no)

Una **skill** es una capacidad empaquetada que el SherpaX puede invocar: un conjunto de
instrucciones (y a veces scripts y archivos de referencia) que se cargan **bajo demanda**
cuando la situación la dispara. No es un prompt suelto ni un documento — es una unidad
reutilizable, con nombre, que vive en un plugin y se activa sola por su descripción.

**La distinción clave:**

| | Skill | Comando (slash) | Documento del vault |
|---|---|---|---|
| Se invoca | Sola, por contexto/descripción | El usuario escribe `/nombre` | El usuario lo abre/lee |
| Contiene | Instrucciones + scripts + refs | Una instrucción de tarea | Conocimiento estable |
| Vive en | Plugin (`skills/`) | Plugin (`commands/`) | IntelliBank |

**Anatomía mínima de una skill** (carpeta):
- `SKILL.md` — el corazón. Frontmatter (`name`, `description`) + las instrucciones.
- `references/` *(opcional)* — material que la skill lee según necesite (no se carga de entrada).
- `scripts/` *(opcional)* — código ejecutable que la skill corre.

**El campo más importante es `description`.** Es lo único que el modelo ve para decidir si
activar la skill. Si está mal escrita, la skill nunca se dispara — o se dispara cuando no debe.

---

## 2. Cómo se generan (el flujo en EmpowerLabs)

> **Procedimiento operativo paso a paso:** este playbook explica el *concepto*. Para el
> *cómo* end-to-end (alta + plugin + versión + publicar + registrar + verificar), usa el
> [[SOP-EL-SkillsAlta-v01]].

Usamos la skill `skill-creator` para crear, editar y evaluar skills. El flujo canónico:

1. **Detectar el patrón.** Una tarea que repites ≥3 veces con la misma estructura es candidata a skill. (Si es de la operación, también documenta el caso con `labpraxis-case-documenter`.)
2. **Definir el disparador.** ¿Qué dirá el usuario cuando necesite esto? Esas frases son la base de la `description`.
3. **Escribir el `SKILL.md`.** Instrucciones claras, en segunda persona ("Cuando el usuario… haz…"). Mover el material extenso a `references/` para mantenerlo liviano.
4. **Nombrar bajo BMF si es propia.** Naming canónico, owner, versión. Registrar en [[CP-EL-SkillsRegistry-v01]].
5. **Probar en seco.** Correr casos reales; verificar que dispara cuando debe y no cuando no debe.
6. **Ratificar y publicar.** Tripleta (Owner + Sherpa + Ratificador). Empaquetar en el plugin y distribuir por el marketplace privado de EL.

> **Gate G0 (Vault-First):** antes de crear una skill, consulta el registry — quizá ya existe una que cubre el caso, o una de terceros que puedes envolver.

---

## 3. Consejos por nivel

### 3.1 Básico — usar bien lo que ya existe

- **Arranca siempre con `/arrancaroom`.** Sin contexto WORX cargado, cualquier skill rinde a medias.
- **Deja que disparen solas.** No tienes que "llamar" a la mayoría de skills; descríbele al SherpaX lo que quieres en lenguaje natural y la skill correcta se activa.
- **Una tarea, una skill.** Si pides tres cosas a la vez, ayuda nombrar la que importa ("resúmeme esto" → `sage-summariser`).
- **Confía en el registry.** ¿No sabes qué hay? Abre [[CP-EL-SkillsRegistry-v01]] o corre `/wx-listaskills`.
- **Da contexto, no solo la orden.** "Hazme una oferta" rinde poco; "hazme una oferta para CEOs LATAM de $500K" dispara mejor y personaliza.

### 3.2 Intermedio — encadenar y ubicar

- **Encadena skills.** Destila una fuente con `ana-source-analyzer` → guarda el aprendizaje → genera el entregable. El valor está en la secuencia, no en la skill suelta.
- **Distingue propia vs. tercero.** Las de terceros (AI Specialists) son shells genéricos: buenos para arrancar, planos en cognición. Sábelo y ajusta expectativas.
- **Cuida naming y ubicación.** Todo lo que una skill escriba al vault debe cumplir BMF + ir al IntelliBank correcto. Si algo queda volando, `vault-orphan-rescue`.
- **Mantén el registry vivo.** Cada skill nueva entra al registry; cierre de semana se verifica (`weekly-sync` + `bmf-registry-updater`).
- **Escribe descripciones que disparen.** Si una skill propia no se activa, casi siempre es la `description`: agrega las frases reales que el usuario diría.

### 3.3 Avanzado — crear y potenciar

- **De patrón a skill.** Formaliza con `skill-creator` cualquier flujo que repitas. La regla de 3 repeticiones es el umbral.
- **Liviano por diseño.** El `SKILL.md` se carga entero cuando dispara — manténlo corto y empuja el detalle a `references/` que solo se leen si hacen falta.
- **Fusiona shell × Brain Code = SVA.** El salto de potencia: un especialista genérico animado por una cognición destilada. Es la base de **UltraSherpaX** — ver [[PLAN-EL-UltraSherpaX-v01]] y el prototipo `SVA-EL-Titan-BusinessOffer-v01`.
- **Versiona y mide.** Sube `version` en cada cambio; usa `skill-creator` para evaluar disparo y desempeño antes de publicar.
- **Empaqueta y distribuye.** Skills propias → plugin → marketplace privado de EL. Bump de versión + `git push` + el equipo actualiza.
- **Gobierna la frontera.** Una skill propia que envuelve a una de terceros debe declarar qué hereda y qué añade, para no duplicar ni chocar nombres.

---

## 4. Errores comunes (anti-patrones)

- **Skill que nunca dispara** → `description` pobre. Arréglala con frases-disparador reales.
- **Skill que dispara de más** → `description` demasiado amplia. Acótala.
- **`SKILL.md` gigante** → mueve material a `references/`.
- **Escribir al vault sin naming/ubicación** → viola WORX. Valida antes de escribir.
- **Reinventar lo que ya existe** → consulta el registry primero (Gate G0).

---

## 5. Skills, Plugins y Comandos — la estructura

### Los tres conceptos (no confundirlos)
- **Plugin** = la **caja** que instalas. Agrupa comandos + skills + su manifiesto. Ej: `worx-empowerlabs`.
- **Comando** (`/nombre`) = una acción que **TÚ** disparas escribiendo `/nombre`. Vive en `commands/`. Ej: `/wx-arrancaroom`.
- **Skill** = una capacidad que **dispara sola** cuando tu mensaje coincide con su `description`. Vive en `skills/`. Ej: `wx-buzon`.

> **Regla de dedo:** *comando = ritual que inicias tú · skill = capacidad que salta sola por contexto.* `/wx-arrancaroom` lo escribes; `wx-buzon` dispara con "¿tengo mensajes?".

### 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 (frontmatter `description:` + cuerpo)
├── skills/
│   └── <slug>/
│       ├── SKILL.md       ← frontmatter (name + description) + instrucciones
│       └── references/    ← opcional: detalle pesado, se lee SOLO si hace falta
└── README.md
```
Reglas de estructura:
- Solo `plugin.json` va dentro de `.claude-plugin/`. `commands/` y `skills/` van en la **raíz** del plugin, no anidados.
- El plugin **NUNCA** vive dentro del vault (la sync mutila los dotfolders). Vive en el **repo git** del marketplace.
- Nombres propios con prefijo: **`/wx-`** (producto WORX, portable a clientes) o **`/sk-`** (interno EL). Así se distinguen de los de terceros.

### Marketplace vs Plugin vs Banco (para no confundir)
- **Marketplace** = la "tienda" (repo git) que agrupa VARIOS plugins. `worx-empowerlabs` es UN plugin dentro del marketplace `empowerlabs`.
- **Banco / registry** = el inventario (`CP-EL-SkillsRegistry`) de qué skills existen. Vive en el vault. No es el marketplace.

---

## 6. Escribir skills eficientes en tokens

El `SKILL.md` se carga **entero** cada vez que la skill dispara — cada línea cuesta tokens en **cada** uso. Escribe para eficiencia:

1. **Corto por diseño.** Mantén el `SKILL.md` chico. El detalle pesado va en `references/` (se lee solo cuando hace falta), no en el cuerpo.
2. **La `description` es el disparador, no un resumen.** Precisa, con las frases reales que diría el usuario. No prosa larga.
3. **Imperativo y terso.** "Haz X" > "Deberías considerar hacer X". Cero relleno.
4. **No repitas contexto que el SherpaX ya tiene** (reglas WORX globales, identidad). Referéncialas, no las copies.
5. **Tablas y bullets > prosa.** Más denso y más escaneable.
6. **Referencia por ruta, no inline.** "Lee `X-v01.md`" en vez de pegar su contenido.
7. **Un skill = un trabajo.** No metas 3 capacidades en una (infla la carga en cada disparo). Ej: el buzón NO va dentro del skill de contexto.
8. **Trabajo determinista → script.** Apunta a un `.js`/`.py` en vez de describir pasos que el modelo re-ejecuta.
9. **Cierra con la acción concreta**, no con reflexión abierta.

> **Regla mental:** cada palabra en el `SKILL.md` se paga en **cada** invocación; cada palabra en `references/` se paga **solo cuando se lee**. Pon en el cuerpo lo que siempre se necesita; el resto, en `references/`.

## CHANGELOG
| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-06-17 | Creación. Qué son las skills, flujo de generación en EL, consejos básico/intermedio/avanzado, anti-patrones. |