Skills vs Subagentes vs Servidores MCP

Preludio

Claude Code tiene tres formas de extender lo que puede hacer. Skills. Subagentes. Servidores MCP. Los tres añaden capacidades. Los tres residen en directorios del proyecto. Los tres se pueden compartir con un equipo. Desde fuera, parecen tres nombres para lo mismo.

No lo son. Cada uno resuelve un problema diferente en una capa diferente del sistema. Confúndelos y desperdiciarás tiempo construyendo lo incorrecto. Lo sabemos porque hicimos exactamente eso, más de una vez. Cuarenta horas en un servidor MCP que debería haber sido un archivo markdown de diez minutos. Semanas intentando que un skill consultara una base de datos a la que nunca podía acceder.

Esta guía te da el modelo mental que nos habría gustado tener desde el principio. No una comparación teórica, sino un marco de decisión práctico construido a partir de ejecutar 8 plugins en producción con más de 34 skills, múltiples subagentes y servidores MCP conectados a sistemas reales.

El Problema

En el momento en que necesitas que Claude Code haga algo más allá de sus funciones por defecto, te enfrentas a una decisión triple. El sistema de skills te permite crear prompts reutilizables como slash commands. Los subagentes te dan sesiones de IA especializadas con su propio modelo, herramientas y contexto. Los servidores MCP conectan Claude a herramientas y fuentes de datos externas.

Cada mecanismo tiene su propia estructura de directorios, su propio formato de configuración y su propia documentación. Lo que ninguna documentación deja claro es cómo se relacionan los tres entre sí, cuándo recurrir a cuál y cómo componerlos juntos.

Elegir mal es costoso. No solo en tiempo de desarrollo, sino en mantenimiento continuo, confusión del equipo y capacidades desaprovechadas. Un skill intentando hacer lo que debería hacer un servidor MCP alucinará datos. Un servidor MCP haciendo lo que debería hacer un skill desperdicia esfuerzo de ingeniería en infraestructura que sirve texto estático. Y ejecutar todo en la sesión principal de Opus cuando los subagentes podrían manejar tareas rutinarias a una fracción del coste quema dinero en cada conversación.

El Camino

Qué Son los Skills

Los skills son el mecanismo más simple. Un skill es un archivo markdown que se convierte en un slash command. Cuando se invoca, todo el contenido del archivo se inyecta en la conversación como instrucciones para que Claude las siga.

Los skills residen en .claude/skills/ con cada skill en su propio subdirectorio:

.claude/skills/
  review/SKILL.md       → /review
  migration/SKILL.md    → /migration
  deploy-check/SKILL.md → /deploy-check

Aquí tienes un skill real de producción que aplica estándares de revisión de código:

Revisa los cambios de código buscando:
- Vulnerabilidades de inyección SQL en cualquier consulta a base de datos
- Manejo de errores faltante en llamadas a APIs externas
- Castellano en todas las cadenas visibles para el usuario
- Uso consistente de snake_case en código Rust

Enfócate en: $ARGUMENTS

Proporciona correcciones como bloques de código, no solo descripciones.

Escribe /review src/handlers/auth.rs y cada desarrollador del equipo aplica los mismos estándares de revisión. El marcador $ARGUMENTS se reemplaza con lo que siga al nombre del comando.

Los skills aceptan argumentos, pueden inyectar contexto dinámico mediante comandos de shell, y se invocan manualmente con slash commands o automáticamente cuando Claude detecta relevancia. Se versionan con tu proyecto, así que cuando las convenciones cambian, una actualización de archivo se propaga a todo el equipo.

El coste es casi nulo. Crear un skill toma minutos. Modificarlo toma segundos. Sin código, sin compilación, sin conocimiento del protocolo. Cualquiera que pueda escribir un párrafo puede escribir un skill, lo que los hace particularmente valiosos para equipos que incluyen no-desarrolladores. Nuestra guía sobre skills para equipos no técnicos cubre cómo involucrar a todos.

Aquí tienes un segundo skill de producción que genera migraciones de base de datos siguiendo las convenciones del equipo:

Genera una migración de base de datos para: $ARGUMENTS

Reglas:
1. Usa el framework de migraciones en db/migrations/
2. Incluye migraciones tanto de ida como de vuelta
3. Usa castellano en todos los comentarios
4. Añade un índice para cualquier nueva columna de clave foránea
5. Formato de nombre: YYYYMMDD_HHMMSS_descripcion.sql
6. Nunca uses CASCADE en tablas de producción sin aprobación explícita
7. Incluye una consulta de verificación de rollback al final

Referencia el esquema actual en db/schema.sql para tipos de columna y nomenclatura.

Y un tercero que estandariza cómo el equipo escribe documentación de endpoints de API:

Genera documentación de API para el endpoint: $ARGUMENTS

Sigue estas convenciones:
1. Empieza con una descripción de una oración de lo que hace el endpoint
2. Lista todos los parámetros de ruta con tipos y restricciones
3. Muestra el esquema del cuerpo de la solicitud como ejemplo JSON
4. Muestra una respuesta de éxito y al menos dos respuestas de error
5. Incluye un ejemplo curl con datos de prueba realistas
6. Nota cualquier requisito de autenticación
7. Nota cualquier límite de tasa que aplique

Formato de salida: Markdown apto para inclusión en docs/api/

Cada uno de estos skills codifica conocimiento que de otro modo viviría en una página wiki que nadie lee. La diferencia es que una página wiki es pasiva. Un skill es activo. Participa en el trabajo en lugar de estar al lado.

Cuándo usar skills: La capacidad es sobre conocimiento reutilizable, convenciones o plantillas de flujo de trabajo. Listas de verificación de revisión de código. Patrones de migración. Procedimientos de despliegue. Formato de mensajes de commit. Cualquier cosa donde Claude necesite seguir instrucciones en lugar de acceder a datos externos.

Qué Son los Subagentes

Los subagentes son agentes de IA especializados que se ejecutan dentro de Claude Code con su propio system prompt, restricciones de herramientas, selección de modelo y ventana de contexto. Manejan tareas específicas y devuelven resultados a la conversación principal sin contaminarla.

Los subagentes residen como archivos markdown en .claude/agents/ para alcance de proyecto o ~/.claude/agents/ para alcance personal. El frontmatter YAML define la configuración. El cuerpo se convierte en el system prompt.

---
name: code-reviewer
description: Revisa código en busca de calidad, seguridad y estilo
model: haiku
tools: Read, Grep, Glob, Bash
disallowedTools: Write, Edit
mcpServers:
  - github
skills:
  - review
---

Eres un especialista en revisión de código. Tienes acceso de solo lectura
a la base de código y al servidor MCP de GitHub. Revisa código contra los
estándares del equipo con enfoque en seguridad, rendimiento y mantenibilidad.
Nunca sugieras cambios sin proporcionar ejemplos de código específicos.

Varias cosas están ocurriendo en esa configuración:

Selección de modelo. El campo model: haiku dirige este subagente a Haiku en lugar de Opus. Para revisión de código rutinaria (coincidencia de patrones, aplicación de estilo, detección de errores obvios), Haiku es más que suficiente. Cuesta una fracción de Opus y se ejecuta más rápido.

Restricciones de herramientas. El campo disallowedTools: Write, Edit significa que este subagente literalmente no puede modificar archivos. Lee, analiza e informa. Solo lectura por diseño, no por convención.

Acceso MCP con alcance. El campo mcpServers: - github da al subagente acceso al servidor MCP de GitHub pero nada más. Tu base de datos, tu pipeline de despliegue, tus APIs internas son todos invisibles para este subagente.

Precarga de skills. El campo skills: - review carga el skill de review en el contexto del subagente, para que siga exactamente las convenciones de revisión de tu equipo.

Contexto aislado. El subagente se ejecuta en su propia ventana de contexto. La exploración, el análisis y las lecturas de archivos no se acumulan en la conversación principal. Cuando el subagente termina, solo sus resultados vuelven.

Referencia Completa del Frontmatter de Subagentes

El frontmatter YAML soporta los siguientes campos, cada uno controlando un aspecto diferente del comportamiento del subagente:

• name (obligatorio). El identificador usado para invocar al subagente. Debe ser único dentro del proyecto. Se convierte en el nombre del agente que referencias al delegar tareas.
• description (obligatorio). Una descripción corta de lo que hace el subagente. Claude usa esto para decidir cuándo delegar tareas automáticamente, así que hazla específica. "Revisa código" es demasiado vago. "Revisa código Rust en busca de vulnerabilidades de seguridad y cumplimiento de clippy" es útil.
• model. Qué modelo usar. Las opciones incluyen opus, sonnet y haiku. Por defecto usa el modelo actual de la sesión si se omite. Aquí es donde ocurre la optimización de costes. Tareas rutinarias en Haiku, tareas analíticas en Sonnet, razonamiento complejo en Opus.
• tools. Una lista separada por comas de herramientas que el subagente puede usar. Si se omite, el subagente hereda el conjunto de herramientas por defecto. Especificar este campo explícitamente es buena práctica porque documenta para qué está diseñado el subagente.
• disallowedTools. Herramientas que el subagente nunca debe usar. Este es un mecanismo de seguridad. Un subagente de revisión con disallowedTools: Write, Edit físicamente no puede modificar tu base de código, independientemente de lo que diga su system prompt.
• mcpServers. Una lista de nombres de servidores MCP a los que el subagente puede acceder. Solo se pueden listar servidores ya configurados en el .mcp.json de tu proyecto o en la configuración. El subagente solo ve estos servidores. Todos los demás son invisibles.
• skills. Una lista de nombres de skills para precargar en el contexto del subagente. Los contenidos del skill se inyectan en el system prompt del subagente, para que siga las convenciones de tu equipo sin que se le diga que lo haga.
• permissionMode. Controla cómo el subagente maneja la aprobación de herramientas. Configúralo como bypassPermissions para operación completamente autónoma, o déjalo en el valor por defecto para flujos de aprobación estándar. Úsalo con precaución en producción.
• maxTurns. Limita cuántos turnos de conversación puede tomar el subagente antes de devolver resultados. Previene subagentes descontrolados que espiralen en exploración interminable. Un valor de 10-20 es razonable para la mayoría de tareas.
• background. Cuando se configura como true, el subagente se ejecuta concurrentemente con la sesión principal. La conversación principal continúa mientras el subagente trabaja. Los resultados se devuelven cuando el subagente termina. Útil para tareas de análisis de larga duración que no deberían bloquear el trabajo interactivo.
• isolation. Configúralo como worktree para dar al subagente su propio árbol de trabajo de git. Esto significa que el subagente puede hacer checkout de ramas, preparar archivos y hacer commits sin afectar el directorio de trabajo principal. Esencial para subagentes que realizan operaciones de git.
• hooks. Define hooks de ciclo de vida que se ejecutan en puntos específicos durante la ejecución del subagente. Los hooks pueden ejecutar comandos de shell antes o después de que el subagente comience, habilitando tareas de configuración como preparación de entorno o limpieza.
• memory. Controla si el subagente retiene memoria entre invocaciones. Cuando está habilitado, el subagente acumula contexto con el tiempo, lo cual es útil para subagentes que necesitan aprender patrones del proyecto de forma incremental.

Cuándo usar subagentes: La capacidad requiere un comportamiento diferente: un modelo diferente por razones de coste o capacidad, acceso restringido a herramientas por seguridad, contexto aislado para mantener limpia la conversación principal, o un system prompt especializado para un dominio específico.

Qué Son los Servidores MCP

Los servidores MCP conectan Claude Code a herramientas y fuentes de datos externas. Son programas que hablan el Model Context Protocol y exponen capacidades (herramientas, recursos y prompts) que Claude descubre al inicio y llama cuando es necesario.

Un servidor MCP se ejecuta como un proceso separado, ya sea localmente sobre stdio o remotamente sobre HTTP. Puede escribirse en cualquier lenguaje. Claude se comunica con él vía JSON-RPC.

