Skills vs. Subagentes de Claude: Una Guía Empírica

La distinción entre una skill y un subagente de Claude es un punto de confusión frecuente. Los desarrolladores que construyen sobre Claude Code a menudo preguntan si empaquetar una pieza de lógica como una skill reutilizable o como un subagente más complejo y aislado. La documentación proporciona una guía teórica, pero la teoría a menudo se rompe frente a la realidad. Este artículo ofrece una respuesta empírica a la pregunta de claude skills vs subagents.

En SkillProof, nuestro único propósito es probar las skills de Claude Code en trabajo real. Para hacer esto de manera fiable, nuestro arnés de pruebas ejecuta cada skill candidata dentro de un subagente dedicado, para que una ejecución no pueda contaminar la siguiente. Eso nos da un punto de vista práctico, aunque vale la pena ser precisos sobre lo que nuestros datos prueban y no prueban. Tenemos registros de ejecución para 2090 skills, lo que nos dice mucho sobre cómo fallan las skills, no una comparación controlada de la misma tarea construida de ambas maneras. La diferencia entre skill y agente de Claude que se expone a continuación es nuestra interpretación de esos fallos, y mostraremos los números detrás de cada afirmación para que puedas juzgar el razonamiento por ti mismo.

Definiendo los Términos: Skill vs. Subagente

Antes de analizar los datos, es importante establecer definiciones claras. Aunque puedan parecer similares, las skills y los subagentes sirven para propósitos fundamentalmente diferentes y operan en distintos niveles de abstracción.

Una skill es una receta. Es un conjunto de instrucciones y herramientas específicas y reutilizables que aumentan las capacidades del modelo base para una tarea bien definida. Una skill se define en un archivo SKILL.md y está diseñada para ser invocada por el agente principal para realizar una acción discreta. Opera dentro del contexto del agente principal y es más adecuada para operaciones atómicas, como formatear código, generar un tipo de archivo específico o aplicar un estilo interno. Piénsalo como una tarjeta de receta que le das a un cocinero que ya sabe cocinar.

Un subagente es un trabajador completamente separado. Es una instancia independiente del modelo, iniciada por un agente primario para manejar una tarea grande, compleja o especializada. Un subagente tiene su propio contexto, su propio prompt de sistema y puede gestionar su propio estado a lo largo de un flujo de trabajo de varios pasos. El agente primario delega un objetivo de alto nivel al subagente, que luego trabaja de forma autónoma para lograrlo. Piénsalo no como una función, sino como un servicio separado al que llamas a través de una API.

Esta tabla resume las diferencias principales:

Característica	Skill	Subagente
Analogía	Una receta específica	Un chef especializado
Alcance	Tarea atómica de un solo propósito	Flujo de trabajo complejo de varios pasos
Estado	Sin estado (stateless)	Ventana de contexto propia para la ejecución; devuelve un resumen y no guarda nada después
Contexto	Comparte contexto con el agente principal	Contexto aislado e independiente
Complejidad	Un directorio: SKILL.md más scripts y archivos de referencia opcionales cargados bajo demanda	Un archivo markdown con frontmatter YAML en .claude/agents/ — prompt de sistema, lista de herramientas permitidas, modelo
Ideal para	Herramientas, aplicación de formato	Tareas autónomas, roles especializados

Cómo Nuestro Arnés de Pruebas Revela la Diferencia

Ten en cuenta que el verdadero eje de diferencia en esa tabla es el aislamiento del contexto, no el tamaño del código. Ambos se escriben como markdown simple; solo uno obtiene su propia ventana.

Nuestra metodología de pruebas se apoya en esta distinción. Como dice nuestra página de metodología, un agente ejecuta la prueba, no una persona: el mismo agente produce una línea base sin skill y un intento guiado por la skill en la misma tarea real, y luego califica si el resultado es claramente mejor que Claude sin la skill. Ejecutamos cada una de esas pruebas en su propio subagente para que la ejecución de una skill no pueda influir en la de otra.

Esta configuración fuerza un límite claro. Al subagente se le da un único objetivo: ejecutar la tarea usando la skill proporcionada. Al observar este proceso miles de veces, vemos exactamente dónde brilla la abstracción de la skill y dónde se rompe.

Las estadísticas de nuestro catálogo son reveladoras. De 2090 skills probadas hasta la fecha:

