Publicar un Plugin en el Marketplace de Claude

Preludio

Publicar un primer plugin de Claude Code puede llevar unas cuatro horas desde la idea inicial hasta un envío funcional, y la mayor parte de ese tiempo se dedica a decidir qué debería hacer realmente el plugin. Las partes mecánicas, escribir el manifiesto, estructurar los directorios, probar en local, son sencillas una vez que comprendes las convenciones.

Lo que puede sorprenderte es cuántas categorías siguen estando desatendidas. El directorio oficial de plugins tiene un ecosistema creciente de plugins, pero la gran mayoría cubre casos de uso muy específicos. Categorías enteras están vacías. Las herramientas de calidad de código, el tipo de cosa que todo equipo necesita, están infrarrepresentadas.

Esta guía recorre la construcción de un plugin de calidad de código desde cero. Incluye un skill para revisar código según estándares configurables, un hook pre-commit que detecta problemas comunes antes de que lleguen a una pull request, y un comando slash que genera stubs de tests a partir de archivos fuente existentes. Al final, tendrás un plugin funcional listo para enviarlo al marketplace.

Si llevas un tiempo usando Claude Code y quieres empaquetar tus flujos de trabajo para otros, esta guía cubre el camino completo.

El Problema

Claude Code es extraordinariamente capaz tal cual viene. Pero cada equipo tiene sus propios estándares. Las reglas de linting difieren en cada equipo. Las convenciones de testing siguen patrones específicos de cada stack. Las listas de verificación de code review reflejan años de conocimiento acumulado sobre lo que realmente falla en producción.

El sistema de plugins existe para cubrir esa brecha. En lugar de escribir las mismas instrucciones en CLAUDE.md en cada proyecto, empaquetas tus estándares en un plugin que cualquiera puede instalar con un solo comando. En lugar de configurar manualmente los hooks para cada repositorio, los distribuyes como parte de un plugin que lo configura todo automáticamente.

El ecosistema de plugins de Claude Code ha crecido rápidamente desde su lanzamiento. Cientos de plugins existen ya en el ecosistema, con el directorio oficial sirviendo como escaparate curado. Pero hay una distinción importante que debes entender antes de empezar a construir.

Existen dos marketplaces separados en el mundo de Claude. El Claude Enterprise Marketplace, que se lanzó el 6 de marzo de 2026, es para integraciones de software empresarial. Empresas como Snowflake, GitLab y Replit publican integraciones allí para su uso dentro de la interfaz web de Claude. Ese marketplace opera a nivel de organización y requiere una asociación con Anthropic.

El Claude Code Plugin Marketplace es donde publican los desarrolladores individuales. Es un directorio basado en GitHub donde los plugins se envían, revisan y listan para el CLI de Claude Code. Aquí es donde vivirá tu plugin, y está abierto a cualquiera.

Ambos marketplaces están creciendo. Para una visión más profunda del lado empresarial, consulta nuestra guía sobre cómo empezar con el Anthropic Marketplace. Esta guía se centra enteramente en el ecosistema de plugins de Claude Code, porque es donde los desarrolladores individuales pueden realmente publicar algo hoy.

El Camino

Comprender el Ecosistema de Plugins

Un plugin de Claude Code es un directorio que contiene un archivo de manifiesto y uno o más componentes. Los componentes pueden incluir skills (instrucciones que guían el comportamiento de Claude), hooks (manejadores de eventos que se disparan durante el ciclo de vida de Claude), comandos slash (atajos que los usuarios invocan directamente), agentes (definiciones de agentes personalizados) y configuraciones de servidores MCP.

Los plugins se instalan a través del CLI. Cuando un usuario ejecuta /plugin install con la URL de tu repositorio, Claude Code clona el plugin, valida su estructura y lo hace disponible en todas las sesiones. Los skills del plugin aparecen en la lista de skills del usuario, sus hooks se registran automáticamente y sus comandos quedan disponibles como comandos slash.

La documentación de referencia de plugins cubre la especificación completa. Lo que importa a efectos prácticos es entender el contrato. Tu plugin debe tener un manifiesto .claude-plugin/plugin.json. Todo lo demás es opcional pero sigue convenciones estrictas de directorio.

Planificar tu Plugin