{
  "mcpServers": {
    "analytics": {
      "command": "node",
      "args": ["./mcp-servers/analytics.js"],
      "env": {
        "DATABASE_URL": "postgresql://localhost:5432/analytics"
      }
    }
  }
}

La característica clave de los servidores MCP es que hacen de puente entre Claude y cosas fuera de su sesión. Una base de datos. Una API. Un pipeline de despliegue. Un sistema de monitorización. Si los datos o la acción viven externamente, un servidor MCP es el mecanismo que proporciona acceso.

Los servidores MCP mantienen sus propias conexiones, estado y ciclo de vida. Manejan recuperación de errores, caché y limitación de tasa independientemente de Claude Code. Esta separación de responsabilidades significa que tu servidor MCP puede ser tan sofisticado como necesite sin afectar la sesión de Claude.

La contrapartida es el esfuerzo de desarrollo. Escribes código real, manejas errores reales, gestionas dependencias reales. Para nuestras integraciones críticas en rendimiento, construimos servidores MCP en Rust. Para casos de uso más simples, TypeScript o Python funcionan bien.

Cuándo un CLI Es Suficiente

No todo lo externo necesita un servidor MCP. Los CLIs invocados a través de la herramienta Bash funcionan brillantemente para flujos de trabajo locales y de un solo agente. Ejecutar una migración de base de datos, llamar a un endpoint de API o comprobar el estado de un despliegue con un comando puntual son tareas donde un CLI es más simple y suficiente.

Los servidores MCP se vuelven necesarios cuando necesitas:

• Ejecución remota. La herramienta debe ejecutarse en una máquina o entorno diferente al de la sesión de Claude Code.
• Alcance de permisos. Quieres exponer capacidades específicas sin dar a Claude acceso completo al shell.
• Conexiones persistentes. La integración requiere una conexión de larga duración (pools de conexiones a base de datos, streams WebSocket, sesiones de API autenticadas).
• Operaciones con estado. La herramienta mantiene estado entre múltiples llamadas que una invocación CLI puntual no puede preservar.

Si tu caso de uso no requiere ninguno de estos, una herramienta CLI llamada a través de Bash es la elección correcta. Recurrir excesivamente a servidores MCP añade complejidad innecesaria y coste de desarrollo.

Cuándo usar servidores MCP: Claude necesita acceder a datos externos o realizar efectos secundarios que requieren ejecución remota, alcance de permisos, conexiones persistentes u operaciones con estado. Si una llamada CLI puntual a través de la herramienta Bash puede lograr la tarea, prefiere ese enfoque más simple. Reserva los servidores MCP para integraciones que genuinamente necesitan las capacidades del protocolo.

El Marco de Decisión

Después de construir lo incorrecto tres veces, este marco no ha fallado ni una:

¿Necesitas extender Claude Code?
  │
  ├── ¿Claude necesita datos externos o efectos secundarios?
  │   ├── ¿Puede una llamada CLI puntual manejarlo?
  │   │   └── Sí → Herramienta Bash con CLI
  │   └── ¿Necesita ejecución remota, alcance de permisos,
  │       conexiones persistentes u operaciones con estado?
  │       └── Sí → Servidor MCP
  │
  ├── ¿Claude necesita un comportamiento diferente?
  │   (modelo diferente, herramientas restringidas, contexto aislado)
  │   └── Sí → Subagente
  │
  ├── ¿Claude necesita instrucciones reutilizables?
  │   (convenciones, listas de verificación, plantillas, flujos de trabajo)
  │   └── Sí → Skill
  │
  └── ¿Requisito complejo?
      └── Componer los tres

Las preguntas están ordenadas por coste. Los skills cuestan minutos en crearse. Los subagentes cuestan un archivo markdown con frontmatter. Los servidores MCP cuestan tiempo real de ingeniería. Empieza por la opción más barata y solo escala cuando sea necesario.

Errores Comunes y Anti-patrones

