¿Alguna vez imaginaste tener trucos en la vida real? Bueno, eso es lo que siente tu agente cuando usas las skills. Este término se ha hecho muy popular con la ola de LLMs y code agents que están surgiendo. Primero e importante, aclarar que no importa cuál uses (Claude, Codex, etc.), la skill es una herramienta universal, que aquí podrás entender desde qué son hasta poder crear tu propia skill.
¿Qué es una Skill? 📃#
Imagínate que estás en una biblioteca antigua resolviendo un misterio. Tienes miles de libros para leer, ¿lo harías? Seguramente no, lo primero es buscar títulos. Si uno te llama la atención, pasas a leer su descripción. Y, en el caso de que te interesen ambas, lees todo el libro buscando la información. Una skill es como un libro en esa biblioteca antigua, es ese libro con un título y una descripción que, de la misma forma que vos elegís qué leer, el agente elige qué skill consumir. En otras palabras, cada skill es un tesoro de información, y el agente lo consulta para encontrar la respuesta a su misterio (tu prompt).
Resumido, es un bloque de conocimiento reutilizable para aprender de manera dinámica y rápida algo específico. Su valor está en evitar tener que empezar de cero cada vez, en lugar de volver a pasarle todo un contexto como los criterios, los pasos, las reglas o una investigación, sino que encapsulas todo de una manera ordenada y lista para reutilizar. Así, el agente no depende solo del mensaje puntual que recibe; también puede apoyarse en una referencia preparada de antemano para trabajar con más contexto y mejor criterio.
¿Cuándo usarla? 🤔#
Una de las cosas más importantes para entender cómo funcionan las skills es que no se abren todas de una vez. Si así fuera, el agente se llenaría de contexto innecesario en su inicio. En lugar de eso, primero trabaja con una vista liviana de la skill, que se basa sobre todo en el título y la descripción. De ahí está la importancia de que el título sea claro y fácil de asociar, y más importante que la descripción resuma bien qué aporta esa skill, porque de eso depende en gran parte si el agente la selecciona o no.
Pero no siempre la decisión tiene que quedar del lado del agente. También puedes ser vos quien elija qué skill usar. Esto es útil cuando ya tienes en mente un workflow concreto o varias maneras de atender un problema, y dependiendo del contexto, quieres tomar un camino u otro. En esos casos, indicarle qué skill usar te da más control sobre cómo quieres que trabaje y sobre qué referencia quieres que tome.
Estructura 📂#
Una skill no es un texto aislado ni un prompt guardado en txt, sino una unidad con estructura propia. Lo más común es encontrarla dentro de una carpeta con su nombre y exclusiva de ella, donde vive toda la información y los recursos que necesita. Dentro tenemos un archivo tan principal como obligatorio llamado SKILL.md, que vendría a ser el corazón de la skill y su punto de entrada. Es el primer lugar desde donde se entiende qué es, cómo debe interpretarse y qué instrucciones contiene. Desde este punto, todo lo demás puede expandirse, complementarse o especializarse. La idea acá es romper con la noción de que una skill es simplemente un prompt largo. En realidad, se parece mucho más a una guía de trabajo o a una caja de herramientas armada para ayudar al agente a cumplir un objetivo concreto.
Dentro del SKILL.md existe una estructura, por un lado aparecen los metadatos y por otro el cuerpo. Esta división es importante porque separa de qué trata y de cómo debe interpretarse. Dentro de esos metadatos están los dos campos fundamentales, name y description, de los que hemos hablado anteriormente. Además, existen otros campos opcionales, como allowed-tools o model, que no solo amplían la información sobre la skill, sino que también permiten definir condiciones sobre cómo debe trabajar el agente mientras la está usando. Después, el cuerpo (lo más cargado), escrito en Markdown, donde viven las instrucciones. Ahí colocamos reglas, pasos, criterios, formatos, ejemplos, convenciones o cualquier otra guía que ayude al agente a encarar una tarea de forma concreta.
Por otro lado, una skill también puede apoyarse en recursos complementarios. Eso significa que no todo tiene que estar dentro de SKILL.md, puede venir acompañada por otros archivos y carpetas. Entre lo más utilizado aparecen directorios como scripts/, references/ y assets/, cada uno con un rol distinto. scripts/ puede incluir código o automatizaciones para tareas repetitivas. Referencias, documentación o material de consulta. assets/, imágenes, plantillas u otros recursos que ayuden a ejecutar mejor una tarea o a explicarla. Esto hace que sea un conjunto de herramientas y referencias listas para acompañar al agente cuando la tarea lo necesita.
Cuándo crear una skill 💡#
Una skill empieza a valer la pena crearla cuando dejas de ver un prompt como una explicación suelta y empiezas a verlo como un flujo, una forma de trabajo o una tarea que repites una y otra vez. Si hay algo que siempre requiere el mismo enfoque, los mismos pasos o ciertas reglas, y no quieres volver a explicarlo cada vez, probablemente ya tengas una buena candidata. También cuando buscas trabajar con más consistencia: no solo porque ahorra tiempo, sino porque te permite capturar ese conocimiento de una forma clara, ordenada y reutilizable. Incluso, el simple hecho de crear la skill también te obliga a generalizar y ordenar mejor ese proceso que ya hacías de manera parecida o casi idéntica.
En general, una buena skill empieza a aparecer cuando detectas ciertos patrones con etapas fáciles de olvidar, tareas que repites demasiado o una manera de trabajar que quieres mantener siempre igual. En ese punto, deja de ser solamente una idea útil o un recurso repetitivo y pasa a convertirse en algo que vale la pena empaquetar.
Crea y evalúa tu skill 🧪#
¿Cuál es la idea?#
Antes de empezar, conviene hacer una pausa y preguntarse qué es lo que quieres resolver con ella, en qué situaciones la usarías y qué flujo o resultado se espera al consumirla. También ya adelantar qué tipos de recursos o herramientas podrían venirle bien. Esto es muy importante porque una skill no nace de la nada, sino de una necesidad en concreto. Y acá entra la primera parte clave de su estructura, la descripción que no está solo para informar, sino para entender en qué situaciones conviene usarse. Por eso no tiene que sonar linda, sino ser práctica; tiene que dejar claro qué hace, en qué contexto debería activarse, qué se espera que use y qué resultado debería producir. Si tenemos todo eso desde el principio, construir la skill después se vuelve mucho más fácil.
Menos es más.#
Escribir una skill no es tirar un bloque gigante de instrucciones, poner demasiada información o copiar y pegar todo el contexto disponible. La idea es construir una guía clara, útil y fácil de seguir, sin llenarla de cosas innecesarias que no aportan valor real. Por esto conviene evitar explicar lo obvio o agregar información que el agente ya sabe, sí solo. Lo importante acá no es escribir mucho, sino escribir bien, dejando claro criterio, flujo y decisiones. También es importante no hacerla rígida, una buena skill no mata al agente, sino que marca una forma de trabajar con información extra. En otras palabras, no se trata de controlar cada movimiento, sino de darle una base útil de información para que razone mejor y responda con más criterio según la situación.
Métodos y agregados#
Algo que suma mucho es agregar una sección de gotchas. Es donde se anotan esas trampas que suelen aparecer en la práctica como errores recurrentes, supuestos que parecen razonables pero no lo son, casos borde o decisiones que cambian según la práctica y el contexto. Puede ser algo tan simple como recordar que no siempre un cambio grande implica algo malo o como atender un error repetitivo. Ese tipo de advertencias dan muchísimo valor a tu skill, porque no solo enseña qué hacer, sino también qué cosas pueden salir mal en el camino.
Una buena práctica es aplicar “progressive disclosure”. En lugar de meter todo dentro de SKILL.md, conviene dejar en el archivo principal solo lo esencial y apoyarse en referencias, ejemplos o materiales complementarios que el agente pueda consultar más adelante si realmente los necesita. Eso hace que la skill sea más clara, más liviana y mucho más fácil de mantener. Pero cuidado, la realidad es que conviene sumar scripts o recursos extra solo cuando aportan valor de verdad, por ejemplo, a resolver los problemas mencionados previamente. Si no cumplen ese rol, agregarlos por agregar solo vuelve la skill más pesada y más difícil de sostener.
Otra capa interesante que puede incorporar son los guardrails o restricciones. No todas las skills están pensadas solo para enseñar qué hacer, hay algunas que también sirven para delimitar cómo trabajar, qué herramientas conviene usar y cuáles no. Campos como allowed-tools permiten limitar qué herramientas puede utilizar. Esto resulta especialmente útil en flujos sensibles, flujos de solo lectura o donde quieres reducir margen de error.
Valídala y termínala.#
Por último, una skill no termina de construirse cuando se escribe, sino cuando se valida. Esto lleva a probarla con casos reales o realistas como para ver donde funciona bien y donde empieza a fallar. Luego, con esos resultados, estudiar los errores repetidos, los casos borde y las decisiones que cambiaron según el contexto, ya que ahí suele aparecer la información más útil para mejorarla. Y si quieres ir más lejos, puedes comparar resultados, observar si realmente aporta una mejora frente a no usarla o frente a una versión anterior. En definitiva, validar una skill es comprobar que no solo está bien escrita, sino que de verdad ayuda cuando llega el momento de usarla.
Conclusión 🤖#
En definitiva, si el agente ya es capaz por sí solo, una skill es la herramienta que lo vuelve más cercano a tu manera de pensar y trabajar. Ahí está la verdadera gracia, en no quedarte solo con lo que el agente puede hacer, sino en darle una caja de herramientas que lo ayude a hacerlo cada vez mejor.
Links de interés 🔗#
Si quieres profundizar un poco más, te dejo algunos links que valen la pena para seguir explorando123.
