Cómo crear skills de agentes de IA para flujos de trabajo empresariales de un ámbito específico

El agente de programación de IA de propósito general resuelve con solvencia una variedad sorprendentemente amplia de tareas. Lee documentación, escribe código, depura fallos y razona sobre problemas desconocidos si cuenta con suficiente contexto. Sin embargo, la mayoría de los equipos que despliegan estos agentes en entornos operativos reales se encuentran con la misma dificultad: proporcionar ese contexto es una tarea en sí misma, cuya complejidad aumenta con la del ámbito de trabajo.

Un analista de datos que necesita que el agente extraiga los plazos de entrega de proveedores de una carpeta de órdenes de compra en distintos formatos no quiere tener que explicar qué es una orden de compra, cómo funcionan las convenciones de nombres de su empresa y qué formato de salida esperan los sistemas posteriores cada vez que lo solicita. Un desarrollador que mantiene el monitoreo de infraestructura no quiere pegar los mismos umbrales de alerta y definiciones de gravedad en cada conversación. El problema es la repetición.

Las skills —configuraciones reutilizables que reúnen conocimientos de un ámbito e instrucciones de comportamiento en una única unidad que se puede invocar— responden directamente a ese problema. Este artículo describe cómo se crean, cómo se despliegan en flujos de trabajo recurrentes y dónde aportan valor de forma fiable.

Qué es realmente una skill

Una skill no es una función del modelo ni una capacidad de la API. Es un archivo; en concreto, un archivo Markdown situado en un directorio que el agente revisa al iniciar la sesión (en Claude Code, por ejemplo, un archivo SKILL.md dentro de una carpeta en ~/.claude/skills/ o en .claude/skills/ del proyecto; otros entornos de ejecución de agentes usan sus propias ubicaciones). Cuando el agente recibe una solicitud que coincide con la descripción de la skill, carga sus instrucciones y las sigue, en lugar de razonar desde cero sobre cómo abordar la tarea.

El archivo contiene cuatro elementos: un bloque de descripción que indica al agente cuándo activar la skill; un conjunto de instrucciones que especifica cómo abordar ese tipo de tareas; declaraciones opcionales de acceso a herramientas que, según el entorno de ejecución, autorizan de antemano o limitan las herramientas que el agente puede usar durante la ejecución (en Claude Code, allowed-tools autoriza herramientas de antemano sin restringir las demás); y ejemplos opcionales que muestran el comportamiento correcto ante entradas realistas.

Lo que el archivo no contiene son datos empresariales fijados de forma estática. Una skill codifica cómo abordar una clase de tareas —el vocabulario del ámbito, el patrón de razonamiento, el formato de salida—, no las tareas en sí. Esa distinción entre codificar el método y codificar los datos es la cuestión central al diseñar skills que sigan siendo útiles con el tiempo.

Cuándo incorporar conocimientos del ámbito y cuándo no

La mayoría de las implementaciones de skills que fracasan lo hacen porque incorporan demasiada información. Los equipos, entusiasmados con el concepto, escriben una skill que incluye nombres concretos de proveedores, los planes de precios actuales, el formato de informe preferido por un cliente y los endpoints exactos de las API que se usan hoy. Seis meses después, la mitad de esa información es incorrecta, la skill ya no refleja la realidad y nadie sabe con certeza en qué partes confiar.

La regla práctica: incorpore lo que cambia despacio y deje al agente lo que cambia con frecuencia.

El vocabulario de un ámbito cambia despacio. Una skill para procesar documentación de importación debe saber qué es un certificado de origen, qué significa el método deductivo en la valoración aduanera y cómo es el marco normativo del mercado de destino. Ese conocimiento cambia mucho más despacio que los detalles operativos, aunque los marcos normativos se modifican y siguen necesitando revisiones periódicas. Su lugar está en la skill.

Los formatos concretos de presentación de documentos, los nombres de las contrapartes, los umbrales normativos vigentes y los plazos exactos cambian constantemente. Deben formar parte de los datos que el agente recibe durante la ejecución, no de la definición de la skill. La skill enseña al agente cómo leer una clase de documentos. El documento concreto llega como contexto.