Construir un servidor MCP para prompts estáticos. Si tu servidor devuelve el mismo texto cada vez, debería ser un skill. Los servidores MCP son para datos dinámicos, no para instrucciones estáticas. Construimos un servidor MCP en TypeScript de 400 líneas que proporcionaba prompts de revisión de código. Tenía un endpoint de health check, manejo de errores, logging y respuestas JSON estructuradas. Todo fue reemplazado por un archivo markdown de 15 líneas. El archivo markdown también era más fácil de actualizar porque cualquiera del equipo podía editarlo sin saber TypeScript.

Escribir un skill que necesita datos externos. Un skill que dice "comprueba el estado del despliegue" producirá alucinaciones. Claude no puede consultar tu sistema de despliegue a través de un prompt markdown. Eso es un problema de servidor MCP. La señal reveladora es cuando tu skill incluye frases como "busca", "consulta", "obtén" o "comprueba el estado actual de". Si el skill necesita información que no existe en la base de código, necesita un servidor MCP.

Ejecutar todo en la sesión principal de Opus. La revisión de código rutinaria, la generación de documentación y la verificación de estilo no necesitan Opus. Un subagente de Haiku con acceso de solo lectura los maneja más rápido y más barato. Rastreamos nuestro uso de tokens durante un mes y descubrimos que el 60% de los tokens de Opus se gastaban en tareas que Haiku podía manejar de forma idéntica. Eso es dinero tirado.

Ignorar la composición. Los tres mecanismos no son alternativas. Son capas. Un subagente con un servidor MCP y un skill precargado es más potente que cualquiera de los tres por separado.

Dar demasiadas herramientas a los subagentes. Un subagente que puede hacer todo es simplemente otra sesión de Opus. El valor de los subagentes viene de las restricciones. Un subagente de documentación no debería poder ejecutar comandos bash arbitrarios. Un subagente de revisión no debería poder escribir archivos. Si la lista de herramientas de tu subagente se parece a la de la sesión principal, no lo has acotado correctamente.

Omitir el campo description. Claude usa la descripción del subagente para decidir cuándo delegar automáticamente. Una descripción vaga como "ayuda con código" significa que Claude delegará de forma demasiado agresiva o no delegará en absoluto. Escribe descripciones lo suficientemente específicas para que Claude pueda compararlas con las tareas entrantes. "Analiza planes de consulta PostgreSQL y sugiere optimizaciones de índices" es una descripción sobre la que Claude puede actuar.

Hacer subagentes demasiado autónomos demasiado pronto. Empezar con permissionMode: bypassPermissions y maxTurns: 100 es buscar problemas. Comienza con permisos por defecto y un valor bajo de maxTurns. Observa lo que hace el subagente. Aumenta la autonomía solo después de haberlo visto comportarse correctamente en una variedad de tareas. Un subagente descontrolado con permisos completos puede hacer un desastre más rápido de lo que puedes darte cuenta.

Usar aislamiento cuando no lo necesitas. La opción isolation: worktree crea un árbol de trabajo de git separado. Esto es potente para subagentes que necesitan experimentar con ramas, pero añade sobrecarga. Si tu subagente solo lee archivos e informa hallazgos, no necesita su propio worktree. Reserva el aislamiento para subagentes que realizan operaciones de git o necesitan modificar archivos sin afectar tu directorio de trabajo.

Componiendo los Tres

La arquitectura real es por capas:

Capa 3: Skills (Conocimiento del Equipo)
  /review, /migration, /deploy-check, /sql-standards

Capa 2: Subagentes (Comportamiento Especializado)
  code-reviewer (Haiku, solo lectura, MCP GitHub)
  debugger (Opus, acceso completo)
  database-analyst (Sonnet, MCP PostgreSQL, skill sql-standards)

Capa 1: Servidores MCP (Conexiones Externas)
  analytics-db, deploy-pipeline, github, content-api

Considera un subagente database-analyst que compone los tres:

---
name: database-analyst
description: Analiza rendimiento de base de datos y sugiere optimizaciones
model: sonnet
tools: Read, Grep, Bash
mcpServers:
  - postgresql
skills:
  - sql-standards
disallowedTools: Write, Edit
maxTurns: 20
---

