Skills, Subagents, Commands y MCP: cuándo usar cada uno en Claude Code

La confusión entre los cuatro es real

Uno de los hilos de Claude Code más votados en Hacker News últimamente no es una petición de función ni un informe de error. Es una queja sobre el menú. Ahora hay varias formas solapadas de lograr lo mismo, un slash command, un skill, un subagent, un servidor MCP, y ninguna guía clara de cuándo usar cuál. La gente entrega trabajo real con la herramienta y sigue adivinando a qué primitiva pertenece cada tarea.

Yo uso Claude Code todos los días en un monorepo, una automatización de carga en vivo y las rutinas que mantienen este sitio. He elegido la primitiva equivocada las veces suficientes como para haber pagado por la respuesta. Esta es la decisión que uso de verdad, con la mecánica que hace obvia la elección una vez que la ves.

La trampa es que los cuatro parecen similares desde fuera. Dos se invocan igual, escribiendo una barra y un nombre. Dos hacen trabajo. Dos amplían Claude. Así que la gente los ordena por un tamaño o una intuición vaga, un skill para lo pequeño, un subagent para lo grande, y ese modelo mental es incorrecto. Ordénalos por mecanismo y el solapamiento desaparece.

Los dos ejes que lo aclaran todo

Olvida el tamaño. Cada uno de estos cuatro queda definido por dos preguntas.

¿Quién aprieta el gatillo, tú o el modelo? Un slash command solo se dispara cuando lo escribes. Un skill puede dispararse solo: Claude lee su descripción de una línea, y cuando tu petición encaja, se carga a sí mismo. Esa es toda la diferencia entre las dos cosas que empiezan con una barra.

¿Dónde se ejecuta el trabajo, en tu contexto, en uno sellado o fuera de Claude por completo? Los commands y los skills se ejecutan en línea, en la misma conversación, y lo que producen queda delante de ti. Un subagent se ejecuta en una ventana de contexto separada con sus propias herramientas y memoria, y devuelve solo un resumen, así que la exploración nunca toca tu hilo principal. MCP se ejecuta fuera de Claude Code por completo: es un protocolo que permite al modelo llamar a otro sistema.

Sostén esos dos ejes y las cuatro primitivas dejan de competir. Son respuestas a preguntas distintas.

Slash commands: un prompt que activas tú

Un slash command personalizado es el más simple de los cuatro. Es un prompt guardado, o una directiva de sesión, que invocas a mano. Escribes el command y las instrucciones guardadas entran en la sesión actual. Se ejecuta en tu contexto principal, ahora mismo, porque lo has pedido.

Recurre a un command cuando quieras ser tú quien decida cuándo ocurre. Una lista de verificación previa que ejecutas antes de cada release. Una pasada de revisión que quieres bajo demanda, no automáticamente. Una instrucción repetida que de otro modo pegarías por centésima vez. El rasgo que lo define no es lo que contiene, es que el momento es tuyo.

Lo que un command no es: no es algo que Claude vaya a usar por su cuenta, y no se ejecuta en aislamiento. Si te descubres deseando que Claude simplemente supiera cuándo ejecutarlo, no quieres un command. Quieres un skill.

Skills: un prompt que Claude activa solo

Un skill es la misma idea que un command, instrucciones reutilizables, con una diferencia que lo cambia todo: Claude puede invocarlo sin que se lo digan. Cada skill lleva una descripción breve en su frontmatter, y esa descripción está en contexto a bajo coste. Cuando tu petición encaja con ella, el skill completo se carga en línea y Claude sigue razonando con esas instrucciones en la mano.

Esta es la primitiva que la gente infrautiliza, porque el beneficio es invisible hasta que se dispara. La descripción de un skill es una oferta permanente: cuando una pregunta se parezca a esto, así la manejo. No escribes nada. Claude reconoce la forma de la tarea y trae el manual. Un command hace que tú recuerdes invocar el procedimiento correcto; un skill hace que Claude lo recuerde por ti.

Dos hechos mecánicos conviene conocer antes de apoyarte en los skills. Primero, las descripciones siempre están cargadas pero el contenido completo solo se carga al usarse, así que una docena de skills bien escritos cuestan muy poco hasta que uno hace falta de verdad. Segundo, una vez que un skill se carga, su contenido permanece en contexto el resto de la sesión, así que los archivos de skill inflados gravan en silencio cada turno posterior. Mantenlos ajustados; separa el material de referencia en archivos de apoyo que el skill solo cargue cuando sea necesario.

Usa un skill cuando el disparador sea un tipo de tarea y no un momento que tú elijas: convenciones que tu código siempre deba seguir, un procedimiento de despliegue, un libro de reglas de dominio. Usa un command cuando quieras el momento en tus propias manos. La misma materia prima, disparador opuesto.

Subagents: un segundo Claude en una sala sellada

Aquí es donde el instinto de lo pequeño frente a lo grande engaña de verdad. Un subagent no es un skill más grande. Es algo estructuralmente distinto: una instancia de Claude separada, lanzada en su propia ventana de contexto, con sus propias herramientas y sin acceso a tu conversación. Hace su trabajo fuera de la vista y devuelve solo el resultado.

