Catálogo de plugins Wiedii — qué tienes disponible

Inventario exhaustivo de capacidades: por cada skill, comando, MCP y plugin acompañante → qué hace · cómo se activa o invoca · ejemplo · limitaciones · aclaraciones. Cómo se instala (managed settings / Cowork) está en plugins-empresariales-distribucion-configuracion; la arquitectura en claude-wiedii-plugin; los binarios de host en prerequisitos-plugins-claude.

Cada persona recibe wiedii-core (base de toda la empresa) + el plugin de su área. Conceptos:

• Skills → se activan solas según el contexto (no se invocan). Trabajas normal y Claude aplica la convención correcta.
• Comandos → los llamas tú con /<nombre> (admiten argumentos).
• MCP → herramientas extra que Claude usa por ti (navegador, etc.).
• Plugins acompañantes → algunos plugins auto-instalan otros como dependencia.

Leyenda de origen: 🟦 Wiedii (sincronizado del vault) · 🟪 capacidad propia o guardrail curado (autoreado en el repo, no del vault) · 📦 vendorizado (terceros, con crédito) · 🅰️ oficial de Anthropic (auto-instalado).

---

Parte A — USO (qué tienes y cómo usarlo)

A.1 · Todos (wiedii-core) — transversal a la empresa

Lo instala todo el mundo (Desarrollo, Finanzas, Diseño, Operaciones, RRHH…). council y lyra no son de código.

wiedii-core · skill · 🟦

• Qué hace: base de empresa — contexto de Wiedii, idioma de documentación, política de IA, manejo de información y gestión de proyectos.
• Cómo se activa: automática, en cualquier trabajo para Wiedii.
• Ejemplo: al pedir un documento, Claude responde en español por defecto (política Wiedii).
• Limitaciones: es política transversal, no técnica; lo específico de stack vive en wiedii-dev.
• Aclaraciones: es la línea base obligatoria; el resto de plugins la asumen.

council · skill · 🟪

• Qué hace: deliberación multi-perspectiva (DMAD) — 5 advisors con métodos de razonamiento distintos + peer-review anónimo + abogado del diablo + un chairman que sintetiza un veredicto. Todos los agentes corren en Opus.
• Cómo se invoca: lenguaje natural — "council this …", "run the council", "convene the council", "pressure-test this …", "stress-test this …", "war room this …". Flags: --quick, --confidence, --measure-diversity.
• Ejemplo: "council this — ¿reasignamos el presupuesto Q3 a growth?" · "pressure-test this rebrand antes de presentarlo al cliente".
• Limitaciones: caro por diseño (todo Opus, hasta ~12 llamadas) — úsalo bajo demanda, para decisiones donde equivocarse es costoso, no para todo.
• Aclaraciones: sirve a cualquier área (no solo código) y funciona en Claude Code y Cowork (ambos corren sub-agentes). El argument-hint menciona "MR/PR URL" solo como ejemplo.

lyra-prompt-optimizer · skill · 🟪

• Qué hace: transforma prompts vagos en prompts precisos con la metodología Lyra 4-D (Deconstruct, Diagnose, Develop, Deliver), para cualquier IA (ChatGPT, Claude, Gemini…).
• Cómo se invoca: lenguaje natural EN/ES — "Lyra", "mejora este prompt", "optimiza este prompt para ChatGPT", "ayúdame a escribir un prompt para…", "este prompt no funciona".
• Ejemplo: "mejora este prompt para pedirle a la IA un informe de ventas mensual".
• Limitaciones: optimiza el texto del prompt; no ejecuta la tarea del prompt.
• Aclaraciones: útil en cualquier área; también dispara si pegas un prompt rudimentario y pides mejores resultados.

wiedii-vault · skill · 🟪

• Qué hace: reglas para editar el vault de documentación de Wiedii (Obsidian) — el lifecycle estado (borrador→maduro→promovido→archivado), revertir una nota promovido a maduro al editarla, las meta-notas vigente que no cambian de estado, y cuándo entregar un briefing en vez de aplicar cambios en silencio.
• Cómo se activa: automática al crear/editar/mover notas del vault (por MCP de Obsidian o edición directa del repo wiedii-documentation).
• Ejemplo: al editar una nota promovido, Claude avisa que el cambio la revierte a maduro.
• Limitaciones: aplica solo al vault wiedii-documentation, no a docs de un proyecto.
• Aclaraciones: evita romper la taxonomía del vault y dejar notas huérfanas.