Eres un especialista en rendimiento de bases de datos. Tienes acceso de
solo lectura al servidor MCP de PostgreSQL. Analiza esquemas, planes de
consulta y uso de índices. Sigue los estándares SQL definidos en el skill
precargado. Nunca sugieras operaciones destructivas sin confirmación explícita.

Este subagente se ejecuta en Sonnet (suficientemente capaz para análisis, más barato que Opus). Puede consultar PostgreSQL a través del servidor MCP pero no puede acceder a ningún otro sistema externo. Sigue las convenciones SQL del equipo desde el skill precargado. No puede modificar archivos. Y se ejecuta en su propio contexto, así que el análisis de esquemas y la inspección de planes de consulta no saturan la conversación principal.

Aquí tienes una segunda composición para un generador de documentación:

---
name: docs-generator
description: Genera y actualiza documentación de API a partir del código fuente
model: haiku
tools: Read, Grep, Glob
disallowedTools: Write, Edit, Bash
mcpServers:
  - content-api
skills:
  - docs-api
maxTurns: 15
background: true
---

Eres un especialista en documentación. Lee el código fuente para entender
las firmas de endpoints, tipos de solicitud/respuesta y manejo de errores.
Usa el servidor MCP content-api para comprobar la documentación publicada
existente en busca de lagunas. Genera documentación siguiendo las convenciones
del skill precargado docs-api. Produce tu documentación como markdown que
puede ser revisado antes de publicar.

Este subagente se ejecuta en Haiku porque la generación de documentación es principalmente coincidencia de patrones y formato. Se ejecuta en segundo plano para que el desarrollador pueda seguir trabajando mientras se genera la documentación. No tiene acceso de escritura, así que produce documentación como texto de salida en lugar de modificar archivos directamente. El servidor MCP content-api le permite comprobar qué documentación ya existe, así que se enfoca en lagunas en lugar de duplicar contenido.

Una tercera composición para un auditor de seguridad:

---
name: security-auditor
description: Audita código en busca de vulnerabilidades de seguridad incluyendo inyección SQL, XSS y bypasses de autenticación
model: sonnet
tools: Read, Grep, Glob, Bash
disallowedTools: Write, Edit
mcpServers:
  - github
skills:
  - review
isolation: worktree
maxTurns: 30
---

Eres un especialista en seguridad. Audita la base de código en busca de
vulnerabilidades con particular atención a la validación de entrada, flujos
de autenticación y saneamiento de datos. Comprueba el historial de git para
archivos recientemente modificados en áreas sensibles a la seguridad.
Cruza referencias con issues abiertos en GitHub para cualquier problema
de seguridad reportado. Produce un informe estructurado con calificaciones
de severidad (crítica, alta, media, baja) y pasos de remediación específicos
para cada hallazgo.

Este subagente usa isolation: worktree porque necesita inspeccionar el historial de git y potencialmente hacer checkout de diferentes ramas para comparar implementaciones. Se ejecuta en Sonnet porque el análisis de seguridad requiere razonar sobre el flujo del código, no solo coincidencia de patrones. El servidor MCP de GitHub le permite verificar issues relacionados con seguridad. El skill de review asegura que siga las convenciones de revisión existentes del equipo mientras añade el enfoque específico de seguridad de su system prompt.

Tres mecanismos, compuestos en exactamente el especialista necesario. Acceso acotado, coste acotado, propósito acotado.

Para equipos construyendo flujos de trabajo en producción, el modelo de composición es cómo se obtiene el máximo de Claude Code. Los plugins pueden empaquetar los tres. Nuestra guía sobre publicar plugins en el marketplace cubre cómo empaquetar skills, agentes y servidores MCP para distribución.

Implicaciones de Coste

Antes de los subagentes, cada tarea se ejecuta en una sesión de Opus. Revisión de código en Opus. Depuración en Opus. Documentación en Opus. La ventana de contexto crece con cada tarea, y pagas por cada token.

Después de introducir subagentes, la estructura de costes cambia fundamentalmente:

