Claude Skills Custom Agents: El 80% de tu Prompt de Sistema Debería Ser una Skill, y No lo Sabes

# Claude Skills Custom Agents: El 80% de tu Prompt de Sistema Debería Ser una Skill, y No lo Sabes

Usas Claude Skills como si fuesen prompts de sistema con botón de guardar. Yo también lo hice. Hasta que entendí que estaba dejando el 80% del valor sobre la mesa.

El 90% de los desarrolladores trata Claude Skills como "system prompts 2.0". Escribes un bloque de instrucciones enorme, le pones nombre, y ya tienes tu custom agent.

*Eso no es una Skill. Eso es un monolito con etiqueta. *

El problema no es que funcione mal. Es que funciona justo lo suficiente para que no te des cuenta de lo que estás perdiendo. Cuando metes 50 líneas de instrucciones contradictorias en una Skill monolítica, Claude hace lo que puede. Pero el resultado es comportamiento borroso, conflictos internos, y un sistema que no puedes depurar porque todo está mezclado en el mismo prompt.

La realidad de Claude Skills no es lo que te cuentan. Y es mucho más potente de lo que imaginas.

Para entender por qué este enfoque es tan importante, tenemos que mirar cómo funcionan realmente los modelos de lenguaje por dentro. Claude no ejecuta instrucciones como un programa secuencial. No lee tu prompt como un script Python donde cada línea se ejecuta en orden. Claude procesa tu prompt como un campo de atención distribuida: cada instrucción compite por peso en el espacio latente del modelo. Cuando escribes "sé conciso" y "sé detallado" en el mismo bloque, el modelo no resuelve la contradicción — hace una media ponderada. Obtienes un comportamiento que no es ni conciso ni detallado, sino un término medio incómodo que no satisface ningún escenario real.

Esta es la razón fundamental por la que las Skills monolíticas fallan: la atención de Claude resuelve composición, no contradicción interna. Si separas las instrucciones en Skills con condiciones de activación mutuamente excluyentes, Claude puede aplicar el comportamiento completo para cada contexto. No tiene que promediar. Puede ser extremadamente conciso en un turno y extremadamente detallado en el siguiente. Eso es composición.

---

❌ El Error: La Skill Monolítica Como "Persona"

La mayoría de los desarrolladores piensa: "Una Skill = un asistente especializado". Así que escriben esto:

Este prompt tiene entre 5 y 7 contradicciones internas. "Sé conciso" vs "sé detallado". "No expliques cosas obvias" vs "no asumas conocimiento". Claude va a hacer promedios de comportamiento. Va a ser mediocre en todo porque no sabe cuándo activar cada instrucción.

El resultado: un custom agent que hace todo "más o menos bien" y nada excepcional.

Y hay un problema adicional que no se ve a simple vista: la depurabilidad. Cuando algo sale mal en una Skill monolítica, ¿cómo sabes qué instrucción causó el problema? No puedes. Está todo mezclado. Tienes que leer las 50 líneas, hacer hipótesis, probar cambios, y esperar que no empeore otra parte del comportamiento. Es como depurar una función de 500 líneas con 15 responsabilidades mezcladas. Lo sabes porque lo has vivido en código. Pues aquí es exactamente igual.

---

✅ El Acierto: Micro-Skills Atómicas que Se Componen

Claude Skills están diseñadas para composición modular. No para ser una persona. Para ser un conjunto de capacidades que se activan cuando toca.

El principio es el mismo que el single-responsibility principle del desarrollo de software. Cada Skill debería hacer una cosa y hacerla bien.

Este bloque tiene 15 líneas. Hace una cosa. La hace bien. Y se desactiva cuando no toca.

Ahora compón varias así:

code-debug-analyzer: solo diagnostica errores
code-style-enforcer: solo revisa estilo y convenciones
security-auditor: solo busca vulnerabilidades
test-generator: solo escribe tests

Las activas todas juntas en una conversación. Cada una se activa cuando corresponde. No hay conflicto porque ninguna intenta hacer lo que hace la otra.

