Skills en el desarrollo agéntico de Business Central: cómo enseñar a tu agente a trabajar como tú

Cualquiera que haya desarrollado en AL conoce ese momento frustrante: un error genérico como "Error en el documento" que no aporta absolutamente nada. Ni el mensaje ni el detalle técnico que hay detrás ayudan a entender qué ha pasado, por qué ha pasado, ni qué hay que hacer para solucionarlo. Es un problema tan habitual que sirve como excusa perfecta para explorar una de las piezas más potentes del desarrollo agéntico con GitHub Copilot: las skills.

Instrucciones vs. skills: la diferencia que lo cambia todo

En una entrega anterior hablamos de las instrucciones: ficheros que se aplican de forma obligatoria a un tipo de fichero concreto (por ejemplo, todos los .al) mediante la propiedad applyTo. Cualquier código que el agente genere dentro de ese ámbito tiene que respetarlas sí o sí.

Las skills funcionan de otra manera. Viven dentro de la carpeta skills, dentro de .github, y se componen de tres elementos: un nombre, una descripción y una explicación detallada de cómo hacer algo. La diferencia clave es que una skill no se ejecuta automáticamente. No lleva ningún applyTo que la dispare sobre un tipo de fichero. El agente solo la usa cuando se le indica explícitamente que la utilice, o cuando el propio flujo de trabajo la invoca desde otro punto (algo que veremos en próximas entregas).

Esto la convierte en la herramienta ideal para capturar buenas prácticas concretas — como "cómo debe verse un mensaje de error en esta extensión", sin forzarlas en cada línea de código que el agente escribe.

El caso práctico: mensajes de error informativos

Para ilustrar cómo funciona una skill, se define una centrada en mejorar los mensajes de error de una extensión. La regla de negocio es sencilla: cualquier mensaje de error debe responder a tres preguntas, en este orden:

1. ¿Qué ha pasado?
2. ¿Por qué ha pasado?
3. ¿Qué se debería hacer?

Para conseguirlo en AL, la skill indica utilizar el tipo de dato ErrorInfo, la funcionalidad que permite añadir a un error un título, un mensaje detallado e incluso una acción — por ejemplo, una codeunit que se ejecute para solucionar el problema directamente desde el propio mensaje de error. Cuando no es posible usar ErrorInfo por falta de parámetros, la skill exige que el texto del error incluya igualmente las tres respuestas de forma clara, con un ejemplo concreto: "La fecha de fin [X] es anterior a la fecha de inicio [Y]. Corrija la fecha final antes de continuar."

La skill también deja explícito qué evitar: mensajes genéricos ("Error en el documento", "No se pudo procesar", "Valor no válido"), referencias al nombre técnico del campo o códigos de error sin contexto ("Error 17"). Ninguno de estos aporta información útil a quien se encuentra el error.

Por último, incorpora reglas de estilo de código: todos los textos deben ir en variables Label — nunca hardcodeados — y esas etiquetas deben terminar con el sufijo Err, de forma que sea fácil identificarlas y mantenerlas.

Por qué las skills necesitan ser invocadas explícitamente

A diferencia de una instrucción, que se aplica automáticamente a cualquier fichero AL, la skill solo entra en juego cuando el agente sabe que debe consultarla.

La solución pasa por nombrarla explícitamente en el prompt:

"Mejora los errores de esta codeunit usando la skill ErrorMessages". 

En ese momento el comportamiento cambia por completo. El agente localiza el fichero de la skill (errormessages.skill.md), lee su contenido y, solo entonces, aplica las reglas: genera las variables Label con sufijo Err, construye los correspondientes ErrorInfo allí donde es posible, y produce mensajes que responden a las tres preguntas — qué pasó, por qué pasó y qué hacer al respecto.

Al probarlo en tiempo de ejecución, la diferencia es evidente. Un error de fechas incoherentes pasa de un mensaje mudo a algo como: "La fecha final está antes que la fecha de inicio del periodo de alquiler. Corrija la fecha final antes de continuar." Lo mismo ocurre al simular un límite de crédito superado: el mensaje explica el problema y apunta directamente a la solución.

La recomendación práctica

La lección de fondo va más allá de los mensajes de error. Cada vez que el agente resuelve una tarea de una forma que no encaja con cómo TU quieres que se hagan las cosas, la respuesta no es corregirlo manualmente una y otra vez, sino crear una skill que capture esa forma de trabajar. El tiempo invertido en documentar una buena práctica se recupera con creces, porque el agente deja de repetir el mismo error de enfoque en futuras iteraciones.

En definitiva, las instrucciones garantizan un mínimo obligatorio en todo el código; las skills permiten enseñar al agente procedimientos concretos, bajo demanda, sin sobrecargar cada generación con reglas que no siempre aplican. Dominar cuándo usar cada una es una de las claves para que el desarrollo agéntico en Business Central sea realmente productivo.

Te dejo un video para que veas cómo funciona en vivo: