Un plugin agrupa lo que ya has escrito —comandos, subagentes, skills, hooks— en una carpeta que otra persona puede instalar. El manifiesto es pequeño y poco polémico, y por eso resultan tan molestos sus errores: una versión que no es una versión, un nombre con mayúsculas, una web sin esquema. Ninguno impide que el archivo sea JSON válido y todos causan problemas después. Este creador rellena los campos, comprueba los que tienen reglas y muestra la estructura que el manifiesto espera a su alrededor, porque el manifiesto por sí solo no hace nada: son las carpetas contiguas las que realmente se cargan.
Características
Nombre comprobado contra las reglas de nomenclatura
Versión comprobada como versión semántica, prelanzamientos incluidos
Autor y correo anidados correctamente en vez de aplanados
La web se comprueba para ver si lleva esquema
Los campos vacíos se omiten en vez de escribirse en blanco
La estructura de carpetas junto al manifiesto
Palabras clave introducidas una por línea
Se descarga como plugin.json
Cómo usar Manifiesto de plugin
Nombra el plugin y dale una versión inicial
Describe qué agrupa
Añade autor, web y licencia si vas a compartirlo
Descarga plugin.json en la carpeta .claude-plugin
Ejemplo
Entrada
"version": "1.0"
Salida
Error: not a semantic version — use major.minor.patch
Las versiones de dos partes son el rechazo más habitual.
Errores comunes y solución de problemas
La versión se rechaza. — Las versiones semánticas tienen tres partes: 1.0.0, no 1.0. Un sufijo de prelanzamiento como 1.0.0-beta.1 está bien.
El plugin no aparece tras instalarlo. — El manifiesto va en .claude-plugin/plugin.json dentro de la carpeta del plugin, no en su raíz. La estructura bajo la salida muestra dónde va cada cosa.
El nombre se rechaza. — Minúsculas, dígitos y guiones simples. Se usa como identificador, así que mayúsculas y espacios quedan fuera.
No carga nada aunque el manifiesto sea válido. — El manifiesto solo describe el plugin. Comandos, agentes, skills y hooks se cargan de las carpetas contiguas: un plugin vacío con un manifiesto perfecto no hace nada.
Preguntas frecuentes
¿Qué puede contener un plugin?
Cualquier combinación de comandos slash, definiciones de subagente, skills y hooks, cada cosa en su carpeta junto al manifiesto. Todas son opcionales: un plugin con un solo comando útil es un plugin perfectamente válido.
¿Qué campos son realmente obligatorios?
El nombre, en la práctica. El resto son metadatos que lo hacen usable por otra gente: una descripción para saber qué es, una versión para notar cuándo cambió y una web para encontrar el código.
¿Cómo debería versionarlo?
Empieza en 0.1.0 mientras se mueva, y trata el primer número como la promesa de compatibilidad que haces. Cambiar el nombre de un comando o quitar una skill es un cambio incompatible para quien lo use.
¿Necesito el campo de licencia?
Solo si lo compartes. Y si lo compartes, decirlo explícitamente ahorra una conversación: un repositorio sin licencia es jurídicamente incómodo de reutilizar aunque esté claramente pensado para ello.
¿Puedo crear un plugin con cosas que ya tengo?
Suele empezar así. Los comandos y skills que ya funcionan se mueven sin cambios a las carpetas correspondientes; el manifiesto es el único archivo nuevo.
Herramientas relacionadas
Constructor de comandos — Crea un comando propio, con argumentos y una lista de herramientas.
Constructor de subagentes — Crea el archivo de definición de un subagente con sus herramientas y modelo.
Constructor de skills — Escribe un SKILL.md con el frontmatter revisado mientras escribes.
Constructor de hooks — Crea hooks de settings.json y detecta los matchers que nunca se activan.