/feedback · comando · 🟪

• Qué hace: reporta un bug / idea / duda sobre cualquier plugin Wiedii → termina como issue en wildcat/claude-wiedii-plugins.
• Cómo se invoca: /feedback o /feedback <tu comentario>. Dos caminos automáticos:
  • Con glab (devs autenticados): crea el issue directo (muestra el borrador y pide confirmar).
  • Sin glab / sin cuenta de GitLab: abre el correo con un email pre-rellenado a innovadev@wiedii.co (un maintainer lo registra como issue).
• Ejemplo: /feedback el audit-project no detecta .cursor/ commiteado.
• Limitaciones: crear un issue en GitLab exige login → quien no tenga cuenta va por el camino de email. Nunca incluyas secretos ni datos de clientes.
• Aclaraciones: clasifica tipo + plugin en el título y adjunta contexto técnico (versión de Claude Code, canal, repo).

---

A.2 · Desarrollo (wiedii-dev)

Comandos (se invocan con /)

/new-feature · 🟦

• Qué hace: arranca una feature siguiendo el flujo Wiedii (branch + commits con wietoo + MR).
• Cómo se invoca: /new-feature [feature-name] [#squadlinx-id].
• Ejemplo: /new-feature exportar-csv #1234.
• Limitaciones: asume el Git Flow Wiedii — rama desde develop y MR hacia develop (no para repos de un solo main); commits firmados con GPG.
• Aclaraciones: delega los no-negociables a dev-conventions (no los repite). Cada commit lleva el footer closed #<id>.

/review-pr · 🟦

• Qué hace: revisa un Merge Request contra los estándares Wiedii (convenciones, Testing Trophy, seguridad, formato de commits) por 5 dimensiones (performance, seguridad, mantenibilidad, escalabilidad, buenas prácticas).
• Cómo se invoca: /review-pr [URL o número de MR] (sin argumento, revisa los cambios de la rama actual). Usa glab (GitLab).
• Ejemplo: /review-pr !87 · /review-pr https://gitlab.wiedii.co/grupo/proyecto/-/merge_requests/87.
• Limitaciones: no aprueba ni mergea (en Wiedii nadie mergea su propio MR); solo entrega la revisión. Requiere glab.
• Aclaraciones: etiqueta cada hallazgo por severidad (🔴 crítico / 🟡 importante / 🟢 recomendado) y difiere a las skills como fuente de cada regla (no inventa reglas).

/audit-project · 🟦

• Qué hace: audita el repo actual contra las convenciones de desarrollo Wiedii y reporta si cumple (archivos obligatorios, tooling, Docker, API, deps, tests, CI, whitelist de herramientas de IA…).
• Cómo se invoca: /audit-project [área a enfocar]. Reporte en español.
• Ejemplo: /audit-project (todo) · /audit-project docker.
• Limitaciones: solo lectura — no modifica el repo (al final ofrece abrir una rama/MR para arreglar los FAIL). No se conecta al vault: usa las skills sincronizadas como rúbrica.
• Aclaraciones: ante una regla que no puede confirmar, marca no verificado — requiere la skill <X> en vez de adivinar.

/sdd-new · 🟪

• Qué hace: arranca Spec-Driven Development — escribe un contrato spec revisable y para en un gate de aprobación antes de codear, luego implementa bajo TDD.
• Cómo se invoca: /sdd-new [descripción de la feature/cambio].
• Ejemplo: /sdd-new añadir paginación al listado de facturas.
• Limitaciones: no para fixes pequeños o mecánicos (esos van por git-workflow); el gate es de parada obligatoria (no escribe código antes del "apruebo").
• Aclaraciones: es un punto de entrada fino; la metodología vive en la skill spec-driven-development. Los artefactos se guardan en .sdd/<slug>/.

Skills de convención (se activan solas por contexto — no se invocan)

Skill	Qué hace	Qué la dispara (automático)	Origen
dev-conventions	Políticas de desarrollo transversales a todos los stacks (hub, incl. manejo de errores)	escribir código, setup de repo, commits, Dockerfiles, elegir deps, instalar tools	🟦
design-principles	SOLID/DRY/KISS (qué son y qué NO) + tipado y modelado de dominio (value objects, dinero entero, DTO≠entidad)	diseñar/revisar código o arquitectura, decidir una abstracción, modelar tipos	🟦
dependency-selection	Cuándo se justifica una librería + health-check de 6 puntos + red flags de supply-chain	añadir, elegir o auditar una dependencia	🟦
testing-strategy	Testing Trophy: qué tipo de test escribir, frameworks por stack, property-based/contract	escribir tests o diseñar la estrategia de pruebas	🟦
wiedii-tooling	Modelo Homebrew + mise (3 niveles), mise.toml, hooks lefthook de wiedii-configs	configurar mise.toml, añadir un tool, setup/debug de hooks	🟦
git-workflow	Conventional Commits + emoji obligatorio + footer closed #<id> + ramas Git Flow + merges --no-ff	commitear, crear rama o MR, release/hotfix	🟦
docker-conventions	Multi-stage, BuildKit, cache mounts, non-root por stack, multi-plataforma, never-install-at-runtime	escribir/revisar un Dockerfile, contenerizar un servicio	🟦
terraform-conventions	Calidad IaC Terraform/Terragrunt: genera .checkov.yaml + .tflint.hcl + entradas mise (checkov/tflint) con rationale de skips (CKV_TF_1 global; CMK por proyecto)	scaffolding/auditoría de un repo Terraform/Terragrunt	🟦
repo-setup	Crear un repo desde cero: checklist, archivos obligatorios, naming GitLab, branch protection	crear un repo nuevo o auditar el setup de uno	🟦
bilingual-docs	Docs bilingües: EN canónico + X.es.md separado, switcher, marcador anti-drift synced-with (+ check determinista de staleness en audit/review)	traducir un README/CONTRIBUTING/guía, agregar un .es.md, mantener una traducción en sync	🟦
ci-pipeline	Modelo CI/CD centralizado y gestionado por Infra (los repos de dev no llevan .gitlab-ci.yaml)	preguntas de CI, pipelines, runners, stages, secretos de CI	🟦
api-security	OWASP API Security Top 10 (2023) + /health y /ready obligatorios + puertos no privilegiados	construir/revisar un servicio que expone API HTTP/REST	🟦
signed-commits	Setup de firma GPG (clave, gpg-agent + pinentry-mac, badge Verified en GitLab)	configurar firma, error "gpg failed to sign", commit/tag sin Verified	🟦
go-service	Convenciones para servicios y CLIs en Go	crear/modificar código Go, su Dockerfile, tests o pipeline	🟦
php-laravel	Convenciones para PHP/Laravel (incl. Dockerfile PHP-FPM)	crear/modificar código PHP, Composer, tests o pipeline	🟦
js-ts-bun	JS/TS con Bun como gestor de paquetes y Node.js como runtime	crear/modificar JS/TS, package.json, Dockerfile, monorepo NX, tests	🟦
python-fastapi	Convenciones para Python (incl. FastAPI)	crear/modificar código Python, su Dockerfile, deps o tests	🟦
rust-tools	Preferir CLIs en Rust (bat, eza, fd, rg, sd, gping, tldr) a los GNU/Unix	antes de correr cat/ls/find/grep/sed/ping/man	🟦
spec-driven-development	SDD: planear como contrato spec antes de codear, con gate de aprobación	features medianas/grandes o con riesgo; triggers 'sdd', 'spec this'	🟪
debugging	Causa raíz: reproduce → aislar (bisect) → Five Whys / fishbone → fix + test de regresión → verificar	un bug, stack trace, regresión, fallo flaky, "va en staging y no en prod"	🟪

Skills accionables (uso por petición en lenguaje natural)

agent-browser · skill · 📦

• Qué hace: automatización de navegador para agentes — navegar, rellenar formularios, clic, capturas, extraer datos, probar web apps (y apps Electron como VS Code/Slack/Figma).
• Cómo se invoca: lenguaje natural — "abre esta web y haz una captura", "rellena este formulario", "prueba este flujo de login", "extrae los datos de esta tabla".
• Ejemplo: "abre https://app.ejemplo.com, inicia sesión y haz una captura del dashboard".
• Limitaciones: requiere brew install agent-browser + agent-browser install (descarga su propio Chrome for Testing). Uso local.
• Aclaraciones: se prefiere sobre la automatización de navegador integrada y sobre Playwright para tareas de agente.

vp-gitignore-builder · skill · 📦

• Qué hace: construye y mergea .gitignore de repo o globales usando las plantillas de github/gitignore, con separación inteligente por destino.
• Cómo se invoca: lenguaje natural o /gitignore — "crea el .gitignore", "añade plantillas de gitignore", "set up gitignore". También se auto-activa al ver un repo sin .gitignore o archivos ignorables sin trackear.
• Ejemplo: "/gitignore para un proyecto Node + Python".
• Limitaciones: solo archivos .gitignore (no .dockerignore ni otros ignore).
• Aclaraciones: vendorizada (terceros, con crédito), pinneada en vendor/sources.json.

MCP (herramientas que Claude usa por ti)

MCP	Qué hace	Cómo se obtiene	Limitaciones / aclaraciones
playwright	Automatización/inspección de navegador	Declarado en el plugin (bunx @playwright/mcp@0.0.76)	Requiere bun + Node; descarga Chromium al primer uso
chrome-devtools	Inspección con Chrome DevTools (red, performance, consola)	Declarado en el plugin (bunx chrome-devtools-mcp@1.2.0)	Requiere bun + Node ≥ 20.19 + Google Chrome instalado
context7	Documentación de librerías al día	NO va en el plugin — per-dev: bunx ctx7 setup (OAuth) en Claude Code; conector Context7 en claude.ai para Cowork	Sin key funciona con rate limit (cortes intermitentes)

Guardrails always-on (no se invocan — se aplican solos) · 🟪

Hooks de wiedii-dev que se aplican solos (no son skills ni comandos); su fuente es politicas-core + git-workflow/repo-setup. Fallan en abierto (nunca rompen una sesión ni el tool Bash).

• Guardrail PreToolUse (Bash): bloquea antes de ejecutar los no-negociables — npm/yarn/pnpm (Bun es el gestor), --no-verify, curl | bash, y un GNU tool cuando su equivalente Rust está instalado (regla #12). Desde #13 también: el primer commit de un repo (sin HEAD) cuyo mensaje no sea EXACTAMENTE chore: initial commit → deny con la regla; y git flow … finish (un merge local salta branch protection + CI). Desde #32 también: crear una rama (checkout -b/switch -c/branch/git flow … start) cuyo nombre no sea (feature|release|hotfix)/<slug-kebab-case> → deny (renovate/* exento). Mensajes de deny autoexplicativos; toda incertidumbre resuelve hacia permitir.
• Mapa SessionStart "consultar-antes-de-actuar": al iniciar sesión (y tras compactación) inyecta un recordatorio imperativo operación→skill (git→git-workflow, repo nuevo→repo-setup, Go/PHP/JS/Py→skill de stack, Dockerfile→docker-conventions, etc.). Es un nudge para que Claude consulte la convención antes de improvisar — no una garantía dura.
• Limitaciones: la validación de contenido del commit más allá del primero (idioma, emoji, footer) no se fuerza aquí (frágil) — vive en commitlint + el nudge. No bloquea push directo a main/develop (lo gobierna branch protection).
• Aclaraciones: son tooling de enforcement del repo, no van en adoption.json y /sync-skills no los toca. El diseño se decidió por SDD + council (issue #13).

---

A.3 · Plugins acompañantes (auto-instalados como dependencia de wiedii-dev)

Plugin	Qué hace	Cómo se usa	Origen
engram	Memoria persistente entre sesiones (+ recuperación tras compactación)	Automático — recuerda decisiones; no haces nada	📦
feature-dev	Flujo de 7 fases explorar→diseñar→implementar→auto-review con agentes en paralelo	Se activa en desarrollo guiado; complementa /new-feature	🅰️
frontend-design	UI de alta calidad, evita estética genérica de IA	Se auto-activa en tareas de frontend	🅰️
claude-md-management	Auditar y mantener los CLAUDE.md	Por petición ("audita el CLAUDE.md")	🅰️
security-guidance	Revisión de seguridad del código generado (inyección/XSS/SSRF/secrets/IDOR)	Automático (default-on); costo afinable por env	🅰️
claude-code-setup	Recomendador de automatizaciones de Claude Code (hooks/subagents/skills)	Por petición	🅰️

Gotcha: un auto-update de wiedii-dev que sume deps nuevas no las instala en silencio → el plugin queda "failed to load". Solución: reinicia Claude Code (resuelve todas) o /reload-plugins (una dep por recarga). Detalle en plugins-claude-problemas-comunes y plugins-empresariales-distribucion-configuracion.

---

A.4 · Finanzas (wiedii-finance) y Diseño (wiedii-design)

Esqueleto, en construcción (finance-assistant / design-assistant). Mientras tanto, ambas áreas ya cuentan con todo lo de wiedii-core (incl. council y lyra).

---

Parte B — MANTENIMIENTO (de dónde sale cada cosa y cómo se sincroniza)

Para quien mantiene el marketplace. La fuente de verdad del diseño es claude-wiedii-plugin.

B.1 · Origen de cada capacidad

• 🟦 Wiedii (del vault): las skills de convención (dev-conventions, stacks, git-workflow, docker-conventions, terraform-conventions, repo-setup, bilingual-docs, ci-pipeline, api-security, signed-commits, wiedii-tooling, dependency-selection, testing-strategy, design-principles, rust-tools) + wiedii-core + los comandos /new-feature /review-pr /audit-project. Son snapshots curados de notas promovido del vault wiedii-documentation.
• 🟪 Curadas / guardrails (no del vault): council, lyra-prompt-optimizer, spec-driven-development (+ /sdd-new), debugging, el comando /feedback, y el guardrail wiedii-vault (autoreado en el repo; su fuente es el AGENTS.md + _Index del vault, no una nota promovido, por eso no va en adoption.json).
• 📦 Vendorizadas (terceros): agent-browser, vp-gitignore-builder, engram. Copiadas con crédito, pinneadas por SHA y con licencia verificada (manifiesto vendor/sources.json).
• 🅰️ Oficiales de Anthropic: feature-dev, frontend-design, claude-md-management, security-guidance, claude-code-setup. Se consumen de su marketplace (no se copian) y los mantiene Anthropic.

B.2 · Cómo se sincroniza

• Skills del vault (🟦): un maintainer corre /sync-skills (con el vault conectado): re-escanea las notas promovido, detecta drift vs adoption.json (mapeo nota→artefacto + hash de contenido), actualiza las skills y abre un MR. Las skills no leen el vault en runtime.
• Curadas (🟪) y vendorizadas (📦): no van en adoption.json y /sync-skills no debe marcarlas como huérfanas. Las vendorizadas se actualizan editando su entrada en vendor/sources.json (pin de SHA) y corriendo bun run vendor.
• Este catálogo + las guías de usuario: son hand-maintained (no se auto-sincronizan de adoption.json). Al añadir o cambiar una skill/comando/capacidad hay que reflejarlo aquí y en uso-plugins-claude-desarrollo (o uso-plugins-claude-para-usuarios si aplica a todas las áreas) — si no, una skill nueva auto-dispara pero un comando nuevo no se descubre.

B.3 · Tooling del repo (no es una capacidad de usuario)

El repo claude-wiedii-plugins trae tooling de mantenimiento (no se entrega al usuario): vendor.ts (vendoring de terceros), skillspector.ts (gate de seguridad de skills — NVIDIA SkillSpector, pinneado en mise.toml; bloquea HIGH/CRITICAL en componentes ejecutables, prosa = advisory; corre en pre-commit + bun run vendor + el comando maintainer /scan-skill), build-cowork-zips.sh (zips para Cowork) y mise tasks. Está documentado en docs/ del repo (referencia de comandos con ejemplos y limitaciones).

B.4 · Gotchas de mantenimiento

• Cascada de dependencias: ver gotcha de "failed to load" en A.3.
• skillListingBudgetFraction: 0.03 en managed settings — sin esto, con ~20 skills + deps el listado se trunca y una skill cuya descripción se dropea deja de auto-disparar. Detalle en plugins-empresariales-distribucion-configuracion.
• Edición del vault: seguir la skill wiedii-vault (lifecycle estado, revert promovido→maduro).

Relacionados

• uso-plugins-claude-para-usuarios — guía de uso día a día (general, todas las áreas).
• uso-plugins-claude-desarrollo — comandos y capacidades de Desarrollo.
• plugins-claude-problemas-comunes — troubleshooting común.
• plugins-empresariales-distribucion-configuracion — distribución y configuración (managed settings, Cowork, dependencias).
• claude-wiedii-plugin — arquitectura/decisiones del marketplace.
• prerequisitos-plugins-claude — qué instalar en la máquina.