Skills vs. slash commands vs. subagentes

Tabla de contenidos

Actualizado agosto 2026.

TL;DR: Los slash commands son un atajo para un prompt que escribes seguido — los invocas por nombre. Los subagentes son trabajadores paralelos con su propia ventana de contexto — tú (o Claude) los generas para una tarea acotada y recibes un resultado de vuelta. Las skills son experiencia empaquetada que Claude decide cargar por su cuenta, según lo que le pidas, sin que tengas que nombrar nada. La mayoría de la gente recurre a un agente personalizado cuando bastaría un slash command, y recurre a un slash command cuando lo que en realidad necesitaba era una skill que Claude pudiera activar por sí solo.

[Lectura de operador] Manejo 30+ agentes en producción en dos negocios, y esta confusión exacta — comando, subagente o skill — es la primera pregunta de diseño en casi todos ellos. Si la respondes mal, terminas con diez comandos cuyos nombres nadie recuerda, o con una skill tan amplia que nunca se activa de forma confiable. La solución no es una regla general, es preguntarte qué es lo que realmente varía entre una ejecución y otra.

Los tres primitivos resuelven problemas distintos

Los tres te permiten empaquetar instrucciones una vez y reutilizarlas. Ahí termina el parecido, y es exactamente por eso que la gente los confunde — desde afuera, “escribir algo corto y obtener un resultado útil” se ve igual sin importar cuál de los tres esté haciendo el trabajo por debajo.

La diferencia real es quién decide invocarlo, y en qué contexto se ejecuta:

• Un slash command lo invocas tú, por nombre. Escribes /deploy o /review, Claude lo expande en una instrucción más completa, y se ejecuta en tu conversación actual.
• Un subagente lo invocas tú o Claude, para una tarea con un límite claro. Tiene su propia ventana de contexto, hace el trabajo y reporta un resultado — no ve toda tu conversación, y tú no ves sus pasos intermedios a menos que los pidas.
• Una skill la invoca Claude, automáticamente, cuando tu petición coincide con lo que la descripción de la skill dice que cubre. Nunca escribes su nombre. Si no pides algo que la skill maneja, nunca se carga.

Esa tercera propiedad — sin invocación explícita — es la que la gente subutiliza. También es la que tiene más apalancamiento en cuanto tienes más de un puñado de flujos de trabajo empaquetados, porque dejas de tener que recordar cómo nombraste las cosas.

Slash commands: un atajo para un prompt que escribes seguido

Construye un slash command cuando el disparador es “sigo escribiendo básicamente la misma instrucción.” Un comando que siempre se resuelve en el mismo prompt subyacente, expandido a partir de un nombre corto que tú elegiste, en la conversación que ya estás teniendo. Sin contexto separado, sin invocación autónoma — tú decides cuándo se ejecuta, cada vez.

Buenos casos de uso: un checklist de lanzamiento fijo, una pasada de code review con tus reglas de la casa integradas, un atajo de “resume este PR.” El comando no necesita criterio sobre si debe ejecutarse — tú eres quien toma esa decisión al escribirlo.

El modo de fallo es construir un comando para algo que en realidad necesita que el modelo decida si aplica. Si la mitad de tu uso es “espera, ¿esto cuenta o no?” — eso es una pregunta de skill, no de comando, porque un comando no tiene forma de activarse a sí mismo.

Subagentes: trabajadores paralelos con su propia ventana de contexto

Construye un subagente cuando la tarea está acotada, es delegable, y de otro modo contaminaría tu conversación principal con pasos que no necesitas ver. Un subagente corre su propio contexto — sus propias llamadas a herramientas, su propio ida y vuelta — y entrega un resultado. Es el mismo principio sobre el que escribí en context engineering: cada llamada a herramienta y paso intermedio extra es contexto que tu hilo principal no necesita cargar, y un subagente es cómo mantienes ese ruido afuera.

Buenos casos de uso: “investiga esto y repórtame,” “corre estas cinco validaciones independientes en paralelo,” “ve a arreglar este archivo en aislamiento.” La tarea tiene un inicio, un final y un entregable — exactamente la forma que el eval harness que uso para lanzar agentes trata como una sola unidad calificable.

El modo de fallo es generar un subagente para algo que necesitaba quedarse en tu contexto principal porque el siguiente paso depende de detalles que el resumen del subagente descartó. Si te encuentras preguntándole una y otra vez al subagente “espera, ¿qué encontraste exactamente?”, el límite se dibujó mal — o lo devuelves al hilo principal, o haces que el reporte del subagente sea lo bastante estructurado para que nada se pierda en la traducción.

Skills: experiencia empaquetada que Claude carga por su cuenta

Construye una skill cuando la condición de activación es algo que Claude debería reconocer a partir de lo que pides, no algo que tú deberías tener que recordar nombrar. Una skill es una descripción más un paquete de instrucciones y scripts; Claude lee la descripción, decide si tu petición coincide, y carga las instrucciones completas solo si coincide. Nunca escribes /nombre-de-skill.

El ejemplo más claro que puedo dar es el que corre la canalización detrás de este blog. Alejandrorioja.com publica en 13 idiomas, y todo el flujo de generar → traducir → renderizar → revisar vive en una sola skill: un archivo SKILL.md que describe cuándo usarla (“generar un post nuevo,” “traducir a todos los idiomas,” “redactar una promo”), más los scripts que hacen el trabajo real. No corro cuatro comandos separados y memorizo su orden. Digo lo que quiero en lenguaje natural, y la descripción de la skill es lo bastante específica como para que Claude la detecte y ejecute los pasos correctos — de la misma forma en que la skill de anuncios de Facebook se activa con “revisa mis anuncios” sin que yo escriba el nombre de ningún comando.

