Plugins empresariales de Claude — distribución y configuración

Esta nota documenta cómo se distribuyen y configuran los plugins de Wiedii en producción, y el modelo de dependencias entre plugins. La arquitectura/decisiones de fondo están en claude-wiedii-plugin; esta nota es la parte operativa (admin de IA, a cargo del TL).

TL;DR

Hay dos superficies y se distribuyen distinto: Claude Code (CLI + panel Code de Desktop) por managed settings; Cowork por zips de organización subidos al admin.
Los plugins Wiedii dependen de plugins oficiales de Anthropic. Esas dependencias se auto-instalan en Claude Code (verificado, CLI y Desktop), pero NO en Cowork (ahí se habilitan a mano).
Para que las dependencias resuelvan, los marketplaces destino deben estar registrados ANTES, y siempre con su nombre intrínseco (no un alias).
Preferir dependencias sobre enabledPlugins para garantizar instalación: enabledPlugins no instala en el CLI (solo en el panel Code de Desktop, y tras reinicio completo).

Las dos superficies

	Claude Code (CLI + panel Code de Desktop)	Cowork
Población	Desarrollo, y UI/UX de Diseño que opte por `wiedii-dev` (manejan la terminal)	Áreas no técnicas (Finanzas, Diseño, …)
Distribución	Managed settings (`extraKnownMarketplaces` + `enabledPlugins`) — zero-touch, lo despliega el TL	Zips de organización subidos en Admin → Plugins → Subir un archivo (uno por plugin)
Marketplace GitLab self-hosted	✅ soportado (`…git#stable`)	❌ el GUI no lo acepta → por eso los zips
Dependencias de plugin (`plugin.json`)	✅ auto-instalan (CLI y Desktop)	⚠️ no cascadean → habilitar a mano
`enabledPlugins`	⚠️ instala solo en Desktop (tras reinicio completo); en CLI puro NO instala, solo habilita lo ya presente	n/a

Audiencia por defecto, no muro de capacidad. "Desarrollo→Code / no-técnicos→Cowork" es una elección de distribución, no un límite técnico. Skills de conocimiento (council, lyra, convenciones) y MCP/conectores sirven en ambas superficies. Lo específico del entorno: skills que manejan herramientas locales (Playwright/Chrome, engram, codebase-memory-mcp) necesitan la máquina con esa herramienta, y los hooks son de Claude Code. Por eso wiedii-dev va por Code (donde el dev tiene su entorno local), pero sus skills de conocimiento podrían servir en Cowork si hiciera falta. Las herramientas tipo CLI local con instalador propio (Context7 ctx7 setup, codebase-memory-mcp codebase-memory-mcp install) son per-dev, no van en el plugin.

Claude Code — managed settings (zero-touch)

En Claude.ai → Admin → Claude Code → Managed settings, el TL pega una vez este bloque; aplica a Claude Code CLI y al panel Code de Desktop:

{
  "extraKnownMarketplaces": {
    "claude-wiedii-plugins": {
      "source": { "source": "git", "url": "https://gitlab.wiedii.co/wildcat/claude-wiedii-plugins.git", "ref": "stable" },
      "autoUpdate": true
    },
    "claude-plugins-official": {
      "source": { "source": "github", "repo": "anthropics/claude-plugins-official" },
      "autoUpdate": true
    }
  },
  "enabledPlugins": {
    "wiedii-core@claude-wiedii-plugins": true
  },
  "skillListingBudgetFraction": 0.03
}

Los 2 marketplaces son obligatorios (claude-wiedii-plugins + claude-plugins-official). Sin registrar el oficial, wiedii-dev falla al cargar ("dependency marketplace not added"). Ya no se registra knowledge-work-plugins (se descartaron productivity/engineering).

enabledPlugins lista solo wiedii-core — la base obligatoria para todas las áreas y cuentas. wiedii-dev queda registrado (por extraKnownMarketplaces) pero NO en enabledPlugins: es opt-in, lo instala quien trabaje en flujos de desarrollo (Desarrollo y UI/UX de Diseño) con /plugin install wiedii-dev@claude-wiedii-plugins. Sus oficiales + engram llegan por dependencia al instalar wiedii-dev.

skillListingBudgetFraction: 0.03 — para que las skills auto-disparen. Claude Code precarga las descripciones de todas las skills (así decide cuál usar) pero trunca el listado si excede el 1% del contexto (default). wiedii-core + wiedii-dev (~20 skills) + dependencias + skills de Anthropic superan ese 1%; una skill cuya descripción se dropea deja de auto-disparar (solo se invoca con /skill). Subirlo a 3% deja espacio para todo el set (cuesta unos miles de tokens/sesión). Por el bug #57941 (baseline fijo ~200k) no bajar de 0.02–0.03. No hay forma de "fijar" una skill — los drops son por uso. Per-dev: el aviso "Skill listing will be truncated" o /doctor lo muestran; /skills desactiva las que no se usen.