Los mejores plugins resuelven un problema específico y recurrente. Los plugins amplios que intentan hacerlo todo tienden a ser mediocres en todo. Los plugins específicos que hacen una cosa bien se instalan y se conservan.

Para el plugin de calidad de código de esta guía, el punto de partida fue enumerar las tres cosas que los desarrolladores hacen más a menudo al revisar código.

Primero, comprobar problemas comunes. Imports sin usar, nombres inconsistentes, falta de manejo de errores, funciones demasiado largas. Esto se convierte en el componente skill.

Segundo, ejecutar comprobaciones antes de hacer commit. Linting, formateo, verificación de tipos. Esto se convierte en el componente hook.

Tercero, generar stubs de tests para código nuevo. Al escribir un nuevo módulo, tener un archivo de test correspondiente con las importaciones correctas y funciones de test vacías ahorra tiempo. Esto se convierte en el comando slash.

Ese alcance parecía correcto. Tres capacidades relacionadas que funcionan juntas pero son útiles de forma independiente. Un desarrollador podría instalar el plugin solo por el skill de revisión e ignorar completamente el hook.

Un principio que vale la pena interiorizar pronto. No intentes reemplazar herramientas existentes. El plugin debería hacer que Claude Code sea mejor trabajando con herramientas existentes, no reemplazarlas. El hook en este ejemplo ejecuta el propio linter del proyecto, sea cual sea. No implementa su propia lógica de linting.

Crear la Estructura del Plugin

Cada plugin sigue el mismo diseño de directorios. Aquí está la estructura completa para el plugin de calidad de código.

code-quality/
├── .claude-plugin/
│   └── plugin.json
├── skills/
│   └── SKILL.md
├── commands/
│   └── generate-tests.md
├── hooks/
│   └── hooks.json
├── README.md
└── CHANGELOG.md

Una regla crítica de la documentación de plugins. Solo plugin.json va dentro de .claude-plugin/. Nunca pongas tus skills, comandos, hooks ni ningún otro archivo en ese directorio. El directorio .claude-plugin/ es exclusivamente para el manifiesto.

Crea primero la estructura de directorios.

mkdir -p code-quality/.claude-plugin
mkdir -p code-quality/skills
mkdir -p code-quality/commands
mkdir -p code-quality/hooks

Ahora escribe el manifiesto. El archivo plugin.json le dice a Claude Code qué contiene tu plugin y dónde encontrarlo.

{
  "name": "code-quality",
  "version": "1.0.0",
  "description": "Code review skill, pre-commit quality hook, and test stub generator for Claude Code",
  "author": {
    "name": "Your Name",
    "email": "you@example.com",
    "url": "https://github.com/yourusername"
  },
  "homepage": "https://github.com/yourusername/code-quality",
  "repository": "https://github.com/yourusername/code-quality",
  "license": "MIT",
  "keywords": [
    "code-quality",
    "code-review",
    "testing",
    "linting",
    "pre-commit"
  ],
  "skills": ["skills/SKILL.md"],
  "hooks": "hooks/hooks.json",
  "commands": ["commands/generate-tests.md"]
}

El campo name debe estar en kebab-case. Esto se convierte en el espacio de nombres de los skills y comandos de tu plugin. Cuando los usuarios invoquen tu skill, escribirán /code-quality:review. Cuando usen tu comando, escribirán /code-quality:generate-tests.

El campo version sigue el versionado semántico. Empieza en 1.0.0. Si estás tentado de empezar en 0.1.0, resiste. Si el plugin funciona, es la versión 1.0.0.

El array keywords es la forma en que los usuarios descubren tu plugin en el marketplace. Elige palabras clave que describan lo que tu plugin hace, no lo que es. "code-review" es mejor que "plugin". "pre-commit" es mejor que "hook".

Construir tu Primer Skill

Los skills son el corazón de la mayoría de plugins. Un skill es un archivo markdown con frontmatter YAML que le dice a Claude cómo abordar una tarea específica. Cuando un usuario activa tu skill, Claude lee las instrucciones y las sigue durante toda la sesión.

Crea skills/SKILL.md con el siguiente contenido.

---
name: "review"
description: "Review code for quality issues, naming conventions, error handling, and common anti-patterns"
---

# Code Quality Review

When reviewing code, follow this structured approach.

## Analysis Steps

