Claude Code trae cinco mecanismos para personalizar su comportamiento: CLAUDE.md, Skills, sub-agentes, hooks y servidores MCP. Cada uno resuelve un problema distinto. Elegir mal significa una de dos cosas: llenar todas las conversaciones con contexto irrelevante o dejar fuera instrucciones críticas cuando más importan.
Después de ver la explicación de Anthropic sobre estas herramientas, me pareció útil ordenar las ideas principales y explicar cómo pienso en cada una cuando trabajo en proyectos reales.
CLAUDE.md: estándares de proyecto siempre activos
CLAUDE.md se carga en todas las conversaciones. Es el equivalente al .editorconfig o al .rubocop.yml del proyecto: reglas que se aplican sin condiciones.
Úsalo para:
- Preferencias de framework. "Usa TypeScript en modo strict" o "sigue las convenciones de Rails".
- Restricciones duras. "No modifiques el esquema de base de datos directamente" o "ejecuta los tests antes de hacer commit".
- Estilo de código. Convenciones de nombres, patrones de organización de archivos y librerías preferidas.
El principio es sencillo: si una instrucción es relevante independientemente de la tarea, pertenece a CLAUDE.md.
Lo que no debería vivir aquí: checklists detalladas, procedimientos específicos de una tarea o conocimiento de dominio que solo aplica a veces. Para eso están las Skills.
Skills: conocimiento bajo demanda
Las Skills son lo contrario de CLAUDE.md en un punto importante: se cargan bajo demanda, solo cuando Claude detecta que tu petición encaja con una skill relevante.
Piénsalo así: tu checklist de revisión de pull requests no necesita estar en contexto cuando estás escribiendo código nuevo. Se activa cuando pides una revisión. Un procedimiento de despliegue se carga cuando hablas de desplegar.
Usa Skills para:
- Conocimiento específico de una tarea. Checklists de revisión, guías de despliegue, plantillas de contenido.
- Información que solo es relevante a veces. Referencias regulatorias, documentación de APIs, guías de estilo para tipos concretos de contenido.
- Procedimientos detallados que añadirían ruido si estuvieran siempre presentes.
La diferencia es clara: CLAUDE.md significa "aplica esto siempre"; las Skills significan "aplica esto cuando aparezca este tema".
Sub-agentes: contextos de ejecución aislados
Las Skills añaden conocimiento a tu conversación actual. Mejoran el razonamiento de Claude dentro del mismo contexto. Los sub-agentes son otra cosa: se ejecutan en un contexto completamente separado.
Un sub-agente recibe una tarea, trabaja de forma independiente con su propio acceso a herramientas y devuelve resultados a la conversación principal. El contexto principal y el del sub-agente quedan aislados entre sí.
Usa sub-agentes cuando:
- Quieres delegar una tarea a un contexto de ejecución separado.
- El trabajo delegado necesita acceso a herramientas distinto al de la conversación principal.
- Quieres aislamiento entre lo delegado y lo que estás haciendo, para que un flujo no contamine al otro.
El modelo mental: una Skill es como llamar a alguien del equipo para que mire tu pantalla contigo. Un sub-agente es como enviar una tarea a alguien que trabaja en su propia mesa y vuelve con los resultados.
Hooks: automatización dirigida por eventos
Los hooks se disparan por eventos, no por peticiones. Esa es la diferencia crítica frente a las Skills.
Un hook puede ejecutar un linter cada vez que Claude guarda un archivo, validar entradas antes de ciertas llamadas a herramientas o lanzar efectos secundarios automáticos después de una acción. Son reactivos: responden a lo que Claude hace, no a lo que le pides.
Usa hooks para:
- Operaciones que deben ejecutarse cada vez que se guarda un archivo. Linting, formateo, validación.
- Validación antes de llamadas concretas a herramientas. Comprobaciones de seguridad, guardarrailes, reglas de consistencia.
- Efectos secundarios automáticos. Logging, notificaciones, sincronización.
Mientras tanto, las Skills están dirigidas por peticiones: se activan según lo que pides a Claude. Los hooks están dirigidos por eventos: se activan según lo que Claude está haciendo.
Servidores MCP: integración con herramientas externas
Los servidores MCP, o Model Context Protocol, dan a Claude herramientas y fuentes de datos externas. Mientras los otros cuatro mecanismos personalizan su comportamiento y su conocimiento, los servidores MCP amplían lo que Claude puede hacer.
Conectan Claude con sistemas externos: bases de datos, APIs, sistemas de archivos y servicios de terceros. Es la capa que le da capacidades más allá de sus herramientas integradas.
La imagen completa
Una configuración bien pensada suele combinar varios mecanismos, cada uno con su especialidad:
| Mecanismo | Cuándo aplica | Qué hace |
|---|---|---|
CLAUDE.md |
En cada conversación | Estándares y restricciones de todo el proyecto |
| Skills | Cuando el tema coincide | Conocimiento y procedimientos específicos de una tarea |
| Sub-agentes | Al delegar | Ejecución aislada de tareas con contexto separado |
| Hooks | Ante eventos concretos | Operaciones automáticas disparadas por acciones |
| Servidores MCP | Cuando hacen falta herramientas externas | Conexión con sistemas y datos externos |
La idea importante es esta: no fuerces todo dentro de un único mecanismo. Si metes checklists detalladas de revisión en CLAUDE.md, añades ruido a cada conversación. Si intentas usar Skills para validaciones automáticas cada vez que se guarda un archivo, estás usando la herramienta equivocada.
Cada mecanismo tiene un propósito claro. Haz coincidir la necesidad con el mecanismo adecuado y combínalos para conseguir una personalización completa.
Mi configuración como ejemplo
En los proyectos Rails en los que trabajo, mi enfoque suele parecerse a esto:
- CLAUDE.md: convenciones de Rails, comandos de test, restricciones de despliegue y preferencias de estilo de código.
- Skills: plantillas de creación de contenido, checklists de revisión de PRs y material de referencia para cumplimiento.
- Hooks: ejecutar RuboCop sobre archivos guardados y validar migraciones.
- Servidores MCP: conexión con herramientas de gestión de proyectos, calendario y email.
El resultado es un Claude que conoce siempre las reglas del proyecto, incorpora conocimiento especializado cuando toca, automatiza comprobaciones repetitivas y puede interactuar con servicios externos sin sobrecargar cada conversación con contexto que no viene al caso.