• 1291 (62%) aprueban nuestros benchmarks. Se instalan, se activan con los prompts que afirman manejar y superan la línea base sin skill en una tarea real.
• 697 necesitan configuración (setup). Según nuestra metodología, 'setup' significa que la skill necesita configuración, una skill compañera o una integración conectada antes de poder funcionar. Al revisar las notas de esas 697 pruebas, los bloqueadores están abrumadoramente relacionados con el acceso: 229 mencionan un CLI o binario externo, 171 una clave de API o credencial, 169 una cuenta o plan de pago, y 136 un servidor o integración MCP.
• 102 obtienen una puntuación INFERIOR a Claude sin adiciones. No lograron superar la línea base sin skill; algunos porque no pudieron ejecutarse en absoluto (un CLI faltante, una dependencia muerta, un ejemplo que falla), otros porque se ejecutaron y dejaron el resultado peor que Claude sin adiciones.

Si se lee con honestidad, esa distribución dice menos sobre la arquitectura de lo que se podría esperar. La categoría de 'setup' es principalmente una historia sobre credenciales y binarios faltantes, lo cual es ortogonal a si una tarea pertenece a una skill o a un subagente. Los fallos son donde realmente reside la lección de arquitectura, y llegaremos a ellos más adelante.

Cuándo Usar una Skill: El Modelo de Receta

Basado en las 1291 skills que aprueban en nuestro directorio, emerge un patrón claro. Las skills exitosas son enfocadas, sin estado (stateless) y deterministas. Son herramientas, no pensadores.

Estos son los casos de uso ideales para una skill:

1. Tareas Atómicas y Repetibles: Una skill sobresale en tareas que tienen una entrada clara y una salida predecible. Piensa en cosas para las que normalmente escribirías un pequeño script. audit-export, una skill aprobada en nuestra categoría de productividad, es un ejemplo claro: aliméntala con un informe de auditoría en markdown y emite un CSV listo para importar en Jira, Linear, Teamwork o Monday. En nuestra prueba, convirtió un informe de cinco hallazgos en filas válidas con fechas de vencimiento de fase correctas y plantillas de tickets multilínea entrecomilladas. Un trabajo, bien hecho.

2. Enseñar a Claude a Usar el Acceso que Ya Tiene: Esta es la distinción que la gente suele entender al revés, así que ten cuidado aquí: una skill no otorga nuevo acceso. No puede acceder a tu instancia de Postgres o llamar a una API de terceros por sí misma — para eso están los servidores MCP, y cubrimos esa división en Claude Skills vs MCP. Lo que hace una skill es enseñar a Claude a usar una capacidad que ya tiene, de manera correcta y consistente. Si un CLI ya está en tu PATH, una skill es el lugar adecuado para codificar cómo tu equipo lo invoca.

3. Salida Restringida y Formateo: Cuando necesitas que la salida se ajuste a una estructura rígida, una skill es la elección correcta. git-workflow, en nuestra categoría de codificación, es un ejemplo funcional: al pedirle ayuda antes de abrir un PR desde una rama de un solo commit llamada my-fix con el mensaje de commit "fixed stuff", la skill identificó las violaciones específicas de la convención y produjo reemplazos conformes. El SKILL.md contiene instrucciones estrictas sobre la forma, que el modelo sigue de manera fiable porque la tarea es limitada.

Las características de una skill bien diseñada, como se ve en nuestros ejemplos de alta puntuación, incluyen un SKILL.md conciso, una definición clara de cualquier herramienta incluida y la ausencia de lógica compleja y con bifurcaciones. Las instrucciones deben guiar al modelo, no intentar programarlo a través de la prosa.

Cuándo Usar un Subagente: El Modelo Especialista

Si una skill es una receta, un subagente es un especialista que contratas para un trabajo complejo. La decisión de claude code subagent or skill se vuelve más clara cuando la tarea requiere memoria, iteración o una persona distinta.

Nuestros datos sobre skills que fallan o tienen una configuración compleja muestran cuándo un desarrollador debería haber elegido una arquitectura de subagente desde el principio.

Estos son los casos de uso ideales para un subagente:

1. Flujos de Trabajo Complejos y de Varios Pasos: Cualquier tarea que requiera una secuencia de pasos dependientes es un trabajo para un subagente. Por ejemplo: "Investigar el rendimiento de varios algoritmos de ordenamiento para datos casi ordenados, escribir un resumen de los hallazgos y luego generar código Python que implemente el más eficiente". Este flujo de trabajo requiere mantener el contexto (la investigación) a través de múltiples pasos (resumir, codificar). La naturaleza sin estado de una skill hace que esto sea casi imposible de hacer de manera fiable.

2. Tareas que Requieren Aislamiento o una Persona Diferente: A veces, una tarea requiere una mentalidad completamente diferente a la del agente principal. Un ejemplo clásico es un agente "revisor de código". Es posible que desees que este agente sea crítico, meticuloso y se centre solo en la calidad del código. Intentar obtener esta persona de un asistente de propósito general a través de una skill es ineficiente y poco fiable. Es mucho más efectivo iniciar un subagente con un prompt de sistema adaptado a esa persona crítica.