1. **Read the full file or diff before commenting.** Do not review line by line. Understand the complete context first, then identify issues.

2. **Check for structural problems first.**
   - Functions longer than 40 lines
   - Classes with more than 7 public methods
   - Files with more than 300 lines
   - Deeply nested conditionals (more than 3 levels)

3. **Check naming conventions.**
   - Variables should describe what they contain, not their type
   - Functions should describe what they do, not how they do it
   - Boolean variables should read as questions (isReady, hasPermission, canRetry)
   - Avoid abbreviations unless they are universally understood (id, url, http)

4. **Check error handling.**
   - Every external call (network, file system, database) must have error handling
   - Error messages must include context about what was being attempted
   - Never catch and silently swallow errors
   - Distinguish between recoverable and unrecoverable errors

5. **Check for common anti-patterns.**
   - Magic numbers and strings (should be named constants)
   - Repeated code blocks (should be extracted into functions)
   - Mutable state where immutable would work
   - Unnecessary comments that restate the code

## Output Format

Present findings as a prioritised list. Group issues by severity.

**Critical** items are bugs or security issues that must be fixed.
**Important** items are maintainability problems that should be fixed.
**Suggestion** items are style improvements that could be considered.

For each issue, include the file path, the line number or range, a clear description of the problem, and a concrete suggestion for fixing it.

If the code has no significant issues, say so. Do not invent problems to fill a report.

El campo name del frontmatter es lo que aparece después del espacio de nombres del plugin. Con name: "review" en un plugin llamado code-quality, los usuarios activan este skill ejecutando /code-quality:review.

El campo description aparece en los listados de skills y ayuda a los usuarios a entender qué hace el skill antes de activarlo.

El cuerpo del skill es markdown simple. Escríbelo como instrucciones claras y específicas. Evita orientaciones vagas como "escribe código limpio". En su lugar, da criterios concretos como "funciones de más de 40 líneas". Claude sigue instrucciones específicas de forma mucho más fiable que las abstractas.

Añadir Hooks para Automatización

Los hooks permiten que tu plugin reaccione a eventos en el ciclo de vida de Claude Code. El sistema de hooks soporta eventos como PreToolUse, PostToolUse, SessionStart y más. Para un plugin de calidad de código, el hook más útil es uno que ejecute comprobaciones de calidad cuando Claude está a punto de hacer commit de código.

Crea hooks/hooks.json con el siguiente contenido.

{
  "hooks": [
    {
      "event": "PreToolUse",
      "matcher": {
        "tool_name": "Bash",
        "input_contains": "git commit"
      },
      "command": "${CLAUDE_PLUGIN_ROOT}/hooks/pre-commit-check.sh",
      "description": "Run quality checks before committing",
      "timeout_ms": 30000
    }
  ]
}

Este hook se dispara cada vez que Claude está a punto de ejecutar un comando Bash que contiene git commit. El objeto matcher filtra qué llamadas a herramientas activan el hook. Sin un matcher, el hook se dispararía en cada llamada a herramienta de ese tipo de evento.

La variable ${CLAUDE_PLUGIN_ROOT} es crítica. Se resuelve al directorio donde tu plugin está instalado en la máquina del usuario. Nunca uses rutas absolutas o rutas relativas que asuman una ubicación específica. Los plugins se cachean y copian durante la instalación, así que la ruta real varía.

Ahora crea el script de shell que ejecuta el hook. Añade hooks/pre-commit-check.sh al directorio de tu plugin.

#!/usr/bin/env bash
set -euo pipefail

# Read the staged files
STAGED_FILES=$(git diff --cached --name-only --diff-filter=ACM)

if [ -z "$STAGED_FILES" ]; then
  exit 0
fi

ISSUES_FOUND=0

# Check for common problems in staged files
for FILE in $STAGED_FILES; do
  # Skip non-text files
  if file "$FILE" | grep -q "binary"; then
    continue
  fi

  # Check for debug statements
  if grep -n "console\.log\|debugger\|binding\.pry\|import pdb\|print(" "$FILE" 2>/dev/null; then
    echo "WARNING: Possible debug statement in $FILE"
    ISSUES_FOUND=$((ISSUES_FOUND + 1))
  fi

  # Check for TODO/FIXME without ticket references
  if grep -n "TODO\|FIXME\|HACK\|XXX" "$FILE" 2>/dev/null | grep -v "#[A-Z]\+-[0-9]\+"; then
    echo "WARNING: TODO/FIXME without ticket reference in $FILE"
    ISSUES_FOUND=$((ISSUES_FOUND + 1))
  fi