Si parte de no-Desarrollo también usa Claude Code, el TL puede acotar estos managed settings al grupo de ingeniería (vía MDM).

Context7 — per-dev (NO va en el plugin). Se sacó del .mcp.json de wiedii-dev. Cada dev lo activa con bunx ctx7 setup (OAuth): escribe la config del MCP con su key en ~/.claude.json (literal, sin depender de env vars) e instala rule+skill. Cubre Claude Code (CLI + panel Code de Desktop) (comparten ~/.claude.json). Cowork es otra superficie (no lee ~/.claude.json) → conector Context7 en claude.ai → Settings → Connectors. Motivo de sacarlo del plugin: sin MDM una key compartida no es desplegable, y ctx7 setup ya cubre per-dev sin duplicar. (Recordatorio del gotcha general: un ${VAR} en headers de un MCP se resuelve del entorno del SO, no del env de managed settings — por eso una key compartida en managed settings no habría servido. En cambio los env de security-guidance —ENABLE_*, SECURITY_GUIDANCE_DISABLE— sí van en el env de managed settings, porque el plugin los lee como env de runtime.)

Modelo de dependencias entre plugins

Los plugins Wiedii declaran dependencias en su plugin.json — el mecanismo robusto para garantizar instalación (auto-instala en CLI y Desktop, a diferencia de enabledPlugins):

wiedii-dev → wiedii-core (intra-marketplace, la base) + claude-code-setup, feature-dev, frontend-design, claude-md-management, security-guidance (de claude-plugins-official) y engram (intra-marketplace, vendorizado en claude-wiedii-plugins)
wiedii-finance / wiedii-design → wiedii-core (intra-marketplace) — para que core se instale también en la terminal limpia al instalar el plugin de área
wiedii-core → sin dependencias propias (se evaluaron productivity/engineering de «Knowledge Work» y se descartaron: productivity solapa con engram y ambos traían MCP de Calendar/Gmail que erroran para todos)

Para que Claude Code resuelva y auto-instale las cross-marketplace, hacen falta tres cosas (todas ya aplicadas en el repo):

Campo marketplace en cada dependencia cross-marketplace. Una dependencia "pelada" { "name": "feature-dev" } se busca dentro del propio marketplace (claude-wiedii-plugins). Para cross: { "name": "feature-dev", "marketplace": "claude-plugins-official" }. (Las intra-marketplace, como engram, van sin campo marketplace.)
allowCrossMarketplaceDependenciesOn en el marketplace.json raíz: ["claude-plugins-official"]. Las dependencias cross-marketplace están bloqueadas por defecto.
Nombre INTRÍNSECO, no alias. El valor de marketplace, la allowlist, los @-refs de enabledPlugins y las claves de extraKnownMarketplaces deben usar el nombre que el marketplace declara en su propio marketplace.json — no un alias local. Reales: anthropics/claude-plugins-official → claude-plugins-official; anthropics/knowledge-work-plugins → knowledge-work-plugins. (Usar alias como anthropic-official rompe tanto la dependencia como feature-dev@anthropic-official.)

Prerequisito duro: las dependencias solo resuelven desde marketplaces ya registrados. Por eso TODO camino de instalación debe registrar claude-plugins-official antes de instalar.

Versiones mínimas de Claude Code: dependencias ≥ 2.1.110; cascada de activación ≥ 2.1.143; security-guidance ≥ 2.1.144.

Verificado (2026-06-11): con claude-plugins-official registrado, instalar wiedii-dev reporta "(+ N dependencies: …)" y las auto-instala/activa. ⚠️ Gotcha confirmado: un auto-update a una versión con deps nuevas NO las auto-instala (queda "failed to load"); /reload-plugins resuelve una dep por pasada (varias deps = varias recargas) — reiniciar Claude Code las resuelve de una.

Por qué dependencia y no `enabledPlugins`

enabledPlugins en managed settings no instala en el CLI (solo habilita lo ya presente — issue abierto de Anthropic); en el panel Code de Desktop sí instala, pero tras reinicio completo. Las dependencias instalan en ambas superficies. Por eso los oficiales de Desarrollo se declaran como dependencias de wiedii-dev, y wiedii-core se declara como dependencia de todos los plugins de equipo (wiedii-dev/finance/design) para que se instale en la terminal limpia, no solo se habilite. enabledPlugins queda como refuerzo de wiedii-core en Desktop.

Cowork — runbook del admin (paso a paso)

Cowork no acepta el marketplace GitLab self-hosted → el admin sube zips de organización (genéralos con mise run package-cowork; salen en dist/cowork-zips/). A Cowork solo van los plugins de áreas no técnicas: wiedii-core + wiedii-finance + wiedii-design. NO subas wiedii-dev ni engram — son de Desarrollo (se distribuyen por Claude Code).

