Los cuatro mecanismos que extienden Claude Code resuelven problemas genuinamente separados. Una habilidad le enseña a Claude cómo quieres que se haga algo. Un hook garantiza que algo suceda, independientemente de lo que Claude decida. Un subagente protege el contexto de la conversación principal delegando trabajo enfocado a un proceso paralelo limpio. Un servidor MCP le da a Claude acceso a un sistema al que literalmente no puede llegar sin él. Si eliges el equivocado, terminarás con una "regla" que el modelo puede ignorar tranquilamente, o una dependencia MCP añadida donde simples instrucciones hubieran bastado.
Elige un mecanismo según la tarea
Comienza con una única pregunta diagnóstica: ¿qué falta realmente?
Si la respuesta es "Claude no sabe cómo quiero que se haga esto", esa es una habilidad. Formato de mensaje de confirmación, plantillas de descripción de PR, política de lint, listas de verificación de revisión. Todo es conocimiento empaquetado, cargado bajo demanda cuando es relevante, y se ejecuta dentro de tu sesión existente sin dependencia externa.
Si la respuesta es "algo debe suceder en un punto fijo y no puedo confiar en que el modelo lo recuerde", ese es un hook. Los hooks se disparan en eventos del ciclo de vida como PreToolUse o PostToolUse y se ejecutan completamente fuera del contexto de Claude. El modelo no puede anularlos. CodingNomads lo describe bien: los hooks se ejecutan determinísticamente sin participación del LLM y sin costo de contexto.
Si la respuesta es "esta subtarea traería 40 lecturas de archivo a mi hilo principal", ese es un subagente. Ventana de contexto separada, presupuesto de tokens propio, reporta un resumen. Silencioso y enfocado.
Si la respuesta es "Claude necesita tocar realmente un sistema al que no puede llegar", ese es un servidor MCP. Lecturas de bases de datos, publicaciones en Slack, APIs internas, páginas de Notion. Estos no son problemas de conocimiento, son problemas de conectividad, y solo MCP los resuelve.
Y CLAUDE.md está encima de todos ellos como la capa siempre activa. Cada sesión la lee automáticamente. Mantenla bajo 200 líneas, según la guía del mismo Anthropic, de lo contrario las restricciones importantes se entierran y se ignoran.
Instrucciones, acceso a herramientas, eventos y contexto aislado
Lo que cada mecanismo realmente controla:
- Habilidades: instrucciones y contexto, cargados bajo demanda en la conversación actual. Sin llamadas externas. Sin activador de evento. El modelo decide cuándo una habilidad es relevante en función de la descripción en su encabezado.
- Servidores MCP: acceso a herramientas. Claude llama a las herramientas MCP de la misma manera que llama a cualquier herramienta, pero la ejecución ocurre en un proceso separado a través de JSON-RPC. Un servidor MCP conecta Claude a sistemas externos; una habilidad le enseña a usarlos bien una vez que está conectado.
- Hooks: eventos del ciclo de vida. SessionStart, PreToolUse, PostToolUse,
PreCompact. Se ejecutan determinísticamente. Un hook que bloquea un comando destructivo lo bloqueará cada vez, sin importar si Claude pensó que era una buena idea. - Subagentes: contexto aislado. Le das un breve a un subagente, trabaja independientemente, devuelve un resultado. Un subagente de escritura de pruebas no necesita saber sobre tu pipeline de despliegue. Un subagente de documentación no necesita tu esquema de base de datos. Esa separación es el punto completo.
Las habilidades y comandos merecen una breve nota aquí porque es fácil confundirlos. Según la documentación oficial de habilidades, los comandos personalizados se incorporan en las habilidades, no son un sexto sistema separado. Comparten el mismo modelo de autoría SKILL.md. Más sobre eso en la siguiente sección.
El desglose de Inventive HQ lo plantea claramente: "Una habilidad cambia el comportamiento, un subagente protege el contexto, un servidor MCP añade capacidad, y un hook garantiza que una acción se ejecute determinísticamente en un evento, sin importar lo que el modelo decida hacer".
Dónde encajan los Slash Commands en las Skills
Los slash commands personalizados no son un mecanismo separado que existe junto a las skills. Son la superficie de invocación para las skills. Cuando escribes /deploy o /review, estás activando una skill por nombre. Esa skill contiene las instrucciones, cualquier archivo de referencia vinculado, y el contexto para cómo Claude debe manejar esa tarea.
La tarea de autoría (escribir un SKILL.md con buenas descripciones en frontmatter), la tarea de búsqueda de comandos (decidir qué nombre de comando exponer), y la tarea de comparación de mecanismos (elegir entre skills y hooks) son tres preocupaciones de lectura diferentes. Resulta que comparten un formato de archivo, que es parte de por qué persiste la confusión.
Si estás decidiendo si usar una skill en absoluto, la pregunta siempre es: ¿es este conocimiento que de otro modo volvería a escribir, o es algo que necesita ejecutarse en un evento independientemente de la entrada? Lo primero es una skill, posiblemente expuesta como un comando. Lo segundo es un hook.
Para una mirada más profunda sobre cómo CLAUDE.md alimenta el contexto del proyecto en cada sesión, la guía CLAUDE.md para agencias cubre el alcance y la estructura de archivos en detalle.
Componer Mecanismos para una Tarea de Repositorio
La mayoría de los configuraciones del mundo real no eligen un mecanismo y listo. Componen dos o tres. Aquí hay un escenario ilustrativo mostrando cómo funciona eso para un flujo de trabajo de PR:
| Tarea | Mecanismo | Razón |
|---|---|---|
| Aplicar formato de descripción de PR | Skill | Conocimiento empaquetado; se carga cuando Claude escribe un PR |
| Obtener contexto de ticket de Linear | Servidor MCP | Sistema externo al que Claude no puede acceder nativamente |
| Escanear >20 archivos para análisis de impacto | Subagenteúltima | Mantiene el hilo principal limpio; devuelve un resumen enfocado |
| Bloquear commits si fallan las pruebas | Hook | Garantía determinista; no puede ser cuestionada por el modelo |
| Regla de naming de rama siempre activa | CLAUDE.md | Nunca condicional; necesario en cada sesión |
| Auto-ejecutar linter antes de escribir archivo | Hook en PreToolUse | Necesita dispararse en un evento, no en el criterio de Claude |
El ejemplo del linter merece una pausa. El análisis de Moeed lo captura bien: "La parte de 'ejecutar el linter' es una habilidad, Claude puede hacerlo, solo quieres consistencia. La parte de 'solo hacer commit si pasa' es un hook, eso es una garantía, no una directriz. Se componen."
Ese es el modelo mental práctico. Las habilidades y los hooks a menudo funcionan en la misma tarea desde ángulos diferentes.
Errores Comunes y Cómo Corregirlos
Algunos patrones se repiten:
- Servidor MCP para algo que era solo conocimiento. Si te encuentras configurando un servidor MCP para que Claude "acceda" a tu guía de estilo, detente. Eso es una habilidad. MCP es para conectividad con sistemas vivos, no para cargar documentación en markdown.
- Regla en CLAUDE.md que en realidad es un hook. Poner "nunca ejecutar rm -rf" en CLAUDE.md es una sugerencia que el modelo técnicamente puede eludir. Un hook en
PreToolUseque bloquea la herramienta Bash en ese patrón es un freno total. Si una regla necesita estar garantizada, pertenece a un hook, no al contexto. - Habilidad para una tarea que necesita su propio presupuesto de contexto. Si el trabajo implica leer docenas de archivos, el consumo de tokens en tu sesión principal se compone rápidamente. Genera un subaagente. Recibe un prompt enfocado, hace el trabajo y devuelve un resumen. Tu contexto principal se mantiene coherente.
- Subaagente para algo que solo necesitaba una instrucción. Los subaagentes tienen sobrecarga. Si Claude solo necesita conocer tu convención de migración, escribe una habilidad. No generes un worker aislado para un problema de conocimiento.
- CLAUDE.md sobrecargado. Pasados 200 líneas, la orientación de Anthropic dice que las restricciones críticas se pierden. Mueve contenido de referencia a habilidades o divide en archivos
.claude/rules/que se carguen condicionalmente según coincidencia de ruta.
Si estás construyendo un workflow de Claude Code desde cero y quieres un punto de partida estructurado, la guía de workflow de Claude Code te lleva a través de cómo secuenciar estas capas para una configuración real de repositorio.
Sigue la Guía de Implementación Relevante
Una vez que hayas identificado el mecanismo correcto, los caminos de implementación se dividen claramente. Este post es una capa de navegación y comparación, no un tutorial de configuración. Aquí es a dónde ir después, por mecanismo:
- Configuración de hooks: la guía de hooks de Claude Code cubre eventos del ciclo de vida, tipos de manejador y cómo escribir manejadores shell e HTTP que se ejecuten de forma determinística.
- Subaagentes: la guía de subaagentes de Claude Code explica cómo dar instrucciones a un subaagente, alcanzar sus permisos de herramienta y manejar el resultado en la sesión principal.
- Subaagentes: la guía de subaagentes de Claude Code
- Guía de producción de servidores MCP
No intentes leer los cuatro a la vez antes de decidir qué mecanismo aplica. Así terminas tres horas configurando hooks cuando necesitabas una habilidad de dos líneas.
FAQ
¿Es CLAUDE.md un mecanismo que debería incluir en esta decisión?
Sí, pero es un tipo de decisión diferente. CLAUDE.md no se selecciona en el momento de la tarea. Se carga automáticamente cada sesión. La pregunta para CLAUDE.md es: "¿necesita Claude esta información cada vez, sin condiciones?" Si es sí, ponla ahí. Si la instrucción solo importa para ciertas tareas, pertenece a una habilidad con una descripción de frontmatter específica.
¿Puede una habilidad activar una llamada de servidor MCP?
Sí. Una habilidad puede instruir a Claude para usar herramientas MCP disponibles como parte de un flujo de trabajo. La habilidad proporciona el cómo (qué pedir, en qué secuencia, con qué expectativas de formato) y el servidor MCP proporciona el acceso. Son complementarios, no compiten.
¿Cuál es la diferencia entre un subagente y un equipo de agentes?
Un subagente es un trabajador que envías desde la sesión principal para manejar una subtarea enfocada. Un equipo de agentes es un conjunto de sesiones pares que pueden comunicarse directamente entre sí, adecuado para trabajo colaborativo genuinamente paralelo. Para la mayoría de tareas de repositorio, un subagente es lo correcto. Los equipos de agentes tienen sentido cuando múltiples líneas de trabajo independientes necesitan coordinarse en lugar de que una sesión delegue hacia abajo.
¿Tienen los hooks acceso al contexto de Claude?
No. Ese es el punto. Los hooks se ejecutan fuera del contexto de Claude y el modelo no puede anularlos. Esto los convierte en la herramienta correcta para garantías duras: verificaciones de seguridad, pasadas de linting obligatorias, patrones de archivo bloqueados. El trueque es que un hook no puede tomar decisiones matizadas basadas en lo que Claude entiende sobre la tarea. Se dispara en el evento y ejecuta su manejador.
¿Cuándo tiene sentido usar los cuatro mecanismos juntos?
Cuando tienes un flujo de trabajo con múltiples modos de fallo distintos: una brecha de conocimiento (habilidad), un requisito de conectividad (MCP), un riesgo de desbordamiento de contexto (subagente), y al menos una acción que debe garantizarse independientemente del criterio del modelo (hook). La mayoría de tareas simples necesitan uno o dos mecanismos. Llegar a los cuatro en cada tarea añade sobrecarga sin beneficio.
La distinción más clara en toda esta comparación: una habilidad es una sugerencia que Claude lee y sigue; un hook es una regla que el arnés ejecuta, le agrade o no a Claude. Equivocarse en eso y tu "regla de seguridad" es solo una solicitud educada.