done

# Run project linter if available
if [ -f "package.json" ] && command -v npx &>/dev/null; then
  if npx --no-install eslint --max-warnings 0 $STAGED_FILES 2>/dev/null; then
    echo "ESLint passed"
  else
    echo "ESLint found issues"
    ISSUES_FOUND=$((ISSUES_FOUND + 1))
  fi
elif [ -f "pyproject.toml" ] && command -v ruff &>/dev/null; then
  if ruff check $STAGED_FILES 2>/dev/null; then
    echo "Ruff passed"
  else
    echo "Ruff found issues"
    ISSUES_FOUND=$((ISSUES_FOUND + 1))
  fi
elif [ -f "Cargo.toml" ] && command -v cargo &>/dev/null; then
  if cargo clippy --quiet 2>/dev/null; then
    echo "Clippy passed"
  else
    echo "Clippy found issues"
    ISSUES_FOUND=$((ISSUES_FOUND + 1))
  fi
fi

if [ $ISSUES_FOUND -gt 0 ]; then
  echo ""
  echo "Found $ISSUES_FOUND potential issue(s). Review before committing."
  # Exit 0 to allow the commit but surface the warnings
  # Change to exit 1 if you want to block commits with issues
  exit 0
fi

echo "All pre-commit checks passed."
exit 0

Haz el script ejecutable.

chmod +x code-quality/hooks/pre-commit-check.sh

Hay una decisión de diseño importante aquí. El hook sale con código 0 incluso cuando se encuentran problemas. Esto significa que el commit procede pero las advertencias se muestran a Claude, quien puede entonces decidir si abordarlas. Si quieres una política más estricta donde los commits se bloqueen hasta que todos los problemas estén resueltos, cambia el exit 0 final por exit 1.

El enfoque permisivo se recomienda porque bloquear commits puede ser frustrante durante la iteración rápida. Claude ve las advertencias y normalmente las aborda en un commit posterior. Para equipos que necesitan un cumplimiento más estricto, el código de salida es el único cambio necesario.

El hook también detecta el toolchain existente del proyecto. Si el proyecto usa Node.js, ejecuta ESLint. Si usa Python, ejecuta Ruff. Si usa Rust, ejecuta Clippy.

Este es el principio mencionado anteriormente. El plugin trabaja con herramientas existentes en lugar de reemplazarlas.

Añadir Comandos Slash

Los comandos slash dan a los usuarios una forma directa de invocar funcionalidades específicas del plugin. A diferencia de los skills, que guían el comportamiento de Claude durante toda una sesión, los comandos son acciones puntuales. El usuario escribe el comando, Claude ejecuta las instrucciones y la interacción se completa.

Crea commands/generate-tests.md con el siguiente contenido.

---
name: "generate-tests"
description: "Generate test stubs for a source file"
arguments:
  - name: "file"
    description: "Path to the source file to generate tests for"
    required: true
---

Generate a test file for the specified source file. Follow these rules.

1. **Determine the test framework from the project.**
   - JavaScript/TypeScript: check for jest, vitest, or mocha in package.json
   - Python: check for pytest or unittest in pyproject.toml or requirements
   - Rust: use the built-in test module
   - Go: use the built-in testing package
   - If unclear, ask the user which framework to use

2. **Create the test file in the correct location.**
   - JavaScript/TypeScript: `__tests__/[filename].test.[ext]` or `[filename].test.[ext]` next to the source, matching the project's existing pattern
   - Python: `tests/test_[filename].py` or matching the project's existing pattern
   - Rust: add a `#[cfg(test)] mod tests` block in the same file
   - Go: `[filename]_test.go` in the same directory

3. **Generate one test stub per public function or method.**
   - Import/require the function from the source file
   - Create a test with a descriptive name: `test_[function_name]_[what_it_tests]`
   - Add a comment inside each test describing what should be verified
   - Leave the test body with a placeholder assertion that will fail: `expect(true).toBe(false)` or equivalent
   - Do NOT implement the test logic. The user will fill that in.

