---
type: GUI
asset_id: GUI-EL-Plugins-ActualizarRepos-v01
version: v01
status: Para difundir al equipo
owner: Victor Heredia
sherpa_owner: Jay
ratificador: Victor Heredia (L3+)
fecha_creacion: 2026-07-11
fecha_ultima_actualizacion: 2026-07-11
intellbank: IB-EL-EmpowerLabs
subbank: EQ-EL-Equipo
proposito: Guía práctica para que 2-3 miembros del equipo puedan actualizar los marketplaces, plugins y skills en los repos de GitHub de EmpowerlabsLLC — acceso, autenticación, flujo de publicación sin pisarse y sincronización. Deriva del SOP maestro y baja a lo operativo del día a día del equipo.
deriva_de: SOP-EL-SkillsAlta-v03 (ciclo de vida completo · owner-level)
relacionados:
  - SOP-EL-SkillsAlta-v03 (el ciclo de vida canónico crear/guardar/compartir/mantener)
  - SPEC-EL-WORX-GitMarketplace-AutoUpdate-v01 (infra git + auto-update + CI)
  - GUI-EL-FixSkills-ProcesoEquipo-v01 (limpieza única de cachés viejos)
  - TP-EL-PluginMarketplace-Handoff-v01 (handoff de publicación al equipo)
  - SX-MastersPack/sx-publicador (el maestro que automatiza fases 2-4)
tags: [GUI, equipo, plugins, marketplace, skills, github, git, colaboracion, publicar, sincronizar]
---

# Cómo actualizamos los marketplaces, plugins y skills en GitHub
## Guía de equipo — de un cambio local a que todos lo reciban

> **Para quién:** los 2-3 miembros que van a publicar cambios a los plugins.
> **Qué resuelve:** cómo tener acceso, autenticarse, subir un cambio sin chocar con otro,
> y cómo lo reciben todos los demás.
> **Referencia madre:** `SOP-EL-SkillsAlta-v03` (el ciclo completo). Esta guía es la bajada operativa.

---

## Las 3 reglas raíz (no negociables)

1. **El repo git vive FUERA del vault Intellibanks.** Nunca dentro: la sync mutila los archivos ocultos (`.claude-plugin` → `archivo.claude-plugin`, `plugin.json` → `plugin_json.md`) y rompe los plugins. Clona en `~/dev/`.
2. **Se edita la FUENTE (el repo git), nunca el caché instalado** (`~/.claude/plugins/…`). Editar el caché rompe el descubrimiento de comandos.
3. **Bump de versión OBLIGATORIO** en el `plugin.json` de cada plugin que cambies. Sin bump, el equipo **no recibe nada** — el auto-update se dispara por el número de versión.

---

## Los dos repos (no los confundas)

| Repo | Marketplace | Contenido | Quién publica | Visibilidad |
|---|---|---|---|---|
| **`EmpowerlabsLLC/empowerlabs-plugins`** | `empowerlabs` | 5 plugins del equipo (`worx-core`, `worx-empowerlabs`, `worx-wikix`, `worx-ultrasherpas`, `worx-governance`) | El equipo (2-3 miembros con Write) | **Privado** |
| **`EmpowerlabsLLC/empowerlabs-masters`** | `empowerlabs-masters` | Plugin único `worx-masters` — maestros `/sx-` **admin-exclusivos** | **Solo Victor** | **Privado** |

> Los maestros `/sx-` **jamás** van al repo del equipo. Son admin-exclusivos por canon.

---

## PARTE A — Acceso (una sola vez, por miembro)

**Dato clave:** el repo del equipo lo creó **Alex** (infra). El org `EmpowerlabsLLC` está en **plan Free**, donde **no hay Teams granulares ni branch protection en repos privados** — el acceso se da agregando a cada persona como **colaborador directo** del repo.

Como el org es Free y la mayoría somos **miembros** (no owners), **quien agrega gente es el owner del org o el admin del repo (Alex).**