El propósito de un subagent no es capacidad, es aislamiento. Cuando necesito escanear una base de código grande, filtrar un montón de logs o investigar una pregunta que va a generar páginas de callejones sin salida antes del único párrafo útil, no quiero ese desorden en mi hilo principal. Un subagent absorbe todo eso y devuelve la conclusión. Mi contexto queda limpio; la exploración desaparece. El aislamiento es la característica.

Compra dos cosas más. Paralelismo: varios subagents pueden ejecutarse a la vez e informar de forma independiente, que es como cubres mucho terreno rápido. Y control: cada uno puede correr con un modelo más barato o un conjunto de herramientas restringido, así que el trabajo pesado de fondo no cuesta dinero de modelo puntero ni tiene permisos amplios.

El coste es real y conviene nombrarlo: sin ida y vuelta. Un subagent termina y devuelve; no puedes dirigirlo a mitad de tarea, y su contexto separado gasta sus propios tokens. Así que un subagent se gana su sitio cuando el trabajo es autónomo, ve a buscar esto, ve a analizar aquello, vuelve con la respuesta, no cuando necesitas una conversación. Un matiz difumina la línea: a un skill se le puede pedir que se ejecute en un contexto bifurcado, lo que en la práctica lo convierte en un subagent. Útil, pero decide por el eje, no por la sintaxis: ¿quieres aislamiento o no?

MCP: un puente al mundo exterior

Los tres primeros son orquestación de prompts, distintas formas de ordenar instrucciones y contexto dentro de Claude Code. MCP es una categoría totalmente distinta. El Model Context Protocol conecta Claude con sistemas que de otro modo no puede tocar: una base de datos Postgres, la API de GitHub, Sentry, Stripe, tu Slack, Notion o Gmail. Expone herramientas que el modelo puede llamar, datos que puede leer y prompts que puede usar.

Así que la pregunta de MCP nunca es si esto es reutilizable o si debería aislarse. Es más simple: ¿el trabajo requiere alcanzar un sistema externo? Crear una incidencia real, consultar la base de datos de producción, publicar en un canal, sacar un panel en vivo, eso es MCP, porque ninguna cantidad de prompting ingenioso permite a Claude alcanzar eso por su cuenta. Necesita una conexión, y MCP es la conexión.

La distinción que hace tropezar es skill frente a MCP, y es limpia una vez enunciada: un skill es conocimiento, MCP es capacidad. Un skill puede contener tus convenciones para redactar una buena incidencia. Solo un servidor MCP puede crearla de verdad. Instrucciones frente a alcance.

Un coste de producción a respetar: las definiciones de herramientas de cada servidor MCP conectado consumen contexto, así que enchufar diez servidores que apenas usas es un impuesto lento sobre cada sesión. Claude Code aplaza la lista completa de herramientas hasta que hace falta, lo que ayuda a escalar, pero la disciplina sigue vigente: conecta lo que usas, poda lo que no.

El árbol de decisión que uso de verdad

Cuatro preguntas, en orden. El primer sí es tu respuesta.

Uno. ¿El trabajo necesita alcanzar un sistema externo, una base de datos, una API, un servicio de terceros? Si es así, es un servidor MCP. Nada más puede cruzar esa frontera.

Dos. ¿Son instrucciones reutilizables o material de referencia, y quieres que Claude lo use automáticamente? Si es así, es un skill.

Tres. ¿Son instrucciones reutilizables que prefieres activar tú mismo, en tu propio momento? Si es así, es un slash command.

Cuatro. ¿Es trabajo autónomo cuya exploración quieres mantener fuera de tu contexto principal, o ejecutar en paralelo? Si es así, es un subagent.

Falla en esto y los síntomas son específicos. Construye un subagent para algo que necesitaba una conversación y pelearás con su naturaleza de un solo disparo. Escribe un skill para algo externo y describirá una acción que nunca podrá realizar. Usa un command donde querías automatización y seguirás olvidándote de ejecutarlo. La primitiva equivocada no falla a gritos. Simplemente hace, en silencio, que el trabajo sea más difícil de lo que debería.

Cómo se combinan en el trabajo real

Las primitivas no son rivales; los buenos montajes las combinan. Una forma concreta de mi propio trabajo: una tarea arranca desde un command que activo yo. Claude, razonando a través de ella, trae un skill que lleva las convenciones de cómo debe hacerse este tipo de trabajo. Despliega subagents para investigar las incógnitas en aislamiento, cada uno devolviendo un resumen ajustado en lugar de una avalancha de exploración. Y llega a través de MCP para leer los datos en vivo y, una vez que apruebo, para actuar sobre el mundo exterior.

Ese es el modelo mental real. No cuál es mejor, no están en el mismo eje. Es quién lo activa, dónde se ejecuta y si necesita salir al exterior. Responde esas tres y el menú que frustró a todo un hilo de Hacker News vuelve a ser cuatro herramientas que hacen exactamente un trabajo cada una.