4. **Include edge case stubs.** For each function, add stubs for:
   - Normal input
   - Empty or null input
   - Error cases (if the function can throw or return errors)

5. **Output only the test file.** Do not modify the source file.

El bloque arguments en el frontmatter define lo que el comando espera. Cuando un usuario escribe /code-quality:generate-tests src/utils/parser.ts, Claude recibe la ruta del archivo como argumento file y sigue las instrucciones.

Observa que las instrucciones del comando son intencionadamente prescriptivas sobre dónde crear el archivo y cómo nombrar los tests, pero deliberadamente dejan la lógica de test como stubs. Esta es una decisión de diseño. Los tests generados que intentan adivinar la implementación casi siempre son incorrectos. Los stubs con descripciones claras de lo que debe probarse son realmente útiles.

Probar en Local

Antes de enviar nada al marketplace, prueba tu plugin exhaustivamente. Claude Code tiene soporte integrado para cargar plugins desde un directorio local.

claude --plugin-dir ./code-quality

Esto inicia una sesión de Claude Code con tu plugin cargado. Deberías ver el plugin listado cuando compruebes los plugins disponibles.

Prueba cada componente individualmente.

Probar el skill. Actívalo escribiendo /code-quality:review en una sesión, luego pide a Claude que revise un archivo. Verifica que Claude sigue tus criterios de revisión y usa el formato de salida que especificaste.

/code-quality:review
Review the file src/handlers/auth.ts

Presta atención a estos aspectos durante las pruebas.

¿Sigue Claude las comprobaciones estructurales (longitud de funciones, tamaño de clases, profundidad de anidamiento)? ¿Usa las categorías de severidad que definiste? ¿Evita inventar problemas cuando el código está limpio?

Probar el hook. Prepara algunos archivos en staging y pide a Claude que haga commit. El hook pre-commit debería dispararse y mostrar su salida.

Stage and commit the changes with message "Add authentication handler"

Verifica que el hook detecta sentencias de depuración, comprueba comentarios TODO sin referencias a tickets y ejecuta el linter apropiado para tu proyecto.

Probar el comando. Ejecuta el comando generate-tests con un archivo fuente real.

/code-quality:generate-tests src/utils/parser.ts

Verifica que el archivo de test generado usa el framework correcto, aparece en la ubicación correcta y tiene stubs para cada función pública.

Si algo no funciona, valida la estructura del plugin.

claude plugin validate ./code-quality

Esto comprueba que tu manifiesto es válido, que todos los archivos referenciados existen y que la estructura de directorios sigue las convenciones. El validador detecta la mayoría de problemas estructurales antes de que los encuentres durante las pruebas.

También puedes validar desde dentro de una sesión usando /plugin validate . mientras tu directorio de trabajo es la raíz del plugin.

Preparar para la Publicación

Antes de enviar al marketplace, tu plugin necesita tres cosas más allá del código en sí.

Un README. El README es lo primero que ven los usuarios potenciales. Debería explicar qué hace el plugin, cómo instalarlo y cómo usar cada componente. No asumas que el lector sabe nada sobre tu plugin más allá del título.

Aquí tienes un README de ejemplo para el plugin de calidad de código.

# Code Quality Plugin for Claude Code

A Claude Code plugin that brings code review, pre-commit checks, and test generation into your workflow.

## Features

- **Code Review Skill** - Structured review against configurable quality criteria
- **Pre-Commit Hook** - Catches debug statements, missing ticket references, and linting issues before commit
- **Test Generator** - Creates test stubs for any source file using your project's test framework

## Installation

Install from the Claude Code CLI:

/plugin install https://github.com/yourusername/code-quality

## Usage

### Review code quality
Activate the review skill, then ask Claude to review files or diffs.

/code-quality:review

### Generate test stubs
Point the command at a source file to generate corresponding test stubs.

/code-quality:generate-tests path/to/file.ts

### Pre-commit checks
The hook runs automatically when Claude commits code. No activation needed.

## Configuration

The pre-commit hook detects your project's toolchain automatically:
- Node.js projects: runs ESLint
- Python projects: runs Ruff
- Rust projects: runs Clippy

## Requirements

- Claude Code CLI
- Your project's linter installed locally (ESLint, Ruff, or Clippy)