Esa decisión de diseño — una skill que decide por sí misma cuándo aplica — también es la razón por la que el default de seguridad importa más aquí que con los comandos o los subagentes. Un slash command solo se ejecuta cuando tú lo escribes; una skill se ejecuta cuando el modelo cree que debería. Mi skill de contenido redacta borradores por default y requiere un paso de aprobación explícito y separado antes de que algo se publique o se suba — el mismo patrón de humano en el ciclo que uso en cualquier lugar donde una skill pueda activarse a sí misma hacia una acción con consecuencias reales.

Buenos casos de uso: cualquier cosa con una frase disparadora reconocible y un procedimiento repetible detrás — “genera un reporte,” “califica esta entrega,” “redacta un resumen para Slack.” El modo de fallo es una descripción de skill tan amplia que se activa cuando no querías, o tan estrecha que nunca se activa cuando sí querías. Escribe la descripción como se la explicarías a un empleado nuevo, no como nombrarías una función.

El marco de decisión

Pregúntate esto	Si es sí →	Por qué
¿Siempre quiero escribir un nombre para activar esto?	Slash command	Tú eres el disparador, no el modelo
¿La tarea está acotada, es delegable y es mejor mantenerla fuera de mi contexto principal?	Subagente	Ventana de contexto propia, devuelve un resultado
¿Claude debería reconocer la necesidad sin que yo nombre nada?	Skill	Se activa según coincidencia de descripción, automática
¿Toca dinero, publicación, o algo difícil de deshacer?	Cualquiera de los tres, más una compuerta de aprobación explícita	Auto-invocación no es lo mismo que auto-ejecución

La mayoría de los flujos de trabajo reales son una pila de estos, no una sola elección. Mi canalización de contenido es una skill (se activa automáticamente con “escribe un post”) que internamente llama a subagentes (uno por idioma, corriendo en paralelo) y expone un slash command (/publish) para el único paso — salir en vivo — que nunca debería pasar sin que yo lo diga explícitamente.

El error que más veo

Construir un agente personalizado completo — con su propio scheduling, su propio estado, su propio deploy — para algo que en realidad era un slash command disfrazado. Si la tarea es “corre este procedimiento exacto cuando yo lo diga,” no necesitas autonomía, memoria, ni una condición de activación. Necesitas un nombre y un prompt. Guarda la maquinaria de subagentes y skills para tareas donde el límite (subagente) o el disparador (skill) realmente están haciendo trabajo, no solo agregando infraestructura a algo que ya era simple.

La conclusión del operador

Pregunta quién decide invocarlo antes de preguntar cómo construirlo. Tú decidiendo, por nombre, cada vez → slash command. Una tarea acotada que quieres fuera de tu contexto principal → subagente. Claude reconociendo la necesidad por su cuenta → skill, con una compuerta de aprobación en cualquier cosa que no se pueda deshacer. Acierta esa única pregunta y el resto — qué va en el archivo, cuánta instrucción empaquetar — casi se resuelve solo.

Preguntas frecuentes

¿Cuál es la diferencia entre una skill de Claude y un slash command?

Un slash command se invoca explícitamente, por nombre, cada vez que quieres que se ejecute. Una skill se invoca automáticamente — Claude compara tu petición contra la descripción de la skill y la carga sin que tú nombres nada. Usa un comando cuando siempre eres tú quien decide activarlo; usa una skill cuando la condición de activación es algo que el modelo debería reconocer por su cuenta.

¿Cuándo debería usar un subagente en lugar de una skill?

Cuando la tarea está acotada y es delegable y quieres que corra en su propia ventana de contexto, separada de tu conversación principal — no por cómo se activa, sino por dónde ocurre el trabajo. Las skills y los subagentes no son mutuamente excluyentes: una skill puede generar subagentes internamente, de la misma forma en que una skill de traducción podría repartir un post entre un subagente por idioma.

¿Es seguro dejar que una skill active automáticamente acciones como publicar o gastar dinero?

Solo con una compuerta de aprobación explícita en el paso con consecuencias. La auto-invocación de la skill en sí misma está bien — solo significa que Claude reconoció lo que estás pidiendo. El riesgo es la auto-ejecución de algo difícil de deshacer. Mantén el redactar, leer y reportar dentro de la skill auto-activada; exige una confirmación separada y explícita para publicar, pagar o borrar.

¿Necesito construir los tres eventualmente?

Solo si tus flujos de trabajo realmente tienen las tres formas. Un operador solo con un puñado de tareas repetibles podría vivir enteramente con slash commands durante mucho tiempo. La necesidad de skills y subagentes aparece cuando tienes suficientes condiciones de activación distintas como para ya no recordar los nombres de los comandos, o suficientes subtareas acotadas como para que mantenerlas en tu contexto principal empiece a dañar la calidad.

---

Relacionado: La skill de Claude que gestiona mis anuncios de Facebook · Context engineering: qué entra en la ventana de contexto · Agentes de IA supervisados: cuándo pedir aprobación · El stack que uso para 30+ agentes en producción

¿Necesitas ayuda para decidir qué automatizar y cómo? Ponte en contacto — diseño sistemas de agentes en producción para equipos de operadores.