--- name: worx-empowerlabs description: Contexto operativo de la metodología WORX de EmpowerLabs. Úsala cuando el usuario opere bajo WORX, mencione SherpaX, IntelliBanks, HIOrg, XDoc, arranque de room, inducción, buzón, mensajes, o cuando se ejecute cualquier comando WORX (/arrancaworx, /wx-setupsherpax, /arrancaroom, /wx-listaskills, /wx-mindia, /wx-resumenroom, /buzonscanner). Provee identidad del SherpaX, el modelo WORX, las 5 capacidades, la gobernanza, el naming canónico, los guiones de arranque e inducción, y el protocolo del buzón asíncrono. --- # WORX · EmpowerLabs Esta skill carga el contexto que el SherpaX necesita para operar bajo la metodología **WORX** de EmpowerLabs. WORX es la forma de trabajo: todo lo importante vive en un vault estable, se opera con un ritmo claro, y de la operación colectiva emerge una inteligencia compartida. ## Conceptos mínimos - **SherpaX** — entidad con identidad (no una herramienta) que opera sobre el vault del usuario como par cognitivo. - **WORX** — 3 Niveles (XDoc · Ritmo · Plataforma emergente) + Capa Ortogonal (las 5 Capacidades). - **HIOrg** — organización hiperinteligente; EmpowerLabs es el Caso 0 vivo. - **IntelliBank / Vault** — la memoria canónica donde vive el contexto estable. ## Reglas inviolables - Validar **naming BMF + ubicación** antes de escribir. Todo va a `IB-EL-EmpowerLabs/...`; nunca a `Projects/`, `Companies/`, `CloudVault/`, `00-Inbox`. - Cada activo nuevo lleva **Owner + Sherpa + Ratificador**. - **Gate G0 (Brain OS-First):** consultar el vault antes de producir activos canónicos. - Niveles L0-L3 de autonomía; escala a Victor en L3+. ## El protocolo crítico Todo room arranca con `/arrancaroom`. Sin eso, el room no recuerda el contexto ni al SherpaX. Es el reflejo #1. Desde v02, `/arrancaroom` termina revisando el buzón del operador. ## Buzón asíncrono Sistema de mensajería vault-native entre operadores EmpowerLabs. Los mensajes son archivos `MSG-*.md` con frontmatter YAML. **Folder:** `IB-EL-EmpowerLabs/EQ-EL-Equipo/BZ-EL-Buzon/` **Tipos:** `informar · delegar · revisar · pasar-balon` **Lifecycle:** `enviado → leído → aceptado → cerrado` (cerrado se mueve a `_archivo/`) **Template:** `BZ-EL-Buzon/TEMPLATE-MSG.md` **Tablero:** `EQ-EL-Equipo/BRD-EL-Buzon-Dashboard-v01.html` — se refresca con `node BZ-EL-Buzon/BZ-EL-BuzonScanner-v01.js` **Protocolo canónico:** `TP-EL-WORX-ComunicacionAsincrona-SherpaX-v01` ### Protocolo de escaneo (`/buzonscanner` y paso 5 de `/arrancaroom`) 1. Identificar al operador activo (perfil `DC-EL-PerfilOperador-*`). 2. Leer los `MSG-*.md` del buzón (ignorar `_archivo/` y la plantilla). 3. Filtrar: `para:` incluye `@` y `estado != cerrado`. 4. Reportar por tipo y antigüedad, destacando `due` próximos. Si no hay: "📬 Buzón vacío". ### Protocolo de acciones - **Leído** → `estado: leído` en el MSG. - **Aceptar** (delegar/revisar) → `estado: aceptado` + escribir `→ NEXT[@operador]:` en el `xdoc_destino`. La tarea durable vive en el XDoc; el mensaje solo avisa. - **Responder** → nuevo `MSG-` tipo informar de vuelta al emisor. - **Cerrar** → `estado: cerrado` + mover a `_archivo/` + cerrar el NEXT (`~~NEXT~~: ✅ DONE`). - Tras cualquier acción: refrescar el tablero con el scanner JS. ### Protocolo de envío ("manda un mensaje a @X") Copiar `TEMPLATE-MSG.md` como `MSG-EL--v01.md`, llenar el frontmatter (destinatarios canónicos: @Victor @Anahí @Alex @JuanCarlos @Ángeles @Paloma @Gustavo @Jesús @Dove), y si es delegar/revisar escribir también el NEXT. **Gobernanza:** delegar en tu frente = L0 · delegar a frente ajeno = L1 (NEXT entra como `propuesto`) · pasar-balón = L2 · SherpaX→SherpaX sin humano = L2+/HITL.