Fíjate en lo que ocurre aquí a nivel de atención de Claude. Cuando el usuario pega un bloque de código con un error sintáctico, se activa code-debug-analyzer y security-auditor puede ignorar ese input. Pero cuando el usuario pega el mismo código pidiendo "revísame la seguridad", se activa security-auditor y el debugger permanece en segundo plano. Claude no tiene que decidir qué quiere el usuario: las condiciones de activación se lo dicen explícitamente.

Esto es exactamente lo que hace que el sistema sea escalable. Puedes tener 20 Skills activas sin que se pisen unas a otras, siempre que sus condiciones de activación estén bien definidas y no se solapen en el mismo contexto.

---

El Marco de Micro-Skills Atómicas

Después de meses de prueba y error con Skills en producción —incluyendo agentes que gestionan contenidos legales, directorios de gestorías, y sistemas multi-dominio— he destilado el proceso en 5 pasos.

1. Identifica tus comportamientos atómicos

Coge tu caso de uso y divídelo en capacidades que no se puedan dividir más.

Una Skill de "traductor" no es atómica porque implica detectar idioma, traducir, y formatear. Sepáralo:

language-detector: identifica el idioma del input
translator-escope: traduce de inglés a español manteniendo tono
format-converter: convierte entre formatos (JSON, Markdown, CSV)

Cada una cabe en 20-50 líneas de instrucciones.

Una buena heurística para saber si has llegado al nivel atómico es preguntarte: "Si esta Skill fallase, ¿sabría exactamente qué capacidad está rota?" Si la respuesta es "no", sigues teniendo responsabilidades mezcladas. En producción, esta claridad es lo que te permite hacer debugging quirúrgico. Cuando un agente legal empieza a generar documentos con formato incorrecto, no tienes que revisar 300 líneas de instrucciones. Vas directamente a format-converter, sabes que esa Skill gestiona el formato, y revisas sus 20 líneas. El resto del sistema sigue funcionando.

2. Define condiciones de activación explícitas

Este es el paso que casi nadie hace. Y es el que diferencia una Skill de un prompt de sistema.

Sin condiciones, tu Skill está siempre activa. Eso significa que contamina todas las respuestas. Claude intentará aplicar comportamiento de compra incluso cuando le pides que resuma un artículo técnico.

Las condiciones de activación actúan como un enrutador semántico. Le dicen a Claude: "este bloque de instrucciones solo aplica si se cumple X condición". Y lo mejor es que Claude entiende estas condiciones de forma natural, no como una regex. Puedes escribir "se activa cuando el usuario parece frustrado o cuando el código contiene más de 3 errores seguidos" y Claude lo interpreta correctamente.

Un error común es escribir condiciones demasiado amplias. "Se activa cuando el usuario habla de código" es tan amplia que básicamente está siempre activa si el contexto es técnico. Prefiere condiciones estrechas que puedas verificar: "Se activa cuando el usuario pega un bloque de código que comienza por ``` y contiene la palabra 'error' o 'bug'".

3. Testea cada Skill en aislamiento

Antes de componer nada, prueba cada Skill por separado. Crea una conversación con una sola Skill activa y verifica:

¿Hace lo que promete?
¿Tiene side effects no deseados?
¿Se desactiva cuando no toca?

Si una Skill produce resultados incorrectos en solitario, en composición va a ser un desastre.

El testing en aislamiento es tu red de seguridad. Cuando añades una Skill nueva a un sistema con 10 Skills ya funcionando, el riesgo de que algo se rompa existe siempre. Pero si cada Skill ha sido verificada individualmente, sabes que el problema, si aparece, está en la interacción, no en la Skill individual. Reducir el espacio de búsqueda de bugs de "cualquiera de las 11 Skills" a "la interacción entre la Skill nueva y las existentes" ahorra horas de debugging.

Una técnica que funciona bien: mantén un conjunto de conversaciones de prueba para cada Skill. Cuando actualices una definición, ejecuta esas conversaciones de nuevo y verifica que el comportamiento sigue siendo el esperado. Es tu suite de tests de regresión para prompts.

4. Compón incrementalmente

Añade Skills una a una. No actives 5 Skills a la vez y esperes que funcione. Cada Skill nueva puede interferir con las existentes.

El orden importa. Si tienes una Skill "be concise" y otra "be thorough", Claude se va a bloquear. Son contradictorias por definición. La solución no es "intentar que coexistan". Es rediseñar la condición de activación para que nunca se activen en el mismo turno.

La composición incremental también te permite observar cómo cambia el comportamiento del agente con cada adición. Es como construir un sistema de software añadiendo módulos uno a uno y ejecutando los tests después de cada paso. Si todo funciona después de añadir la Skill 3, pero se rompe al añadir la Skill 4, sabes exactamente dónde buscar.

En mi experiencia con agentes de contenido legal, el orden óptimo suele ser: primero las Skills de análisis y validación (las que leen e interpretan), luego las de transformación (las que modifican contenido), y al final las de generación (las que producen nuevo contenido). Este orden minimiza las interferencias porque cada etapa consume la salida de la anterior.

5. Versiona tus Skills como código

Cada Skill debería tener:

Un nombre semántico (code-debug-analyzer-v2)
Un changelog (qué cambió y por qué)
Tests de regresión (verificar que actualizar una Skill no rompe las composiciones existentes)

Cuando arreglas un bug en una Skill, todas las conversaciones que la usan se benefician automáticamente. Eso no pasa con los prompts de sistema.

El versionado semántico para Skills sigue una lógica sencilla: cambios menores (v1.1, v1.2) son ajustes de wording o condiciones de activación. Cambios mayores (v2.0) son reescrituras completas de las instrucciones. Y el changelog no es un lujo: es la única manera de saber, tres meses después, por qué cambiaste aquella condición de activación que ahora parece extraña.

Si trabajas en equipo, el versionado se vuelve crítico. Un lead técnico puede definir la Skill code-style-enforcer-v2 con nuevas reglas de estilo, y todo el equipo adopta el cambio automáticamente. Pero si alguien necesita la versión anterior para un proyecto legacy, puede mantener code-style-enforcer-v1 activa. Sin versionado, esto es imposible.

---

La Ventaja Oculta: Persistencia y Actualización Centralizada

Los prompts de sistema son efímeros. Cada conversación nueva empieza de cero. Si encuentras un bug en tu prompt de sistema, tienes que actualizarlo manualmente en cada proyecto.

Las Skills persisten. Las actualizas una vez y todas las conversaciones que las usan adoptan el cambio.

Para equipos, esto es transformador. Un lead técnico define y mantiene una Skill de "estándares de code review". Actualiza la definición. Todo el equipo —los 10 desarrolladores— reciben el nuevo comportamiento sin hacer nada. Sin PRs. Sin despliegues. Sin "ah, es que no me había dado cuenta de que cambiaste el prompt".

Pongamos un ejemplo concreto. Trabajas en un equipo de 8 desarrolladores que usan un agente de revisión de código. El lead técnico detecta que la Skill security-auditor no está detectando vulnerabilidades de inyección SQL en consultas parametrizadas mal escritas. Actualiza las instrucciones de la Skill, añade ejemplos específicos, y sube la versión a v2. Al día siguiente, los 8 desarrolladores tienen el nuevo comportamiento en sus conversaciones. Nadie tuvo que hacer nada. El cambio simplemente ocurrió.

Compara esto con el flujo de un prompt de sistema compartido por documento o por Slack: alguien actualiza el prompt, lo comparte, y espera que los demás se acuerden de copiarlo en sus proyectos. Algunos lo harán. Otros no. Y los que lo hagan, probablemente lo harán mal porque copiar un prompt de 80 líneas manualmente siempre introduce errores.

Esta diferencia de flujo es la que separa una solución individual de una solución de equipo. Claude Skills, bien usadas, son una plataforma de comportamientos compartidos.

---

La Diferencia Arquitectónica con los GPTs de OpenAI

Vas a escuchar que "Claude Skills es el copia de los GPTs de OpenAI". Esa comparación es superficial y se salta lo importante.

Los GPTs de OpenAI son contenedores opacos. Un GPT empaqueta instrucciones + conocimiento + herramientas en una unidad cerrada. No puedes componer dos GPTs en la misma conversación. No puedes activar uno condicionalmente dentro de otro. Cada GPT es su propio mundo.

Claude Skills son transparentes y componibles. Se activan por condiciones. Se apilan en la misma conversación. No requieren una interfaz de chat separada.

La diferencia revela la filosofía de cada empresa: OpenAI priorizó el aislamiento de producto (cada GPT es una app). Anthropic priorizó la composición de comportamiento (las Skills viven en el mismo espacio).

Si quieres construir un sistema multi-dominio —un agente que revisa código Y traduce documentación Y audita seguridad— con GPTs necesitas tres conversaciones separadas. Con Claude Skills necesitas una conversación y tres Skills apiladas.

Y esto no es un detalle menor. Cuando trabajas en un sistema complejo, la capacidad de mantener contexto entre dominios es clave. Un agente que revisa código y luego traduce la documentación de ese código puede aprovechar el contexto de la revisión para hacer una mejor traducción. Con GPTs separados, ese contexto se pierde. Con Skills apiladas, el contexto persiste y cada Skill puede beneficiarse de lo que las otras han descubierto.

La composición no es solo comodidad. Es una mejora cualitativa del output.

---

Objeción: "¿Y por qué no uso un solo prompt de sistema detallado?"

Porque un prompt de sistema funciona para un dominio simple. Cuando crece la complejidad —múltiples dominios, integraciones de herramientas, trabajo en equipo— el prompt monolítico se vuelve frágil.

Cada vez que añades una instrucción, aumentas la probabilidad de contradicción interna. Y las contradicciones no se resuelven solas. Claude hace promedios. Obtienes comportamiento mediocre en todo.

Las Skills resuelven el problema N+1 de la gestión de prompts: cada capacidad nueva es una Skill independiente, no una línea más en un prompt que ya pesa 200 líneas.

Hay un argumento adicional que merece la pena considerar: el coste cognitivo de mantener un prompt monolítico. Cuando tienes 200 líneas de instrucciones, cada modificación requiere entender el prompt completo para no romper nada. Es como refactorizar una función de 500 líneas sin tests. Puedes hacerlo, pero cada cambio es una apuesta. Con Skills atómicas de 20 líneas, cada cambio es local y seguro. Sabes exactamente qué estás tocando y qué no.

La objeción más común que escucho es: "Pero mi prompt de sistema funciona bien. ¿Para qué arreglar lo que no está roto?" La respuesta es que el prompt monolítico funciona bien hasta que deja de hacerlo. Y cuando deja de hacerlo, el coste de desenredarlo es mucho mayor que el de haberlo estructurado bien desde el principio. Es deuda técnica de prompts. Y como la deuda técnica de código, cuanto más esperes para pagarla, más intereses acumulas.

---

El Takeaway Real

Claude Skills no son "prompts de sistema con esteroides". Son un sistema de composición de comportamientos que funciona cuando respetas el principio de responsabilidad única.

Escribe Skills de 20 líneas. No de 200.

Define cuándo se activan. No las dejes siempre encendidas.

Compón incrementalmente. No actives 5 Skills a la vez esperando un milagro.

*El 80% del prompt de sistema que escribes hoy debería estar repartido en Skills. No porque sea más bonito. Porque funciona mejor. *

El cambio no es de herramienta. Es de mentalidad. Dejas de pensar en "personas" y empiezas a pensar en capacidades. Y cuando haces ese cambio, Claude Skills pasan de ser un "feature menor" a ser la forma correcta de construir custom agents.

Yo ya lo hice. Mis agentes en producción —desde sistemas de contenido legal hasta directorios de gestorías— usan este patrón. Y no volvería atrás.

La pregunta no es si deberías migrar tus prompts a Skills. Es cuánto tiempo vas a seguir perdiendo antes de hacerlo.

El patrón de micro-Skills atómicas no es una moda ni una optimización marginal. Es un cambio estructural en la forma de construir agentes que aprovecha cómo funcionan realmente los modelos de lenguaje. Cuando alineas tu arquitectura de prompts con la mecánica de atención del modelo, dejas de remar contra corriente. Y los resultados —en calidad de output, en velocidad de iteración, en capacidad de escalar— hablan por sí solos.

Empieza por una. Coge una capacidad de tu agente actual, extráela a una Skill independiente con su condición de activación, y pruébala en solitario. Luego compónla con el resto. Repite. En tres iteraciones, no querrás volver al monolito.