Qué son realmente las skills

Hay una palabra que aparece mucho cuando se habla de agentes, flujos de prompting y automatización asistida por modelos: skills.

Y como suele pasar con casi todo lo relacionado con IA, a veces se usa para nombrar cosas muy distintas al mismo tiempo. En algunos contextos parece una etiqueta elegante para cualquier prompt largo. En otros, suena casi como si fuera una forma de “instalar capacidades” dentro del modelo. Ninguna de las dos lecturas ayuda demasiado.

La forma más útil que he encontrado de pensarlas es bastante menos espectacular y bastante más práctica: una skill es conocimiento operativo empaquetado para una clase de tarea recurrente.

No es magia. No es entrenamiento. No es una personalidad nueva. Es, sobre todo, una manera de capturar criterio para que el modelo tenga una mejor forma de abordar un trabajo que aparece una y otra vez.

La idea importante no es la longitud, sino la forma

Lo que suele volver útil a una skill no es que tenga muchas líneas, sino que organiza bien una forma de trabajar.

Eso normalmente incluye varias cosas a la vez: contexto, criterios de activación, pasos, restricciones, señales de calidad, errores comunes y, a veces, ejemplos. No porque haya que meter siempre todos esos elementos, sino porque las tareas buenas casi nunca dependen de una sola instrucción. Dependen de una secuencia y de un umbral de criterio.

Si una tarea exige pensar en el orden correcto, respetar ciertos límites, revisar resultados con una barra de calidad concreta y evitar errores repetidos, probablemente ahí hay espacio para una skill.

Por eso un archivo en Markdown puede ser suficiente. No porque Markdown tenga nada especial, sino porque permite escribir esa lógica operativa de una forma simple, mantenible y legible. Es un soporte cómodo para describir procedimientos, expectativas y buenas prácticas sin necesidad de añadir infraestructura antes de tiempo.

Lo que una skill sí hace bien

Una buena skill reduce ambigüedad.

Esa es, para mí, su función principal. No vuelve inteligente una tarea que no estaba bien pensada. No sustituye el criterio del que diseña el sistema. Pero sí ayuda a que una tarea recurrente se ejecute con más consistencia.

Por ejemplo, si un agente tiene que revisar interfaces, analizar una migración, ejecutar un checklist técnico o transformar contenido con un estándar concreto, una skill puede evitar que cada ejecución empiece desde cero. En vez de confiar en que el modelo “ya sabrá por dónde tirar”, le das una forma de trabajo más precisa.

Eso importa especialmente cuando el trabajo no es puramente mecánico, pero tampoco es completamente abierto. Hay tareas que están en ese punto intermedio: no se resuelven con una sola línea, pero tampoco justifican construir una herramienta entera. Ahí las skills suelen encajar bien.

Lo que una skill no es

También conviene ser bastante explícitos con los límites, porque en cuanto una idea funciona medio bien se vuelve fácil pedirle demasiado.

Una skill no es entrenamiento del modelo. No cambia sus pesos ni le enseña capacidades internas nuevas. Tampoco es fine-tuning. Y, aunque a veces pueda parecerlo desde fuera, tampoco es una pieza mágica que convierte un proceso mediocre en uno excelente sólo por estar mejor escrito.

Tampoco es simplemente una bolsa de consejos. Si una skill se queda en una lista de buenas intenciones del tipo “sé claro”, “piensa paso a paso” o “cuida la calidad”, normalmente aporta poco. Para que merezca la pena tiene que traducir experiencia en instrucciones operativas: qué mirar, en qué orden, con qué límites y con qué definición de resultado aceptable.

Y, quizá más importante todavía, una skill no sustituye al diseño del sistema. Si la tarea está mal definida, si el contexto entra incompleto o si la salida esperada no está clara, el problema no se arregla añadiendo más texto.

Cuándo ayudan de verdad

Suelen funcionar bien en tareas que se repiten y donde el rendimiento depende menos de “tener una gran idea” y más de aplicar bien un proceso.

Pienso en casos como revisiones de diseño, auditorías de código, migraciones con varias comprobaciones, preparación de contenido con un tono definido o investigaciones donde conviene seguir siempre el mismo marco. En todos esos casos hay matices que merece la pena capturar una vez y reutilizar después.