Una comprobación útil: si necesita actualizar la skill cada vez que cambia algo en el entorno empresarial, ha incluido la información equivocada. Las skills bien diseñadas resisten los cambios organizativos. Las mal diseñadas quedan obsoletas casi de inmediato.

La estructura de SKILL.md

La estructura canónica del archivo de una skill es sencilla. Un bloque de metadatos iniciales identifica la skill y define cuándo activarla; el cuerpo define cómo utilizarla.

---
name: import-document-processor
description: Use when processing import declarations, ACP applications,
  or customs documentation for Singapore, Japan, or EU markets
---

## Context
Background on the domain: what this class of documents is, why it
exists, what the agent needs to know to interpret one intelligently.

## Approach
Step-by-step instructions for handling the task: what to look for,
how to handle ambiguous cases, what to escalate to human review.

## Output Format
Exactly what the output should contain, in what structure.

## Edge Cases
Known failure modes and how to handle them.

Desde el punto de vista operativo, el bloque de descripción es la parte más importante. Determina si el agente activa la skill. Una descripción vaga —«usar para documentos»— produce una activación irregular. Una descripción precisa que indique los tipos de documentos, los contextos empresariales y los mercados pertinentes produce un comportamiento fiable.

Sin embargo, la descripción tampoco debe ser demasiado específica. Si es demasiado limitada, el agente pasa por alto solicitudes que sí corresponden. El objetivo es una descripción en la que un profesional atento reconozca su situación: ni más ni menos. Esto exige ajustes en la práctica, y conviene probar casos límite durante el despliegue inicial para verificar que los límites de activación sean los previstos.

El patrón /loop para tareas recurrentes

Algunos flujos de trabajo empresariales se ejecutan según una programación: extracción diaria desde un endpoint de API, agregación semanal de informes de proveedores, generación mensual de resúmenes para clientes. No son interacciones puntuales, sino procesos operativos que se ejecutan continuamente, con independencia de que alguien los inicie manualmente.

En Claude Code, el comando /loop convierte una interacción basada en una skill en una operación recurrente:

/loop 24h /process-supplier-reports

Esto vuelve a ejecutar la skill indicada con el intervalo especificado dentro de la sesión actual, que proporciona el contexto en cada invocación. La skill se encarga del trabajo; el bucle se encarga de la programación. A octubre de 2026, la documentación de Claude Code indica que /loop está limitado a la sesión: las tareas solo se ejecutan mientras la sesión está en marcha y las tareas recurrentes caducan a los siete días. Por tanto, la programación duradera en producción debe realizarse mediante un trabajo de cron, un pipeline de CI o una tarea programada en la nube que invoque la misma skill.

Las skills recurrentes requieren consideraciones de diseño específicas que no se aplican a las interactivas. Deben ser idempotentes: ejecutar dos veces la misma skill con la misma entrada no debe crear registros duplicados, enviar notificaciones duplicadas ni corromper el estado de los sistemas posteriores. Necesitan un comportamiento explícito ante errores: una definición clara de qué ocurre si la entrada tiene un formato incorrecto, una API no está disponible o faltan los datos esperados. Y si los sistemas posteriores consumen su salida, esta debe ser legible por máquinas, no solo por personas.

Las skills que funcionan de forma fiable en un bucle casi siempre tienen un alcance más limitado que las creadas para uso interactivo. Una skill interactiva puede gestionar correctamente cinco tipos de documentos y ofrecer resultados razonables para otros que no conoce. La variante recurrente procesa un solo tipo de documento con precisión y devuelve un error explícito ante cualquier elemento inesperado. La fiabilidad operativa favorece la especificidad frente a la flexibilidad.

Una regla práctica: si no puede describir el comportamiento esperado completo de la skill —incluidos los casos de error— en menos de diez minutos, probablemente su alcance sea demasiado amplio para una ejecución programada fiable.

Ejemplos prácticos en producción

Tres patrones que hemos utilizado en entornos operativos reales:

Extracción de datos de comunicaciones de proveedores. Los proveedores envían confirmaciones de pedidos, notificaciones de envío y actualizaciones de facturas en formatos inconsistentes: a veces estructurados, a menudo no. Una skill configurada para el estilo de comunicación de cada proveedor extrae datos estructurados de texto no estructurado. La skill sabe que un proveedor concreto incluye una referencia a la orden de compra en el segundo párrafo de su correo de confirmación, que su formato de fecha es DD.MM.YYYY y que sus códigos de producto siguen un patrón específico. Lo que cambia cada semana es el contenido del correo; lo que permanece fijo es cómo analizarlo. La salida extraída alimenta directamente los sistemas de inventario, sin intervención manual entre la recepción del mensaje y la introducción de los datos.

Generación de informes a partir de datos operativos. Generar un resumen operativo semanal exige saber qué métricas importan, qué umbrales son significativos, qué comparaciones entre períodos tienen sentido y cómo presentar los hallazgos a un público concreto. Nada de eso cambia de una semana a otra. Una skill lo codifica una sola vez. Durante la ejecución, el agente recibe los datos actuales y aplica el marco de análisis configurado. El formato de salida, el registro lingüístico y las secciones que deben aparecer siempre se definen en la skill, sin volver a especificarlos cada vez. El resultado es una consistencia que las instrucciones manuales rara vez logran a gran escala.

Monitoreo de sistemas y alertas. La infraestructura genera registros continuamente. Las skills de monitoreo definen qué patrones constituyen un evento relevante, cómo clasificar su gravedad y qué información necesita una persona para actuar eficazmente ante una alerta. Combinadas con el patrón de bucle y ejecutadas a intervalos cortos, estas skills comprueban las condiciones definidas y generan alertas estructuradas cuando se cumplen.

La consideración clave de diseño es la gestión de falsos positivos. Una skill que alerta sobre cada anomalía acostumbra a los profesionales a ignorar las alertas. El verdadero trabajo consiste en ajustar los criterios: definir las condiciones precisas en las que una alerta merece atención humana. No es un problema técnico, sino de conocimiento del ámbito. Resolverlo exige aportaciones detalladas de quienes actualmente responden a los incidentes de forma manual, porque ya han interiorizado el umbral entre la información relevante y el ruido. La skill formaliza ese conocimiento.

Qué no resuelven las skills

Las skills codifican competencias en ámbitos específicos. No crean una capacidad general.

Una skill bien configurada gestiona patrones conocidos de forma fiable. No maneja bien situaciones realmente nuevas, porque las instrucciones que la hacen fiable en contextos conocidos la limitan activamente en los desconocidos. En la práctica, las skills funcionan mejor cuando el conjunto de tareas está razonablemente acotado: documentación de importación de mercados específicos, generación de informes para un conjunto definido de métricas o análisis de registros con patrones de alerta conocidos. «Ayudar con las operaciones empresariales» no es un conjunto acotado de tareas. Las skills no pueden hacer competente a un agente en ámbitos donde nadie ha dedicado esfuerzo a definir en qué consiste esa competencia.

La otra limitación es el mantenimiento. Las skills que incorporan conocimientos de un ámbito necesitan actualizaciones cuando estos cambian: no ante cada cambio, porque las bien diseñadas evitan incorporar información volátil, pero algunos cambios son inevitables. Mantenerlas al día exige la misma disciplina que mantener actualizada la documentación. Las organizaciones que no invierten en ello descubren gradualmente que sus skills han dejado de reflejar la realidad. El fallo es silencioso: la skill sigue ejecutándose y produciendo resultados, pero estos contienen errores sutiles que tardan en detectarse.

Las organizaciones que obtienen más valor de las skills invierten tanto en la configuración inicial como en los ajustes continuos. La inversión inicial es menor de lo que la mayoría espera. El compromiso de mantenimiento continuo es mayor de lo que la mayoría prevé; planificarlo con honestidad es lo que distingue las skills que siguen siendo útiles de las que se convierten en una fuente de errores silenciosos.