**Alex (o un org owner) hace, por cada miembro:**
1. Repo `empowerlabs-plugins` → **Settings** → **Collaborators and teams** → **Add people**.
2. Rol **Write** (con Write basta para push; no hace falta Admin).
3. El invitado **acepta** la invitación (le llega por correo / GitHub).

> ¿Quieres saber si ya tienes acceso? En tu terminal:
> `gh api repos/EmpowerlabsLLC/empowerlabs-plugins --jq .permissions`
> Debe decir `"push": true`.

---

## PARTE B — Setup de tu máquina (una sola vez, por miembro)

```bash
# 1) Autenticarte como TÚ (tu cuenta de GitHub)
gh auth login          # GitHub.com → HTTPS → Login with a web browser → autorizar SSO de EmpowerlabsLLC
gh auth setup-git      # que git push use la credencial de gh

# 2) Si vas a tocar archivos de CI (.github/workflows/), agrega el scope workflow:
gh auth refresh -h github.com -s workflow

# 3) Token para el auto-update del marketplace PRIVADO (agrégalo a tu ~/.zshrc):
echo 'export GITHUB_TOKEN="$(gh auth token)"' >> ~/.zshrc
source ~/.zshrc

# 4) Clona el repo (una vez) — SIEMPRE fuera del vault:
git clone https://github.com/EmpowerlabsLLC/empowerlabs-plugins.git ~/dev/empowerlabs-plugins
```

> **Nunca** pegues un token en crudo en la terminal ni en un chat. Si necesitas un PAT, créalo en `github.com/settings/tokens` con scopes `repo` + `workflow` y autorízalo para el SSO del org.

---

## PARTE C — Dónde vive cada cosa

Anatomía de cada plugin dentro del repo:
```
{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)
└── README.md
.claude-plugin/marketplace.json  ← (en la raíz del repo) lista los 5 plugins
```

**¿Dónde va un skill nuevo?** En el plugin que corresponde (tabla F1.3 del SOP):

| Si es… | Plugin destino |
|---|---|
| Operación WORX del día a día | `worx-empowerlabs` |
| Producto WikiX | `worx-wikix` |
| Cognición / súper asistente (SVA) | `worx-ultrasherpas` |
| Gobernanza interna (`/sk-`) | `worx-governance` |
| Base org-agnóstica (individual) | `worx-core` |
| Maestro `/sx-` (admin) | **NO aquí** → repo `empowerlabs-masters` |

---

## PARTE D — Publicar un cambio

### Camino por defecto: `/sx-publicador`
Invoca **`/sx-publicador`** con lo que cambió. Automatiza: sync fuente → repo · **valida** (1 `plugin.json` por plugin, JSON válidos, cero `archivo.*`/`*_json.md`) · **bump SemVer** · commit `{plugin}@{version}: {cambio}` · **pide confirmación humana** antes del push · verifica CI. Es gobernanza **L2**.

### Camino manual (respaldo, y el correcto cuando somos varios)
Con 2-3 personas en el mismo repo, lo crítico es **no chocar en `plugin.json` y `marketplace.json`**. Usa ramas + PR:

```bash
cd ~/dev/empowerlabs-plugins
git pull                              # 1) SIEMPRE trae lo último primero
git checkout -b sk-nuevo-skill        # 2) rama por cambio, nunca directo en main

# 3) agrega/edita el skill en el plugin correcto, p.ej.:
#    worx-governance/skills/<nuevo>/SKILL.md

# 4) BUMP de versión en worx-governance/.claude-plugin/plugin.json  (0.2.0 → 0.3.0)

git add .
git commit -m "worx-governance@0.3.0: alta sk-nuevo-skill"
git push -u origin sk-nuevo-skill     # 5) sube la rama
# 6) Abre un PR en GitHub → revisión → Merge a main
```