3. Trabajo de Larga Duración que No Quieres en Tu Contexto: Una skill no es una llamada en absoluto: no se invoca nada y no se devuelve nada. Claude lee el SKILL.md en su propio contexto y sigue las instrucciones por sí mismo, dentro del bucle principal. No hay un trabajador separado al que entregarle un trabajo largo. Los subagentes son el mecanismo para eso, y desde Claude Code v2.1.198 se ejecutan en segundo plano por defecto, reservando el primer plano para cuando el resultado se necesita de inmediato. Una advertencia que vale la pena dejar clara: para simplemente esperar —consultar un endpoint, observar la finalización de una compilación— una tarea de shell en segundo plano es más barata y simple que generar un agente. Recurre a un subagente cuando el trabajo necesite juicio, no solo paciencia.

La Zona Gris: Por Qué 102 Skills Son Peor que Nada

Los datos más esclarecedores provienen de nuestros fallos, y no dicen lo que esperábamos que dijeran. Entramos en esto asumiendo que los 102 fallos serían skills que se esfuerzan por actuar como subagentes: archivos SKILL.md inflados, ramificaciones enrevesadas, procesos con estado embutidos en una receta. Al revisar las notas de prueba de los 102, solo cinco mencionan la longitud o el exceso de tokens. Esa teoría es mayormente incorrecta, y vale la pena decirlo en lugar de abandonarla silenciosamente.

Lo que realmente se descompone en dos grupos. El más grande es el fallo de dependencias: 30 de los 102 citan un CLI o binario faltante, 22 una cuenta de pago, 19 un servidor MCP faltante, 10 una clave de API ausente. skill-builder es representativo: cada llamada a herramienta depende de un servidor MCP separado que no está incluido ni se conecta automáticamente, y la skill nunca menciona el prerrequisito, por lo que un enfoque manual simple lo supera. Estos son fallos de empaquetado, no de arquitectura.

El segundo grupo es más silencioso e instructivo: skills que se instalan limpiamente, se activan correctamente y simplemente no producen nada mejor que la línea base. api-design-principles es el caso más claro. Probamos una tarea de diseño REST —un servicio de marcadores con endpoints, versionado, paginación y ejemplos JSON— con y sin la skill. Ambas ramas produjeron un trabajo correcto y comparable. aeon y arbor terminaron de la misma manera. Aquí es donde la pregunta de skill contra subagente realmente muerde: estas skills intentaron codificar todo un proceso de razonamiento en prosa, y el modelo ya era capaz de ese razonamiento. La skill añadió palabras sin añadir capacidad.

Esa es la lección de arquitectura honesta. No es que "las skills largas fallan", sino que: si lo que estás escribiendo es un procedimiento que el modelo ya sigue competentemente, una skill no añade nada; y si el procedimiento realmente necesita su propio contexto, una persona o muchos pasos dependientes, la prosa en un SKILL.md es el contenedor equivocado para ello. La respuesta a cuándo usar una skill vs. un subagente en Claude Code es esta: si tu tarea se siente como un programa, constrúyela como un subagente; si se siente como un memorando para un colega competente que ya conoce el trabajo, puede que no necesite existir en absoluto.

Una Heurística Práctica

Elegir entre una skill y un subagente no tiene por qué ser un debate académico. Nuestros datos de prueba sugieren una heurística simple y práctica:

¿La tarea es una llamada a función o un programa?

• Si tu tarea puede modelarse como una única llamada a función —toma una entrada clara y produce una salida discreta sin necesidad de recordar interacciones pasadas— es una skill.
• Si tu tarea requiere estado, memoria interna, múltiples pasos o un contexto especializado para ejecutarse —en otras palabras, si se comporta como un programa independiente— debería ser un subagente.

Al adherirse a esta distinción, los desarrolladores pueden construir soluciones más robustas, fiables y efectivas con Claude Code. Comienza con la abstracción más simple que funcione. Una skill bien definida es poderosa. Pero reconoce las señales de complejidad creciente y prepárate para pasar a una arquitectura de subagente cuando la tarea lo exija.

Lectura relacionada: si has decidido que el trabajo pertenece a un trabajador aislado, nuestra guía de subagentes de Claude Code cubre cómo definir uno y qué puede ver realmente. Y si todavía estás decidiendo si necesitas nuevo acceso en lugar de mejores instrucciones, Claude Skills vs MCP traza esa línea correctamente — es la fuente más común de confusión.

Si necesitas herramientas fiables y previamente verificadas para tareas de desarrollo comunes, hemos evaluado más de mil skills que han aprobado. Puedes navegar por función en skills de codificación y skills de documentos, o adquirir un paquete de diez skills probadas por rol por $10 — el developer toolkit es el que mejor se ajusta al trabajo descrito aquí.