En este artículo
Claude Mods: configuración, function hooks y seguridad
Claude Mods son plugins de Claude Code que utilizan function hooks para ampliar el comportamiento del agente durante la ejecución, en lugar de limitarse a aportar instrucciones o herramientas externas. Pueden intervenir en eventos del motor y en la representación de la interfaz. Para un equipo, la pregunta importante no es si una demostración resulta llamativa, sino si la extensión resuelve un problema recurrente sin complicar los permisos, la depuración y las actualizaciones.
Fecha de revisión: . Este artículo analiza documentación y código fuente; no es una prueba de rendimiento realizada en una sesión real. Distinguimos la API publicada y el acceso experimental de la disponibilidad general. Nuestras recomendaciones de adopción son criterios de ingeniería, no garantías de Anthropic.
¿Ya están disponibles los Claude Mods?
Existe una vía de acceso experimental documentada, pero las fuentes revisadas no acreditan una versión estable de disponibilidad general. En la actualización del 9 de septiembre del anuncio oficial de Claude Mods, Anthropic presenta el nombre, enlaza ejemplos integrados y publica CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1 claude para realizar pruebas. Esa misma actualización sitúa el lanzamiento más amplio en un plazo de semanas. La propuesta original se publicó el 3 de septiembre de 2026.
El directorio oficial del código de Mods identifica expresamente la interfaz como acceso anticipado y advierte que la API puede cambiar entre versiones sin previo aviso. Sus ejemplos son el código de funciones integradas, no entradas del mercado de plugins de ese repositorio. Nuestra recomendación es evaluar Mods mediante un piloto controlado, sin presuponer un contrato de soporte estable.
También existe un repositorio comunitario independiente llamado 0xDarkMatter/claude-mods. No debe confundirse esa colección con la función nativa de Anthropic, ni suponerse que las instrucciones de instalación de uno sirven para el otro. En este artículo, «Claude Mods» se refiere a la función de Anthropic.
Claude Mods frente a Skills, MCP, plugins y hooks clásicos
Cada mecanismo responde a una necesidad distinta. La documentación de Skills de Anthropic describe instrucciones y procedimientos reutilizables; su documentación de MCP explica la conexión de herramientas y datos. La referencia de hooks clásicos ya permite tomar decisiones en los eventos compatibles anteriores a una ejecución. Mods no inventa la capacidad de impedir una acción. La documentación de plugins describe la capa que empaqueta y distribuye distintos tipos de extensiones.
| Mecanismo | Función principal | Buen punto de partida cuando |
|---|---|---|
| Skills e instrucciones del proyecto | Aportar conocimiento y procedimientos reutilizables | El agente necesita convenciones, listas de comprobación o contexto de diseño |
| MCP | Exponer herramientas, recursos e integraciones externas | El agente necesita conectarse a otro sistema |
| Hooks clásicos | Ejecutar lógica configurada en eventos compatibles del ciclo de vida | Un evento existente puede activar la comprobación o autorización necesaria |
| Claude Mods | Combinar function hooks alrededor de eventos del motor e interfaces compatibles | Hace falta una composición de eventos más profunda o un comportamiento de interfaz específico |
| Plugins | Empaquetar y distribuir extensiones | Se necesita una unidad de instalación reutilizable, que puede incluir un Mod |
Un Mod es un tipo de plugin, no un sustituto del sistema de plugins. Nuestro criterio es empezar por el mecanismo menos potente que cumpla los criterios de aceptación. Por ejemplo, un contexto de sistema de diseño para Claude Code suele ser mejor punto de partida para respetar una marca que escribir código para el motor. Primero conecta un servicio externo mediante MCP y después comprueba si un Mod aporta algo que realmente le falte a esa integración.
Cómo funcionan los function hooks: eventos, interfaz del motor y next
El código publicado describe un punto de entrada, register(on, options), cuyos manejadores reciben ($, e, next). e representa el evento; $, la interfaz del motor disponible para ese manejador; y next, la continuación por el resto de la cadena. Se parece más a un middleware que a un prompt de sistema más largo.
Las declaraciones de TypeScript publicadas que revisamos identifican Claude Code 2.1.273. Describen un entorno de hooks sin Node.js ni DOM del navegador, con capacidades compatibles mediadas por la interfaz del motor. Los elementos visuales proceden de la superficie correspondiente, no de un acceso arbitrario a una página web. Después de actualizar, regenera las declaraciones con /plugin-types en vez de dar por hecho que los tipos anteriores siguen siendo válidos.
El orden importa. Un manejador envolvente puede actuar antes de delegar y después examinar el resultado devuelto. Por tanto, dos manejadores anidados pueden interferir aunque cada uno parezca correcto por separado. En una revisión de implementación comprobaríamos qué capa decide una denegación, si un reintento repite un efecto secundario y si la continuación se invoca exactamente como se pretendía. Que TypeScript compile no demuestra que esas interacciones sean correctas.
La ausencia de una API directa de Node.js tampoco constituye un argumento de seguridad completo. Un Mod que accede a una herramienta potente a través del motor sigue necesitando un límite de confianza bien definido. Los permisos, las restricciones de red, el tratamiento de datos y la configuración administrativa deben revisarse por separado.
¿Qué demuestran los tres Mods integrados publicados?
sec-default: proteger la configuración administrada por la organización
La documentación de sec-default describe una capa administrativa exterior que mantiene determinados ajustes administrados, contenidos del prompt, hooks clásicos y políticas de herramientas fuera del alcance de los plugins instalados por el usuario. No añade políticas de negocio propias. Muchos otros eventos pasan sin cambios: no es un cortafuegos general para cada llamada a una herramienta.
Su posición en la cadena forma parte de esa protección. La posición predeterminada documentada cambia cuando la organización define su propia lista prependPlugins; entonces debe tener en cuenta expresamente sec-default@builtin. Cargar una carpeta local no equivale a desplegar un control administrado por la organización. Nuestra conclusión es revisar la configuración completa, no confiar únicamente en un nombre de plugin tranquilizador.
diff: una extensión real de la interfaz
El Mod diff muestra cambios sin confirmar y fragmentos de archivos junto al historial de conversación, actualizando el panel cuando se editan archivos o ejecutan comandos. Es un caso de uso concreto de interfaz, no una prueba de que el modelo subyacente sea más inteligente. El código contempla además directorios que no son repositorios Git y un comando /diff ya registrado: casos límite importantes para una extensión similar.
telemetry: publicar el código no significa ofrecer una instalación pública
El README del propio Mod telemetry establece más restricciones de las que sugiere una mirada rápida al directorio. Indica que funciona en compilaciones internas con analítica habilitada y que no está pensado para instalarse de forma independiente mediante --plugin-dir. Sus capacidades no son un servicio público de registro de eventos. Debe tratarse como ejemplo de arquitectura, no como una recomendación de instalación en entornos de clientes.
Cómo probar Claude Mods sin presuponer una API estable
Utiliza un proyecto de prueba desechable, datos sintéticos, una instalación aprobada de Claude Code y ninguna credencial de producción. Los siguientes comandos están documentados en las fuentes; no afirmamos haberlos ejecutado en una sesión real de Claude. Su compatibilidad depende de la compilación instalada y de los controles de la organización.
claude --version
CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1 claudeRegistra la versión y ejecuta /plugin-types dentro de una sesión compatible. Conserva las declaraciones generadas junto con las pruebas del piloto. Si el comando o la función no están disponibles, consulta el acceso admitido con la administración. No desactives protecciones administradas para conseguir que funcione un ejemplo.
Para inspeccionar el código, utiliza una revisión examinada del repositorio oficial. Desde su directorio raíz, el ejemplo documentado de diff y su entorno de pruebas pueden invocarse así, aplicando la activación experimental a cada proceso:
CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1 claude --plugin-dir ./mods/diff
CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1 claude plugin test ./mods/diffEl comando /diff ya integrado puede influir en qué implementación controla la acción. Por tanto, cargar un directorio no demuestra que se haya ejecutado un manejador concreto. Identifica la implementación activa mediante pruebas o evidencias de diagnóstico explícitas que no contengan datos sensibles.
Un Mod publicado es un directorio normal de plugin, con un manifiesto y un módulo de hooks:
my-reviewed-mod/
├── .claude-plugin/plugin.json
├── hooks/
│ ├── hooks.json
│ └── register.ts
└── tests/El archivo oficial hooks.json de diff referencia su módulo mediante el siguiente campo. Es un fragmento de configuración del cargador, no un plugin completo ni un control de seguridad:
{
"modules": ["./register.ts"]
}Implementa el punto de entrada utilizando las declaraciones generadas, añade pruebas y revisa todo el código antes de cargarlo. Evita comandos inventados para un supuesto instalador universal de Mods. Para distribuirlos, utiliza los mecanismos de plugins compatibles y el proceso de aprobación de la organización, no un script arbitrario encontrado en un buscador.
¿Dónde podrían aportar valor práctico los Claude Mods?
Los siguientes diseños son propuestas de pilotos, no implementaciones realizadas por Wavect ni funciones integradas garantizadas. Cada uno parte de un resultado observable, en lugar del objetivo abstracto de «añadir más IA».
Un panel de revisión de evidencias de entrega. Reunir los cambios actuales, el estado de las pruebas y los hallazgos pendientes de revisión. Empezar en modo de solo lectura. Aceptar el piloto únicamente cuando cada estado pueda vincularse con la revisión y ejecución de pruebas exactas, y se rechacen de forma visible las evidencias obsoletas. Un indicador verde atractivo sin esa relación es peor que la salida original del terminal.
Tratamiento controlado de resultados sensibles de herramientas. Un equipo podría transformar los datos antes de enviarlos al modelo. Nuestro criterio de aceptación sería seguir valores de prueba sintéticos por la respuesta original, la transformación, la entrada del modelo, el historial visible y los registros. Ocultar un dato en pantalla no equivale a retirarlo del contexto del modelo; ninguna de las dos cosas demuestra, por sí sola, que se hayan eliminado las copias almacenadas.
Controles de flujo específicos de la organización. Un Mod podría complementar controles existentes con comprobaciones contextuales o explicaciones. La autorización real de despliegue, la protección de repositorios y el alcance de las credenciales no deben depender únicamente de una capa que el usuario pueda desinstalar. Primero comprueba si un hook clásico o la canalización de CI existente cumplen el requisito con menos código propio.
¿Qué límites de seguridad debe probar un equipo?
La guía de seguridad de Claude Code y la documentación de aislamiento mediante sandbox de Anthropic describen controles más allá de los plugins individuales. Deben revisarse de forma independiente. Un entorno restringido para hooks, una interfaz que parece segura y una entrada aprobada en un mercado responden a preguntas diferentes. Ninguno debe sustituir silenciosamente a los demás.
| Riesgo | Prueba | Evidencia exigida |
|---|---|---|
| Cambios de versión o API | Repetir las pruebas al cambiar la CLI o la revisión del Mod | Versiones exactas, tipos regenerados y cambios de comportamiento revisados |
| Composición insegura de la cadena | Combinar eventos permitidos, denegados y transformados entre las capas aprobadas | Orden previsto, decisión final y ausencia de efectos secundarios duplicados involuntarios |
| Protección ausente o averiada | Probar errores de manejadores, tiempos de espera agotados, Mods desactivados y recargas | Un control independiente sigue bloqueando la acción protegida cuando la protección no está disponible |
| Filtración de datos sensibles | Seguir valores sintéticos por todos los destinos | Ningún valor prohibido en la entrada del modelo, los registros exportados o los artefactos conservados dentro del alcance probado |
| Dependencia exclusiva de la interfaz | Ejecutar las rutas interactivas y no interactivas compatibles | Ningún flujo desatendido espera una interfaz no disponible |
| Regresión operativa | Desactivar el Mod y restaurar la configuración aprobada | Procedimiento de reversión conocido, responsable asignado y comprobaciones de referencia satisfactorias |
Son requisitos de aceptación que deben implementarse y verificarse, no afirmaciones sobre todos los fallos posibles de la versión actual. En particular, una ejecución normal satisfactoria no demuestra un bloqueo seguro ante errores. Prueba expresamente las rutas de denegación e indisponibilidad con credenciales incapaces de acceder a producción.
Para revisar la cadena de suministro, combina el examen del código con la documentación oficial de mercados de plugins. Registra el editor, la revisión examinada, las dependencias, las capacidades solicitadas, la vía de actualización y el procedimiento de revocación. Prueba la combinación que se desplegará, incluidas las capas administrativas y los demás plugins, en vez de aprobar cada componente únicamente por separado.
¿Claude Mods reduce el gasto en tokens o mejora la productividad?
Esta revisión no contiene un porcentaje de ahorro medido. La documentación de costes de Anthropic explica el consumo de Claude Code, pero un Mod no es un descuento. Nuestra evaluación incluiría llamadas adicionales a herramientas, contexto, reintentos, desarrollo y mantenimiento, además de los pasos manuales eliminados.
Una métrica útil para el piloto es el coste total por tarea aceptada: los costes atribuibles del modelo y las herramientas, más el tiempo de ingeniería y revisión, divididos entre las tareas que cumplen los mismos criterios de aceptación. Es nuestro método de evaluación, no una fórmula de facturación de Anthropic. Compara la referencia y la variante con Mod utilizando las mismas tareas, configuración del modelo y exigencia de calidad. Informa de fallos y regresiones, no solo del ejemplo exitoso más rápido.
Un piloto que ahorra interacción pero genera más retrabajo puede resultar perjudicial. En cambio, una pequeña mejora en un paso de revisión frecuente y costoso puede justificar un Mod de alcance limitado. Define la mejora buscada y el mantenimiento admisible antes de desarrollar.
¿Debería tu equipo adoptar Claude Mods ahora?
Realiza un piloto cuando exista una limitación concreta de ejecución o interfaz, datos de prueba controlados, una persona responsable y una forma de revertir los cambios. Espera cuando Skills, MCP, un hook clásico o CI ya resuelvan la necesidad, o cuando la extensión vaya a convertirse en la única barrera que protege producción. Recomendamos que un experimento pequeño y reversible justifique su incorporación con evidencias.
En Wavect abordamos esto mediante la adopción de IA para equipos de ingeniería: identificar el flujo, definir pruebas de aceptación y relacionar el resultado con la calidad de entrega. Nuestro caso de Twinsoft AI demuestra por separado nuestro trabajo en proyectos de IA; no se presenta como una implementación de Claude Mods. La lista de comprobación de calidad antes del lanzamiento ofrece una referencia útil para los demás cambios que el agente haga en el producto.
Como contexto de la empresa, nuestro registro de posiciones de septiembre de 2026 documenta los puestos #1 de Wavect en categorías de Austria de Clutch, The Manifest y GoodFirms, con fuentes y fechas específicas. Esas posiciones no garantizan resultados ni demuestran que hayamos desplegado esta nueva función. Para un piloto concreto, hablemos de un flujo y sus criterios de aceptación.
Preguntas frecuentes sobre Claude Mods
¿Qué son Claude Mods?
Claude Mods son plugins de Claude Code que usan function hooks para participar en eventos de ejecución y comportamientos de interfaz compatibles. Amplían la aplicación alrededor del modelo; no son un modelo nuevo ni sustituyen el sistema de plugins.
¿Cómo activo Claude Mods?
El anuncio oficial documenta CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1 claude para pruebas experimentales. Comprueba primero la versión instalada y las políticas de la organización, y genera declaraciones compatibles con /plugin-types en una sesión admitida. Esto no acredita disponibilidad estable en todas las instalaciones.
¿En qué se diferencian de los hooks clásicos de Claude Code?
Los hooks clásicos ya ejecutan lógica configurada en eventos compatibles del ciclo de vida y pueden decidir antes de ciertas acciones. Mods utiliza composición de funciones alrededor del motor y de interfaces compatibles. Elige un hook clásico si ya cumple el requisito.
¿Claude Mods sustituye a Skills o MCP?
No. Skills aporta instrucciones y procedimientos reutilizables; MCP conecta herramientas y datos externos. Un Mod responde a otra necesidad, como una composición de ejecución más profunda o un comportamiento de interfaz específico. Un plugin puede reunir varios tipos de extensión.
¿Es seguro utilizar Claude Mods en producción?
La etiqueta de acceso anticipado no garantiza seguridad en producción. Revisa código, capacidades y configuración administrada, y prueba la combinación real de plugins. Una autorización crítica no debe depender únicamente de un Mod desinstalable o no disponible. Incluye pruebas de fallo y una reversión verificada.
¿Claude Mods abarata Claude Code?
No de forma automática. Las herramientas adicionales, el contexto, los reintentos y el mantenimiento pueden aumentar el coste total. Compara el coste por tarea aceptada con la misma referencia y los mismos criterios de calidad. Este artículo no afirma ahorros medidos ni un multiplicador de productividad.