### Reglas de convivencia (2-3 personas)
- **Pull antes de empezar**, siempre.
- **Una persona toca un plugin a la vez.** Dos bumps al mismo plugin/misma versión = conflicto.
- **Rama + PR**, no push directo a `main` (el org Free no obliga revisión, así que es por disciplina).
- **Coordinen el número de versión** del plugin que ambos tocan.
- El commit dice qué plugin y a qué versión: `{plugin}@{version}: {cambio}`.

> **Ojo con el CI:** subir/editar archivos en `.github/workflows/` requiere el scope **`workflow`** en tu token (Parte B paso 2). Para editar solo SKILL.md/commands no hace falta.

---

## PARTE E — Cómo lo reciben todos (sincronizar)

Cada máquina tiene el marketplace `empowerlabs` con **`autoUpdate: true`** + **`GITHUB_TOKEN`** en el entorno.

1. Al **reiniciar** Claude Code (y periódicamente), hace `git pull` del repo.
2. Si la versión del `plugin.json` subió, baja los cambios al caché.
3. Un **reinicio** carga los skills nuevos/actualizados.

**Sincronización manual** (sin esperar):
```bash
claude plugin update worx-governance@empowerlabs   # el plugin que cambió
# luego reinicia Claude Code
```

**Si alguien "no recibe la actualización":** casi siempre es (1) no reinició · (2) **no bumpearon la versión** · (3) le falta el **`GITHUB_TOKEN`** (repo privado no sincroniza sin él) · (4) no aceptó la invitación de colaborador.

---

## Anti-patrones (lo que rompe el sistema)
- ❌ Marketplace/plugins **dentro del vault** → la sync los corrompe.
- ❌ Editar el caché instalado (`~/.claude/plugins/…`) a mano.
- ❌ **Olvidar el bump** de versión → el equipo no recibe nada.
- ❌ Push directo a `main` sin pull previo → conflictos y pisadas.
- ❌ Instalar skills por **ZIP suelto** mandado por chat. Todo viene del marketplace git.
- ❌ Pegar un **token en crudo** en terminal o chat (queda en el historial).
- ❌ Publicar maestros `/sx-` al repo del equipo → rompe la admin-exclusividad.
- ❌ Push sin validación PASS → plugin roto distribuido a todos en minutos.

---

## Checklist rápido (copia y marca)
- [ ] Tengo **Write** en `empowerlabs-plugins` (`gh api … --jq .permissions` → `push:true`)
- [ ] `gh auth login` + `setup-git` + (`-s workflow` si toco CI) + `GITHUB_TOKEN` en `~/.zshrc`
- [ ] Clonado en `~/dev/` (fuera del vault)
- [ ] `git pull` → rama → edito skill en el plugin correcto
- [ ] **Bump** del `plugin.json` · commit `{plugin}@{version}: {cambio}`
- [ ] Push de la rama → PR → merge a `main` · CI verde
- [ ] Verifico `claude plugin update {plugin}@empowerlabs` + reinicio

---

## Ficha del activo
- **Owner:** Victor Heredia · **Sherpa:** Jay · **Ratificador:** Victor Heredia (L3+)
- **Ubicación canónica:** `IB-EL-EmpowerLabs/EQ-EL-Equipo/GUI-EL-Plugins-ActualizarRepos-v01.md`
- **Deriva de:** `SOP-EL-SkillsAlta-v03` · **Infra:** `SPEC-EL-WORX-GitMarketplace-AutoUpdate-v01`

## CHANGELOG
| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-07-11 | Creación. Guía de equipo para actualizar los repos de marketplaces/plugins/skills en GitHub: acceso (org Free, colaboradores directos vía Alex), setup por miembro (auth + token + clone), dónde vive cada cosa, publicación (/sx-publicador + manual con ramas/PR), reglas de convivencia 2-3 personas, sincronización y troubleshooting. Deriva de SOP-EL-SkillsAlta-v03. |