Las tareas rutinarias se ejecutan en modelos más baratos. Revisión de código en Haiku. Generación de documentación en Sonnet. Aplicación de estilo en Haiku. Estas son tareas de coincidencia de patrones donde los modelos más pequeños rinden bien.

El contexto se mantiene limpio. Cada subagente obtiene una ventana de contexto fresca que contiene solo lo que necesita: su system prompt, los archivos relevantes y el skill precargado. Sin contexto acumulado de turnos de conversación anteriores.

La sesión principal se mantiene enfocada. Las decisiones arquitectónicas profundas, la depuración compleja y el refactoreo multi-archivo se quedan en la sesión principal de Opus donde el contexto completo es valioso.

Para equipos con uso intensivo de Claude Code, el enrutamiento de modelos basado en subagentes es la mayor optimización de costes disponible. Nuestra guía de optimización de costes cubre las estrategias más amplias, pero el patrón de subagentes es la base.

Migrando de una Sesión Única a una Arquitectura por Capas

La mayoría de los equipos empiezan con una única sesión de Opus manejando todo. Moverse a una arquitectura por capas no necesita suceder de golpe. Aquí tienes un camino de migración práctico.

Semana uno. Identifica tus prompts repetitivos. Dedica una semana a anotar cada vez que le das a Claude la misma instrucción dos veces. "Revisa esto por problemas de seguridad." "Genera una migración siguiendo nuestras convenciones." "Escribe documentación para este endpoint." Cada instrucción repetida es un skill esperando ser creado. Extrae cinco o seis de ellos en .claude/skills/ al final de la semana.

Semana dos. Identifica tus tareas rutinarias. Mira tu uso de Claude Code y categoriza las tareas por complejidad. ¿Qué tareas son coincidencia de patrones rutinaria que Haiku podría manejar? ¿Cuáles requieren razonamiento genuino que necesita Sonnet u Opus? Crea tu primer subagente para la tarea rutinaria más común. Un subagente code-reviewer en Haiku con acceso de solo lectura es un buen punto de partida porque es de bajo riesgo y alta frecuencia.

Semana tres. Añade servidores MCP para acceso externo. Si tus subagentes o la sesión principal necesitan consultar bases de datos, comprobar estado de despliegues o interactuar con APIs, construye servidores MCP para esas integraciones. Empieza con la integración que usas con más frecuencia. Un servidor MCP de PostgreSQL o uno de GitHub cubre las necesidades primarias de la mayoría de los equipos.

Semana cuatro. Compón y refina. Ahora que tienes skills, subagentes y servidores MCP, empieza a componerlos. Dale a tus subagentes acceso a servidores MCP relevantes y precarga skills relevantes. Ajusta maxTurns basándote en lo que observes. Afina la selección de modelo basándote en la calidad del resultado. Este es un proceso iterativo.

El principio clave es empezar con skills porque son gratuitos. Luego añade subagentes porque son baratos. Luego añade servidores MCP porque son necesarios. No construyas los tres a la vez. Cada capa debería demostrar su valor antes de añadir la siguiente.

Introduciendo Subagentes en Tu Equipo

Conseguir que un equipo adopte subagentes requiere más que colocar archivos de agentes en el repositorio. Los equipos que han estado usando skills y servidores MCP tienen flujos de trabajo establecidos. Los subagentes cambian la dinámica al introducir delegación, y la delegación requiere confianza.

Empieza con un subagente de solo lectura. La introducción más segura es un subagente que no puede modificar nada. Un revisor de código o un verificador de documentación que solo lee e informa. Nadie se siente amenazado por un agente de solo lectura. Añade valor sin riesgo. Deja que el equipo lo use durante un sprint y vea los resultados.

Comparte los datos de coste. Ejecuta una comparación de dos semanas. Rastrea el uso de tokens y el coste con y sin subagentes para tareas comparables. Cuando los desarrolladores vean que un subagente de Haiku cuesta una décima parte de lo que cuesta la misma tarea en Opus, la adopción se convierte en una decisión pragmática en lugar de filosófica.