Un CHANGELOG. Empieza simple. Para la versión 1.0.0, una sola entrada es suficiente.

# Changelog

## 1.0.0 - 2026-03-10

- Initial release
- Code review skill with structured quality criteria
- Pre-commit hook with debug statement detection and linter integration
- Test stub generator supporting JavaScript, TypeScript, Python, Rust, and Go

Validación de versión. Asegúrate de que la versión de tu plugin.json coincide con tu CHANGELOG y cualquier etiqueta de git que crees. El versionado inconsistente es la razón más común de rechazo en el marketplace.

Ejecuta el validador una última vez.

claude plugin validate ./code-quality

Corrige cualquier problema que reporte. El validador es estricto con la estructura pero no evalúa la calidad de las instrucciones de tus skills o la lógica de los hooks. Eso es lo que cubre tu fase de pruebas.

Enviar al Marketplace

El proceso de envío tiene dos vías dependiendo de la escala de tu plugin.

Para el directorio oficial de Anthropic, envíalo a través del formulario de envío al directorio de plugins. Tu plugin será revisado según estándares de calidad y seguridad. El equipo de revisión comprueba varias cosas.

¿Sigue el manifiesto la especificación? ¿Están presentes todos los archivos referenciados? ¿Evita el plugin acceder a recursos fuera de su propio directorio? ¿Son las instrucciones de los skills claras y bien estructuradas? ¿Explica el README adecuadamente la instalación y el uso?

Los plugins externos se listan en el directorio external_plugins/ del repositorio oficial. Una vez aprobado, los usuarios pueden descubrir tu plugin a través de la funcionalidad de búsqueda de plugins del CLI.

El proceso de revisión normalmente tarda unos días. Durante ese tiempo, puedes distribuir tu plugin directamente a través de su URL de GitHub. Los usuarios pueden instalar cualquier plugin desde un repositorio Git, independientemente de si está listado en el directorio oficial.

/plugin install https://github.com/yourusername/code-quality

Esto funciona inmediatamente. El listado en el marketplace añade visibilidad, no funcionalidad.

Consejos para el envío. El equipo de revisión es exhaustivo pero justo. Los comentarios más comunes sobre envíos rechazados caen en tres categorías.

Primero, el plugin referencia archivos fuera de su propio directorio. Esta es una frontera de seguridad. Tus hooks y scripts deben usar ${CLAUDE_PLUGIN_ROOT} para todas las referencias de rutas y nunca asumir nada sobre la disposición de archivos del sistema anfitrión.

Segundo, el README es insuficiente. "Instala y usa" no es documentación suficiente. Cada componente necesita una explicación clara de lo que hace y cómo invocarlo.

Tercero, el plugin hace demasiado. Si tu plugin tiene quince skills, siete comandos y una docena de hooks, considera dividirlo en múltiples plugins enfocados. El marketplace recompensa la especificidad.

Crear tu Propio Marketplace

Si estás construyendo plugins para un equipo u organización en lugar de para el público, puedes alojar tu propio marketplace. Esto es útil cuando tus plugins contienen estándares propietarios que no deberían ser públicos, o cuando quieres curar un conjunto de plugins aprobados para tu equipo de ingeniería.

Un marketplace personalizado se define mediante un archivo .claude-plugin/marketplace.json dentro de un repositorio git al que tu equipo pueda acceder. Crea el archivo en .claude-plugin/marketplace.json en la raíz de tu repositorio de marketplace.

{
  "name": "Acme Engineering Plugins",
  "description": "Internal Claude Code plugins for Acme Corp engineering teams",
  "plugins": [
    {
      "name": "code-quality",
      "description": "Code review, pre-commit checks, and test generation",
      "version": "1.0.0",
      "repository": "https://github.com/acme-corp/claude-code-quality",
      "keywords": ["code-quality", "review", "testing"]
    },
    {
      "name": "acme-standards",
      "description": "Acme Corp coding standards and architecture patterns",
      "version": "2.1.0",
      "repository": "https://github.com/acme-corp/claude-acme-standards",
      "keywords": ["standards", "architecture"]
    }
  ]
}

Aloja este repositorio en GitHub, GitLab o cualquier servidor git al que tu equipo pueda acceder. Los usuarios añaden tu repositorio de marketplace como fuente en su configuración de Claude Code, y tus plugins aparecen junto al directorio oficial.

La documentación de marketplaces de plugins cubre la especificación completa para archivos de marketplace personalizados. Para la mayoría de equipos, el formato simple anterior es suficiente.

Este enfoque funciona bien en combinación con el sistema de skills y cowork de EntendIA. Puedes usar plugins para el CLI de Claude Code y skills de EntendIA para la interfaz web de Claude, dando a tu equipo estándares consistentes en ambos entornos.

La Lección

El sistema de plugins cambia la forma en que los equipos piensan sobre los flujos de trabajo de Claude Code. Antes de los plugins, cada mejora en la configuración de Claude Code era local. Mejores archivos CLAUDE.md, hooks más sofisticados, instrucciones de skills refinadas. Todo vivía en directorios de proyectos individuales y no se podía compartir fácilmente.

Los plugins hacen que esas mejoras sean portables. Un plugin de calidad de código construido para un conjunto de proyectos puede ejecutarse en docenas de repositorios dentro de un equipo. Cuando los criterios de revisión mejoran o se añade una nueva comprobación al hook pre-commit, todos reciben la actualización en su próxima sesión.

La barrera técnica para publicar es baja. Si puedes escribir un archivo markdown y un manifiesto JSON, puedes publicar un plugin.

La parte más difícil es el trabajo de diseño. Decidir qué pertenece al plugin y qué no. Escribir instrucciones de skills que sean lo suficientemente específicas para ser útiles pero lo suficientemente flexibles para funcionar en diferentes bases de código. Elegir la granularidad correcta para los hooks de modo que ayuden sin estorbar.

Tres principios se aplican ampliamente al diseñar plugins.

Primero, resuelve un problema específico. Los mejores plugins del marketplace hacen una cosa excepcionalmente bien. Un plugin que formatea consultas SQL. Un plugin que impone convenciones de mensajes de commit. Un plugin que genera documentación de API a partir de comentarios en el código.

La especificidad es una característica.

Segundo, trabaja con herramientas existentes. El hook pre-commit en este plugin ejecuta el propio linter del proyecto. No incluye sus propias reglas de linting. Esto significa que funciona con cualquier proyecto independientemente del lenguaje o toolchain.

Los plugins que intentan reemplazar herramientas existentes crean fricción. Los plugins que mejoran herramientas existentes crean valor.

Tercero, escribe instrucciones como si el lector no supiera nada sobre tu intención. Claude sigue lo que escribes, no lo que quieres decir. Si tu skill dice "comprueba problemas comunes", Claude hará su propio juicio sobre qué cuenta como común. Si tu skill dice "comprueba funciones de más de 40 líneas", Claude hará exactamente eso. La precisión en las instrucciones se traduce directamente en fiabilidad en el resultado.

Conclusión

El ecosistema de plugins de Claude Code todavía está en sus inicios. Con cientos de plugins en el ecosistema más amplio y el directorio oficial creciendo a diario, ya hay una base. Pero comparado con ecosistemas de plugins maduros en otras herramientas, la superficie de lo que está cubierto sigue siendo pequeña.

Eso es una oportunidad. Si has construido flujos de trabajo en Claude Code que te funcionan bien, empaquetarlos como un plugin es sencillo. La estructura de directorios es simple. El manifiesto es un único archivo JSON.

El flujo de trabajo de pruebas está integrado en el CLI. Y el proceso de envío, aunque requiere cumplir estándares de calidad, está abierto a cualquiera.

Empieza con algo pequeño. Un único skill que capture tus mejores prácticas de revisión de código. Un hook que automatice una comprobación que actualmente haces manualmente. Un comando que genere código repetitivo que estás cansado de escribir.

Hazlo funcionar en local, valídalo y envíalo.

La documentación de plugins cubre todo lo no abordado en esta guía. La referencia de plugins documenta cada campo del manifiesto y convención de directorio. Y si quieres ver cómo los plugins encajan en el ecosistema más amplio de Claude junto con los skills y el marketplace, la plataforma EntendIA lo une todo.

Tus mejoras de flujo de trabajo no deberían vivir y morir en un único directorio de proyecto. Empaquétalas. Publícalas. Deja que otros desarrolladores se beneficien de lo que has aprendido.