Paso 1 — Subir los zips de Wiedii

Organization settings → Plugins → Add plugins → Upload a file (zip válido, < 50 MB):

wiedii-core.zip → Upload to a new marketplace → nombre del marketplace: claude-wiedii-plugins.
wiedii-finance.zip y wiedii-design.zip → añadir al marketplace existente claude-wiedii-plugins.

Subir un zip con el mismo nombre sobrescribe la versión anterior (así actualizas tras regenerar zips).

Paso 2 — Definir el acceso de cada plugin

Cada plugin tiene una preferencia de instalación (labels exactos de Cowork):

Opción	Qué hace
Required	Instalado para todos, sin opción de quitarlo
Installed by default	Instalado para todos (el usuario puede quitarlo)
Available for install	Aparece en el catálogo (Browse plugins), autoservicio
Not available	Oculto del catálogo

Sugerido: wiedii-core = Required (lo reciben todos); wiedii-finance / wiedii-design = Installed by default para su grupo (o Available for install si prefieres autoservicio).

Paso 3 — Verificar (no hay dependencias que habilitar)

Los plugins que van a Cowork (wiedii-core/wiedii-finance/wiedii-design) ya no tienen dependencias oficiales (se quitaron productivity/engineering), así que no hay nada extra que habilitar. Un usuario de Cowork debería ver activos wiedii-core + su plugin de área.

Recordatorio: Cowork no resuelve las dependencies de plugin.json desde los zips (a diferencia de Claude Code) — justamente por eso evitamos dependencias en los plugins que van a Cowork. La dep intra-marketplace a wiedii-core se ignora en Cowork (core se sube aparte como Required); un plugin nuevo de Cowork debe seguir sin dependencias cross-marketplace/oficiales. Si en el futuro un plugin de Cowork necesitara un acompañante, habría que habilitarlo a mano desde el panel Customize.

Cómo enviar una actualización a Cowork

Cowork no tiene canal git ni auto-update (a diferencia de Claude Code): la actualización es manual. (1) Promueve stable (el zip se arma desde stable por defecto); (2) mise run package-cowork → dist/cowork-zips/; (3) en Organization settings → Plugins vuelve a subir los zips no técnicos que cambiaron — mismo nombre = sobrescribe la versión anterior; (4) el acceso por plugin se conserva. wiedii-dev/engram (y todo lo que tenga MCP stdio) no van a Cowork.

Plugins oficiales de Anthropic (y cómo llegan)

Host-agnósticos, sin vendoring (los mantiene Anthropic). Todos son de Desarrollo → no van en core. Los cuatro son dependencias de wiedii-dev → se auto-instalan al instalar wiedii-dev (CLI y Desktop):

feature-dev — flujo de 7 fases explorar→diseñar→implementar→auto-review con agentes en paralelo (complementa /new-feature y /review-pr, no impone branching/testing).
frontend-design — UI de alta calidad; se auto-activa en frontend. Disponible para quien instale wiedii-dev (Desarrollo y UI/UX de Diseño).
claude-md-management — auditar y mantener los CLAUDE.md.
security-guidance — revisión de seguridad del código generado (avisos regex + review LLM del diff + review en git commit: inyección/XSS/SSRF/secrets/IDOR). Su costo de tokens se afina o se apaga por env (en el mismo bloque de managed settings): ENABLE_PATTERN_RULES, ENABLE_CODE_SECURITY_REVIEW (0 = solo avisos regex, gratis), ENABLE_COMMIT_REVIEW, o SECURITY_GUIDANCE_DISABLE=1 (kill-switch). Requiere Claude Code ≥ 2.1.144 + Python.

El oficial code-review se descartó: depende de GitHub/gh y Wiedii usa GitLab — la revisión de MRs la cubre /review-pr vía glab. Regla vendorizar vs registrar (reconocido → su marketplace; comunidad → vendorizar) en vendor/README.md del repo.

Relacionados

claude-wiedii-plugin — arquitectura/decisiones del marketplace (CLI vs org admin, monorepo, canales main/stable).
prerequisitos-plugins-claude — qué debe estar instalado en la máquina (MCPs, binarios, versión mínima de Claude Code).
guia-nuevo-dev — onboarding paso a paso.
auditoria-uso-claude — auditoría de uso/asientos de Claude (pendiente de evaluar).

TL;DR​

Las dos superficies​

Claude Code — managed settings (zero-touch)​

Modelo de dependencias entre plugins​

Por qué dependencia y no enabledPlugins​

Cowork — runbook del admin (paso a paso)​

Paso 1 — Subir los zips de Wiedii​

Paso 2 — Definir el acceso de cada plugin​

Paso 3 — Verificar (no hay dependencias que habilitar)​

Cómo enviar una actualización a Cowork​

Plugins oficiales de Anthropic (y cómo llegan)​

Relacionados​