Deja que los desarrolladores creen sus propios subagentes. No impongas nada. Proporciona el patrón, los ejemplos de referencia y la documentación del frontmatter. Los desarrolladores que vean el beneficio crearán subagentes para sus propios flujos de trabajo. Los que resulten útiles serán adoptados naturalmente por el resto del equipo a través de revisiones de código y boca a boca.

Establece convenciones de nomenclatura temprano. Una vez que múltiples desarrolladores empiecen a crear subagentes, las colisiones de nombres y los propósitos poco claros se convierten en un problema. Acuerda una convención de nomenclatura desde el principio. Nosotros usamos el patrón dominio-acción, como db-analyst, code-reviewer, docs-generator, security-auditor. El nombre debería hacer obvio el propósito del subagente sin leer el archivo.

Documenta lo que cada subagente puede y no puede hacer. No en un documento separado. En el propio archivo del subagente. El cuerpo del system prompt debería declarar claramente el alcance, las capacidades y las limitaciones del subagente. Cuando un desarrollador invoca un subagente y este hace exactamente lo que se prometió, la confianza se construye rápidamente.

Gradúa los permisos gradualmente. Empieza cada nuevo subagente con disallowedTools: Write, Edit y un maxTurns bajo. A medida que el equipo gane confianza en el comportamiento de un subagente, relaja las restricciones. Un subagente que ha estado revisando código de forma fiable durante un mes probablemente puede recibir la confianza de background: true para operación asíncrona. Pero empieza restringido y gana confianza.

Construyendo Agentes Personalizados

Para una inmersión más profunda en la construcción y configuración de subagentes, incluyendo patrones de composición y ejemplos reales de desarrollo de plugins en producción, nuestra guía sobre construir agentes Claude personalizados recorre el proceso completo.

La relación entre subagentes y los otros mecanismos de extensibilidad en la comparación de plugins, servidores MCP y skills proporciona contexto arquitectónico adicional para equipos planificando su estrategia de extensión.

La Lección

Los tres mecanismos de extensibilidad de Claude Code no son opciones intercambiables. Son capas en una arquitectura de extensión, cada una resolviendo una clase distinta de problema.

Los skills codifican conocimiento. Son rápidos de crear, no requieren código y hacen ejecutables las convenciones del equipo. Empieza aquí.

Los subagentes especializan comportamiento. Ejecutan modelos diferentes, restringen herramientas, aíslan contexto y se componen con servidores MCP y skills. Úsalos cuando necesites que Claude trabaje de forma diferente para tareas específicas.

Los servidores MCP hacen puente con sistemas externos. Conectan Claude a bases de datos, APIs y herramientas que existen fuera de su sesión. Constrúyelos cuando Claude necesite acceder al exterior.

La decisión toma un segundo una vez que internalizas el marco. Y los tres se componen magníficamente en especialistas con alcance definido que hacen exactamente lo que necesitas al coste exacto correcto.

Conclusión

Pasamos meses aprendiendo esto construyendo lo incorrecto. Un servidor MCP que debería haber sido un skill. Un skill que necesitaba ser un servidor MCP. Sesiones de Opus que deberían haber sido subagentes de Haiku.

El triángulo de extensibilidad es simple. Skills para conocimiento. Subagentes para comportamiento. Servidores MCP para conexiones. Y composición para cualquier cosa compleja.

Empieza auditando tu configuración actual de Claude Code. Si estás ejecutando todo en una sesión con un modelo, casi con certeza estás pagando de más por tareas rutinarias. Si estás construyendo servidores MCP que sirven prompts estáticos, estás sobre-ingeniando archivos markdown. Si no tienes ningún skill, estás repitiendo instrucciones que deberían codificarse una vez.

El camino de migración es incremental. Extrae tus prompts repetidos en skills esta semana. Crea tu primer subagente de solo lectura la semana que viene. Construye un servidor MCP para tu sistema externo más usado la semana siguiente. Cada capa demuestra su valor independientemente, y la composición de las tres es donde aparece el verdadero apalancamiento.

El mecanismo adecuado para el problema adecuado. Tres capas, tres propósitos, cero solapamiento.