También ayudan cuando varias personas —o varios agentes— necesitan compartir una forma parecida de trabajar. Una skill sirve entonces como un pequeño contenedor de criterio: no garantiza perfección, pero sí hace más probable que el resultado salga dentro de unos márgenes razonables.

Un caso bastante natural es usarla desde LangChain como una pieza de contexto reutilizable. La skill sigue siendo texto, pero texto con estructura y propósito. Por ejemplo, puedes guardar la skill como un archivo Markdown y cargarla en el mensaje de sistema para que el agente no improvise desde cero en cada ejecución.

# Skill: review-ui

Usa esta skill cuando tengas que revisar una interfaz antes de implementarla.

## Objetivo
- detectar problemas de jerarquía, densidad y claridad
- proponer mejoras concretas, no genéricas

## Reglas
- empieza por estructura antes que por decoración
- no sugieras animaciones si el problema es de layout
- prioriza cambios de alto impacto y bajo ruido

Y luego usarla desde LangChain de una forma tan simple como esta:

import { readFile } from 'node:fs/promises'
import { ChatPromptTemplate } from '@langchain/core/prompts'
import { ChatOpenAI } from '@langchain/openai'

const skill = await readFile('./skills/review-ui.md', 'utf8')

const model = new ChatOpenAI({
  model: 'gpt-4.1-mini',
  temperature: 0,
})

const prompt = ChatPromptTemplate.fromMessages([
  [
    'system',
    `Eres un diseñador de producto senior. Sigue esta skill con precisión:\n\n${skill}`,
  ],
  [
    'human',
    `Revisa esta propuesta de landing page. Quiero feedback sobre jerarquía visual, spacing, claridad del mensaje y calidad del CTA. Devuelve observaciones y una lista corta de mejoras priorizadas.`,
  ],
])

const chain = prompt.pipe(model)
const result = await chain.invoke({})

console.log(result.content)

No hay nada especialmente misterioso aquí. La skill no se convierte en un módulo ejecutable ni en una capacidad nueva del modelo. Sigue siendo contexto. La diferencia es que ahora ese contexto está más cuidado, es reutilizable y expresa una forma concreta de trabajar.

Cuándo no merece la pena

No toda tarea necesita una skill.

Si algo es obvio, corto y de una sola vez, añadir una capa de instrucciones especializadas puede introducir más fricción que valor. También pasa cuando la tarea cambia tanto entre un caso y otro que el procedimiento deja de ser reutilizable. En esos escenarios, lo que parecía una skill termina siendo un documento cada vez más largo y cada vez menos útil.

Otro caso típico es usar skills para compensar una mala decisión de arquitectura. Si en realidad lo que hace falta es una herramienta, una función, una validación automática o una transformación determinista, conviene construir eso antes que describirlo de forma narrativa y esperar que el modelo lo ejecute siempre igual.

Eso también aplica en LangChain. Si lo que necesitas es acceso estable a datos, validación estricta, llamadas a APIs, branching determinista o transformaciones que no deberían depender de interpretación, ahí la solución no es “hacer la skill más detallada”. Ahí conviene modelar mejor el grafo, introducir herramientas o mover parte del trabajo fuera del modelo.

No todo debe resolverse con prompting.

La señal de que una skill está bien planteada

Hay una prueba bastante simple: después de leerla, el modelo debería tener menos grados de libertad inútiles, no más.

Una skill buena no encorseta por completo, pero sí orienta. Reduce errores previsibles. Hace explícita la barra de calidad. Ordena el trabajo. Y deja claro cuándo ese procedimiento aplica y cuándo no.

Si, por el contrario, después de escribirla todo sigue siendo difuso y abierto a demasiadas interpretaciones, probablemente no has definido una skill: sólo has acumulado texto alrededor de una tarea que aún necesita diseño.

Una forma sobria de pensarlas

Me gusta entenderlas así: una skill es una unidad pequeña de conocimiento operativo reutilizable.

Ni más ni menos.

No intenta reemplazar el juicio. Intenta empaquetar parte de él para no tener que redescubrirlo cada vez.

Y quizá ese sea el criterio más útil para decidir si algo merece convertirse en skill: si al escribirla no estás capturando una forma real de trabajar mejor, entonces probablemente no necesitas una skill. Necesitas pensar mejor la tarea.