Claude Skills: El 90% de los Desarrolladores los Usa Como Prompts del Sistema (y Así Es Como se Rompen)
Claude Skills no son prompts del sistema. Son especificaciones formales de comportamiento. Aprende el patrón de 5 pasos para construir custom agents que escalan en producción.
Si crees que las Skills de Claude son solo prompts más bonitos, estás perdiendo el 80% de su potencial
Y probablemente estás escribiendo código que no escala.
La mayoría asume que una Skill de Claude es un prompt guardado con esteroides. Instrucciones más largas, algunos ejemplos, un par de herramientas. Casi como un GPT de OpenAI, pero en Anthropic.
*El error no es menor. Es conceptual. *
Las Skills de Claude no son prompts. Son especificaciones formales de comportamiento que se compilan en un pipeline de ejecución. Están más cerca de TypeScript que de ingeniería de prompts. Definen tipos de entrada, tipos de salida, herramientas asociadas, y constraints de seguridad — todo antes de que el modelo genere un solo token.
Tratarlas como prompts es como usar TypeScript como si fuese JavaScript sin tipar. Funciona al principio. Luego tienes 50 Skills, no sabes qué entra ni qué sale, y el debugging se convierte en adivinar.
*La diferencia no es sutil. Es la diferencia entre un script de 50 líneas y un sistema que aguanta producción. *
---
Qué es realmente un Claude Skill (y qué no es)
Cuando Anthropic lanzó las Skills en Claude, la documentación hablaba de "comportamientos reutilizables definidos mediante instrucciones estructuradas y ejemplos". Sonaba a prompts con esteroides. La comunidad respondió guardando prompts largos en la interfaz de Anthropic.
Pero la realidad técnica es más interesante.
Una Skill en Claude se define con una estructura formal. No es una cadena de texto monolítica. Tiene secciones separadas con propósito único:
instructions: el comportamiento que debe seguir el modelo
tools: las herramientas externas disponibles para esa Skill
examples: demostraciones few-shot de entrada/salida esperada
constraints: límites de seguridad, validaciones post-ejecución
Cada sección tiene su propia función. No se mezclan. *No se pueden mezclar. *
❌ Enfoque incorrecto:
```
Prompt del sistema que mezcla instrucciones, ejemplos y contexto en un párrafo de 2000 tokens. Sin separación. Sin tipos. Sin herramientas declaradas.
```
✅ Enfoque correcto (Skill como especificación):
```yaml
name: "analizar_repo_python"
description: "Analiza un repositorio Python y genera un informe de calidad"
input:
repo_url:
type: string
description: "URL del repositorio a analizar"
branch:
type: string
description: "Rama del repositorio"
default: "main"
output:
type: array
items:
type: object
properties:
severity: { type: string, enum: ["high", "medium", "low"] }
file: { type: string }
line: { type: number }
description: { type: string }
tools:
git_clone
pylint_runner
bandit_scanner
instructions: |
Eres un analizador de calidad de código Python.
1. Clona el repositorio en la rama especificada
2. Ejecuta pylint y bandit sobre todos los ficheros .py
3. Clasifica cada issue por severidad
4. Devuelve un array ordenado por severidad descendente
examples:
input: { repo_url: "https://github.com/ejemplo/proyecto", branch: "main" }
output: [{ severity: "high", file: "src/auth.py", line: 42, description: "Hardcoded secret detected" }]
constraints:
max_tokens: 4000
temperature: 0.1
```
Fíjate en la diferencia. La versión incorrecta es un texto plano que le pides al modelo que interprete como quiera. La versión correcta es un contrato. Define qué entra, qué sale, qué herramientas se usan, bajo qué límites.
Esto no es un prompt. Es una función.
---
El problema de tratar las Skills como prompts sueltos
Cuando tienes una Skill, todo funciona. Cuando tienes diez, empiezan los problemas. Cuando tienes cincuenta, el sistema colapsa.
La razón es simple: los prompts no tienen tipos. No puedes validar que una Skill reciba los parámetros correctos. No puedes garantizar que devuelva la estructura esperada. No sabes si una herramienta se va a ejecutar fuera de contexto porque la definición está mezclada con las instrucciones.
El resultado es lo que veo en producción cada semana:
Skills que devuelven JSON mal formado porque no hay validación de salida
Skills que invocan herramientas que no deberían tener acceso
Skills que se "olvidan" de pasos porque las instrucciones son narrativas, no procedurales
Skills que fallan silenciosamente porque no hay constraints definidos
*El 90% de los Claude Agents en producción son chats glorificados con un prompt largo. * No son agentes. Son chatbots con pretensiones.
Anthropic diseñó las Skills para que fueran máquinas de estado deterministas con puntos de verificación explícitos. Pero la mayoría las usa como prompts narrativos donde el modelo decide cómo interpretar las instrucciones. Esa es la diferencia entre un sistema que escala y uno que se rompe al tercer usuario.
---
El sistema de tipos cambia todo
El aspecto más infravalorado de las Skills de Claude es el tipado de entrada/salida.
Cuando defines parámetros de entrada con tipos (`string`, `number`, `object` con propiedades) y una estructura de salida esperada, estás haciendo algo que los prompts tradicionales no pueden hacer:
*Puedes validar estáticamente las invocaciones antes de que lleguen a la API. *
Esto no es teoría. Es práctica. Si defines una Skill que espera `repo_url: string` y `language: enum["python", "javascript"]`, cualquier invocación con un valor incorrecto se rechaza en tiempo de definición, no en ejecución.
Los prompts tradicionales descubren estos errores en producción. El usuario manda un parámetro incorrecto y el modelo adivina. A veces acierta. A veces no. *Nunca sabes hasta que es demasiado tarde. *
Con Skills tipadas, el error se detecta antes de la llamada a la API. Punto.
---
El Patrón de 5 Capas para Skills en Producción
Después de enviar varios sistemas con Skills en producción — desde gestorías online hasta análisis de emergencias — he destilado el proceso en un patrón que funciona.
Llamadlo "El Patrón de 5 Capas para Skills en Producción" . Cada capa es obligatoria. Saltarte una es acumular deuda técnica que pagarás en debugging.
1. Identifica comportamientos atómicos
Una Skill = una capacidad. No más.
Si tu Skill hace tres cosas diferentes (analizar código, generar documentación, y enviar un email), la has cagado. Dividela en tres Skills independientes.
La regla es simple: si puedes describir lo que hace la Skill en una frase sin usar "y", estás bien. Si necesitas "y", dividela.
❌ Skill monolítica: `analizar_repo_y_generar_informe_y_enviar_notificacion`
✅ Skills atómicas: `analizar_repo`, `generar_informe`, `enviar_notificacion`
Cada Skill atómica se prueba de forma aislada. Cada una tiene su propio contrato. *La composición de Skills pequeñas siempre gana a una Skill grande. *
2. Define el contrato antes que las instrucciones
Este es el paso que casi nadie hace. Y es el más importante.
Antes de escribir una línea de instrucciones, define:
Input: tipos, formatos, validaciones, valores por defecto
Output: estructura esperada, tipos, campos obligatorios
Errores: qué devuelve si falla, códigos de error
El contrato es el qué. Las instrucciones son el cómo. Si no tienes claro el qué, el cómo no importa.
```yaml
Siempre define el contrato primero
input:
customer_id:
type: string
pattern: "^CUST-\d{6}$"
description: "ID de cliente con formato CUST-XXXXXX"
document_type:
type: string
enum: ["factura", "presupuesto", "contrato"]
output:
type: object
properties:
summary: { type: string }
key_points: { type: array, items: { type: string } }
risk_flags: { type: array, items: { type: string } }
required: ["summary", "key_points"]
```
Esto parece más trabajo que escribir un prompt rápido. Lo es. *Pero es trabajo que solo haces una vez, mientras que el debugging lo haces cada semana si no lo haces. *
3. Asigna herramientas explícitamente
Cada Skill debe tener solo las herramientas que necesita. Nada de dar acceso a todas las herramientas y confiar en que el modelo use las correctas.
El riesgo es obvio: si una Skill tiene acceso a una herramienta de escritura en base de datos y el modelo se confunde, puedes tener datos corruptos. O peor, acciones ejecutadas sin autorización explícita.
```yaml
Skill para leer datos de cliente
tools:
read_customer_db # ✅ Solo lectura
search_invoices # ✅ Solo consultas
❌ NO incluir: update_customer_db, delete_invoices, send_email
```
El tool use en Claude permite hasta 200+ herramientas en una sola solicitud de API. Pero tener 200 herramientas no es un feature. Es un riesgo de seguridad. Asigna con pinzas.
4. Establece constraints de seguridad por Skill
Cada Skill necesita sus propios límites. No heredes los del sistema global.
Define por Skill:
max_tokens: cuánto puede generar como máximo
temperature: qué nivel de creatividad (producción = 0.1 a 0.3)
top_p: control de diversidad en la selección de tokens
stop_sequences: tokens que detienen la generación
Y no olvides las validaciones post-ejecución. Claude implementa capas de seguridad con Constitutional AI que se ejecutan antes y después de cada invocación de Skill. Aprovéchalas.
```yaml
constraints:
max_tokens: 2000
temperature: 0.1
stop_sequences: ["\n\nHUMAN:", "\n\nASSISTANT:"]
post_validation:
check_output_schema: true
validate_no_hallucinations: true
max_severity_flags: 5
```
5. Prueba y versiona las Skills como código
Este es el paso que separa a los que envían de los que experimentan.
Las Skills deben tener tests. No tests de "pinta bien". Tests reales:
Test de esquema: la salida cumple el contrato definido
Test de límites: qué pasa con inputs vacíos, nulos, o mal formados
Test de composición: dos Skills encadenadas producen el resultado esperado
Test de seguridad: la Skill no invoca herramientas fuera de su alcance
Y versionado. Cada Skill en un fichero YAML/JSON dentro de un repositorio. Con commits. Con CI/CD. *Si no versionas tus Skills como código, no sabes qué cambió ni cuándo se rompió. *
---
Cómo se ve esto en la práctica: Skill vs. prompt tradicional
Vamos a ver la diferencia con un ejemplo real. Una Skill para clasificar emails de soporte técnico.
Prompt tradicional:
```
Eres un clasificador de emails de soporte. Clasifica cada email en una de estas categorías: facturación, técnico, cuenta, general. Devuelve la categoría y una breve explicación.
```
Esto funciona. Más o menos. El problema es que el modelo puede devolver "Facturación", "facturacion", "Facturacion técnica", "Categoría: facturación" — cada vez un formato diferente. No hay contrato. No hay validación. Es narrativa pura.
Skill correctamente definida:
```yaml
name: "classify_support_email"
description: "Clasifica un email de soporte técnico en una categoría predefinida"
input:
email_subject:
type: string
required: true
email_body:
type: string
required: true
customer_tier:
type: string
enum: ["basic", "premium", "enterprise"]
default: "basic"
output:
type: object
properties:
category:
type: string
enum: ["billing", "technical", "account", "general"]
confidence:
type: number
minimum: 0
maximum: 1
explanation:
type: string
maxLength: 200
required: ["category", "confidence"]
tools: []
constraints:
temperature: 0.05
max_tokens: 300
```
Ahora la salida es predecible. Sabes exactamente qué estructura va a devolver. Puedes validarla antes de usarla. Puedes componerla con otras Skills. Puedes testearla.
*Esa es la diferencia entre un experimento y un sistema de producción. *
---
Composición: el superpoder de las Skills
Cuando cada Skill tiene su propio contrato, puedes componerlas como funciones en un pipeline.
```yaml
Pipeline de procesamiento de soporte
pipeline:
skill: classify_support_email
input: { email_subject, email_body, customer_tier }
output: classification
skill: route_to_team
input: { classification: classification.category }
output: routing_result
skill: generate_auto_reply
input:
category: classification.category
confidence: classification.confidence
customer_tier: customer_tier
output: draft_reply
```
Cada Skill se prueba de forma aislada. Cada una tiene su propio contrato. Si la clasificación falla, el pipeline se detiene antes de enrutar. *No hay efectos secundarios inesperados porque cada Skill solo sabe lo que necesita saber. *
Esto no es posible con prompts monolíticos. Con prompts, todo está mezclado. Cambias una cosa y se rompe otra. Con Skills, cada pieza es independiente.
---
La verdad sobre Claude Skills vs. OpenAI Agents
La comparación con OpenAI es inevitable. Y revela diferencias filosóficas profundas.
OpenAI apuesta por autonomía del modelo. Sus GPTs son entornos abiertos donde el modelo decide cómo interpretar las instrucciones, qué herramientas usar, y cómo estructurar la salida. Es flexible. Es rápido de prototipar. Pero es impredecible en producción.
Anthropic apuesta por control del desarrollador. Las Skills son máquinas de estado deterministas. El desarrollador decide exactamente qué herramientas están disponibles, qué estructura tiene la salida, y bajo qué constraints opera el modelo.
*No hay enfoque correcto. Hay enfoques para contextos diferentes. *
OpenAI gana en experimentación y prototipado rápido. Anthropic gana en producción donde la predictibilidad y la seguridad importan más que la creatividad.
El problema es que la mayoría intenta usar Skills de Claude como si fuesen GPTs de OpenAI. Y entonces el sistema se rompe porque las Skills no están diseñadas para ser flexibles. Están diseñadas para ser predecibles.
---
Conclusión
Las Skills de Claude no son prompts. Son el intento más serio de Anthropic de convertir la interacción con LLMs en ingeniería de software real — con tipos, contratos, tests y versionado.
Si las tratas como prompts bonitos, vas a tener problemas cuando intentes escalar. Si las tratas como módulos de software con entrada/salida tipada, herramientas asignadas explícitamente, y constraints de seguridad, vas a construir sistemas que aguantan producción.
*El cambio de mentalidad es incómodo. Pero es necesario. *
La era de los prompts narrativos está terminando. La era de las especificaciones formales de comportamiento acaba de empezar.
Las Skills no son para jugar. Son para enviar.
Lee el artículo completo en brianmenagomez.com
Más sobre mis servicios en brianmenagomez.com
Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF