Haz que tu agente de IA pase de Junior a Senior: aprende a crear Skills y enséñale a trabajar como lo harías tú

Durante meses usé Claude como casi todo el mundo: abría una conversación, le explicaba el contexto, le pedía algo y, si salía bien, lo celebraba. El problema es que al día siguiente tenía que explicarle otra vez cómo quería que trabajase, y aun así el resultado era una lotería. Hasta que caí en la cuenta de cuál era el error de fondo: le estaba pidiendo tareas, cuando lo que tenía que hacer era enseñarle a trabajar como yo lo haría.

Y es que una IA potente, sin contexto sobre cómo trabajas tú, se comporta como un junior brillante: sabe muchísimo, pero le falta tu criterio. No conoce tus estándares, no sabe qué priorizas, no ha visto las cien decisiones pequeñas que tú ya tienes interiorizadas y que separan un trabajo aceptable de uno bueno. No es que sea torpe. Es que le falta lo que a ti te sobra: criterio.

La pregunta entonces es casi obvia: ¿y si pudieras enseñarle una sola vez cómo lo harías tú, con tu criterio de senior, y que lo aplicara siempre? Eso son las Skills. Y de eso va este artículo: de qué son, de cómo funcionan por dentro y de cómo crear la tuya desde cero para que tu agente deje de improvisar como un junior y empiece a entregar como un senior de tu equipo. No hace falta que seas desarrollador: esto sirve igual para diseño, producto, growth o cualquier trabajo donde tu forma de hacerlo marque la diferencia.

Qué es una Skill

Una Skill, en el fondo, son instrucciones. Le explicas a tu agente cómo quieres que haga una tarea concreta: qué mirar primero, qué ignorar, qué formato usar, en qué orden, qué tono. Y la próxima vez que le pides esa tarea, la hace tal y como se lo indicaste, sin que tengas que repetírselo.

A mí me ayuda pensarlo con una analogía. Los agentes de IA son muy autónomos: si les das un objetivo, lo persiguen como sea. Imagina que le encargas a uno entregar un paquete importante a un cliente, conduciendo del punto A al B. Lo más probable es que llegue, o que te diga que no ha podido, pero por el camino tomará sus propias decisiones, y casi nunca serán las que tomarías tú. ¿Por qué? Porque optimiza por llegar al resultado, no por la calidad con la que se realiza la tarea. Igual aparca de cualquier manera, coge la ruta más larga o le habla al cliente de un modo que tú jamás usarías.

Ahora dale tres cosas antes de salir: el manual del coche, una guía de cómo tratar al cliente y un mapa con la mejor ruta señalizada. De repente conduce con criterio, sabe atender a quien recibe el paquete y llega por el camino más eficiente. No le has enseñado a conducir (eso ya sabía), le has dado tu forma de hacer bien ese trabajo.

Una Skill es justo ese paquete de manuales. No le enseñas a la IA a hacer la tarea, eso ya lo sabe. Le transfieres el criterio que tú, como senior, ya tienes interiorizado.

Y aquí está el matiz que para mí lo cambia todo. Mucha gente usa las Skills solo para no repetirse, y está bien, pero se quedan cortos. La potencia real aparece cuando dejas de pensar en ellas como atajos y empiezas a usarlas para destilar tu criterio. No le estás diciendo «ahórrame escribir esto otra vez», le estás diciendo «haz esto como lo haría yo después de años haciéndolo».

Un par de ejemplos para que se vea, según a qué te dediques:

• Producto: una Skill para escribir PRDs como los escribes tú. Que siempre empiece por el problema y la métrica de éxito antes que por la solución, que incluya criterios de aceptación, que marque explícitamente lo que queda fuera de scope y que cierre con riesgos y preguntas abiertas.
• Diseño: una Skill de UX Audit que captura las pantallas de un flujo (desde Figma o desde la web), verifica cada elemento antes de comentarlo para no inventarse nada, aplica los marcos que tú usarías (leyes de UX, heurísticas de Nielsen, sesgos cognitivos, WCAG) y entrega un informe con los hallazgos clasificados por severidad y anclados a competidores que resuelven mejor cada problema.
• Growth: una Skill para diseñar experimentos que exija siempre hipótesis, métrica primaria, criterio de éxito y tamaño de muestra mínimo antes de proponer nada, porque sabes que sin eso un test no sirve.
• Desarrollo: una Skill de code review que mire legibilidad antes que rendimiento, marque las funciones de más de 20 líneas como candidatas a refactorizar y termine con un resumen ordenado por impacto.

En todos los casos pasa lo mismo: lo escribes una vez y, a partir de ahí, el agente trabaja con tu criterio, no con el suyo. Deja de darte el resultado promedio de internet y empieza a darte el tuyo.

Por qué esto importa

Hay tres problemas que aparecen en cuanto usas un agente de IA de forma habitual, y las Skills atacan los tres.

Criterio. Este es el grande. El modelo sabe hacer la tarea, pero no sabe cómo la harías tú: que en un PRD el problema va antes que la solución, que en un UX audit no se comenta nada que no esté verificado en pantalla, que un experimento sin métrica primaria no se lanza. Una Skill le transfiere ese criterio que tú has ido afinando con los años. Es lo que convierte un output de junior en uno de senior.

Consistencia. El resultado del lunes y el del martes deberían tener la misma calidad. Sin una Skill, dependes de la suerte del prompt. Con ella, el agente sigue las mismas reglas cada vez, y dejas de jugar a la lotería.

Eficiencia. Cada conversación nueva arranca en blanco y acabas reexplicando lo mismo una y otra vez. La Skill lo recuerda por ti; y para el contexto de fondo, el CLAUDE.md que vimos en el artículo anterior hace el resto.

La anatomía de una Skill

El único archivo obligatorio es el SKILL.md, y tiene dos partes.

El frontmatter. Un bloque YAML al principio con, como mínimo, el nombre y la descripción. El nombre se convierte en el comando con el que la invocas. La descripción es lo que Claude lee para decidir si activarla o no.

Tienes dos formas de activarla. La manual, escribiendo /ux-audit directamente en el chat. Y la automática: si la descripción dice algo como «Usa esta Skill siempre que el usuario mencione ‘UX audit'», Claude la activa solo cuando detecta ese tipo de petición, sin que tú la invoques.

En el frontmatter también puedes restringir qué herramientas usa Claude cuando la Skill está activa, con el campo allowed-tools:

--name: uxaudit
description: Audita la UX de un flujo e identifica problemas de usabilidad.
allowed-tools: Read, Grep, Glob
--

En este caso, la Skill solo puede leer. No puede modificar nada. Muy útil cuando quieres que analice sin tocar, como en una auditoría.

El body. Las instrucciones en Markdown. Aquí va el workflow, tu criterio, las herramientas a usar y los recursos disponibles. También es donde puedes definir la estructura exacta del resultado: cómo quieres que se vea el output final, ya sea un informe con sus secciones en un orden concreto o una página con un formato concreto, y cómo se entrega. Así Claude no solo hace la tarea, sino que la presenta tal y como lo harías tú.

A partir de ahí, puedes añadir carpetas según lo que necesite la Skill. En mi Skill de UX Audit, por ejemplo, conviven estas tres:

• references/ para documentación extra que Claude consulta solo cuando hace falta. En mi caso, un archivo por cada marco de análisis: las leyes de UX, las heurísticas de Nielsen, los sesgos cognitivos, el behavioral design, los criterios de accesibilidad WCAG, los patrones de CRO y los patrones de mobile UX. Claude abre el que necesita para cada hallazgo, no todos a la vez. También puedes guardar aquí otro tipo de referencias que Claude deba consultar, como un design.md con los estilos de tu marca. Y lo mejor es que es ampliable: el día que quiera incorporar un marco nuevo, solo añado un archivo más y la Skill lo aprovecha sin tocar el resto.
• scripts/ para código que Claude puede ejecutar. Aquí está, para mí, una de las partes más potentes: yo he escrito los scripts que capturan las pantallas como las capturaría yo, tanto desde Figma como desde una web. Y eso es mucho más que hacer un pantallazo. Saben recorrer un flujo paso a paso, pulsar los botones, abrir los desplegables y los configuradores para ver los estados que no aparecen a simple vista, y generar un inventario del texto real de cada pantalla para que después Claude no se invente nada al analizar. Todo ese saber hacer (qué capturar, en qué orden, cómo no dejarte estados fuera) vive en el código, no tengo que explicárselo cada vez.
• assets/ para archivos base que Claude reutiliza en el resultado: tu logo, una plantilla de informe o un HTML de partida con tu formato. La idea es que el output salga ya con tu estilo.

Cómo carga Claude una Skill

Aquí está una de las partes más interesantes. Claude no carga todas tus Skills de golpe. Usa un sistema llamado progressive disclosure: carga solo lo que necesita, cuando lo necesita. Y funciona en tres niveles.

Nivel 1: nombre y descripción. Es lo único que se carga al inicio de cada sesión. Claude escanea todas las descripciones disponibles y decide cuáles tener en cuenta.

Nivel 2: el SKILL.md completo. Cuando le pides la tarea y tu petición encaja con la descripción, recién ahí lee el archivo entero: el workflow, tus reglas, los criterios.

Nivel 3: scripts, references y assets. Solo se cargan si la tarea concreta los necesita. Si no, es como si no existieran.

Esto tiene una consecuencia muy práctica: puedes tener decenas de Skills instaladas, con mucho contenido cada una, y nada de eso afecta al rendimiento hasta que se usa.

Y de aquí sale la lección más importante de todo el artículo: la descripción es lo más importante que vas a escribir. Si es vaga, Claude no sabe cuándo activar la Skill, y todo lo que escribiste dentro queda invisible. Ten en cuenta también que hay un límite práctico de unos 15.000 caracteres para la lista completa de descripciones; si tienes muchas y muy largas, las últimas pueden quedarse fuera. Cortas y precisas.

Un extra para sacarle aún más partido: puedes diseñar la Skill para ayudar a Claude a cargar solo lo que necesita. Por ejemplo, si ves que hay partes muy extensas que solo aplican a ciertos casos, puedes separar la documentación por casos de uso. Es justo lo que hice con mi Skill de UX Audit: las instrucciones para capturar desde Figma y las de capturar desde una web están en dos archivos separados. Así, en cuanto identifica si es un enlace de Figma o una URL, lee solo la guía que corresponde y se ahorra la otra entera. Menos ruido, más foco y un trabajo más limpio.

Cuándo merece la pena crear una Skill

La señal más clara es muy sencilla: si cada vez tienes que explicar cómo lo harías tú (tu criterio, tu forma de trabajar) y no solo qué necesitas, ya tienes una Skill sin escribir.

Tres casos donde casi siempre vale la pena:

• Cuando el output depende de criterio que el modelo no tiene. Tus estándares, tus convenciones, cómo trabajáis en tu equipo. Si cada vez que pides una landing acabas aclarando que el CTA va arriba, que el tono es cercano pero no informal y que nada de jerga; o si cada vez que pides un componente repites que usas React y que los props necesitan valores por defecto, eso es una Skill.
• Cuando el resultado tiene que ser consistente. Si a veces la presentación arranca con una portada, otras va directa al problema y otras te pregunta qué quieres, es que nadie le ha explicado cómo lo quieres tú.
• Cuando el proceso tiene pasos que se olvidan. Quieres que un análisis siempre valide los datos antes de sacar conclusiones, o que un UX audit verifique cada elemento en pantalla antes de comentarlo. Sin Skill, a veces lo hace y a veces no.

Lo que no tiene sentido: crear una Skill para algo que haces una sola vez, o para tareas donde el contexto cambia tanto que unas instrucciones fijas no ayudan. Una Skill es un marco, no una solución universal.

Skills que puedes usar hoy

Anthropic publica un conjunto de Skills oficiales que puedes instalar directamente, sin tener que crearlas tú. Y lo bueno es que la instalas como le pedirías cualquier cosa a Claude Code, en lenguaje natural: le pasas el enlace de la Skill y le dices que la quieres instalar. Por ejemplo, para añadir Frontend Design:

*Instala esta skill: <https://github.com/anthropics/skills/tree/main/skills/frontend-design*>

Y si prefieres el comando exacto, también puedes registrar el marketplace e instalarla a mano:

/plugin marketplace add anthropics/claude-code
/plugin install frontend-design@claude-code-plugins

Una vez instalada, no tienes que invocarla a mano: Claude activa la Skill cuando le pides crear una interfaz (una landing, un dashboard, un componente).

Estas son algunas de las que mantiene Anthropic:

• Frontend Design. Genera interfaces con criterio de diseño real: tipografía, color, composición y jerarquía. Componentes que se ven trabajados, no genéricos.
• Brand Guidelines. Aplica los colores y la tipografía de tu marca a cualquier cosa que Claude genere, para que todo salga consistente.
• Internal Comms. Redacta comunicaciones internas (informes de estado, anuncios, actualizaciones de proyecto) con un formato cuidado.
• PPTX y DOCX. Crean y editan presentaciones y documentos de Word con layouts, tipografías y formato, sin romper el archivo.
• MCP Builder. Ayuda a construir servidores MCP para conectar Claude con APIs y servicios externos.

Si quieres explorar miles de Skills de la comunidad, puedes hacerlo desde https://skills.sh. Pero aquí toca una advertencia importante: estas Skills no están verificadas por Anthropic. Una Skill puede incluir scripts que Claude ejecuta directamente en tu entorno, con acceso a tus archivos o a servicios externos. Antes de instalar cualquiera de la comunidad, abre el SKILL.md y revisa los scripts. Si hay código que no entiendes, no la instales.

Skills + MCP: el siguiente nivel

Una Skill define cómo trabaja Claude. Un MCP define con qué puede trabajar: es el estándar que lo conecta a servicios externos como tu analítica (GA4, Amplitude, Adobe Analytics…), tu ecommerce o CMS (Shopify, WordPress…) o tu gestor de tareas (Jira, Linear…). Al juntarlos, dejas de darle instrucciones y empiezas a delegarle procesos completos. Si quieres ver un caso real, en un artículo anterior exploré a fondo la potencia del MCP de Figma.

Imagina una Skill que prepara el resumen semanal de tu tráfico web. Le dices «hazme el informe de esta semana» y el agente saca los datos de GA4 a través de su MCP, los cruza con tu criterio y te entrega el informe listo. Tú solo pides el resultado.

Esta combinación es donde las Skills se vuelven de verdad agénticas. Dejas de pedirle cosas a Claude y empiezas a delegarle procesos completos.

Tu primera Skill, paso a paso

El error más común es querer diseñar la Skill perfecta desde el principio. No funciona así. Las mejores se construyen iterando, no planificando.

1. Detecta lo que repites: Esta semana, cada vez que le des contexto antes de pedirle algo, anótalo. No solo el dato («usamos React»), sino sobre todo el criterio: «el tono tiene que ser cercano», «el resumen va siempre al principio», «valida los datos antes de sacar conclusiones». Si lo explicaste más de tres veces, es candidata.
2. Crea la carpeta: Una Skill es una carpeta con el nombre que elijas. Dentro, lo único obligatorio es el archivo SKILL.md; a partir de ahí puedes añadir lo que necesites (references/, scripts/, assets/). Puedes crearla desde tu explorador de archivos o, si prefieres la terminal, con mkdir ~/.claude/skills/nombre-de-tu-skill.
3. Escribe la versión mínima: Crea el archivo SKILL.md dentro de la carpeta que acabas de crear y escribe solo lo esencial para el caso más común. Una Skill de cinco líneas que funciona vale más que una de cien que el agente sigue a medias.
4. Pruébala con casos reales: Ejecuta la misma tarea con y sin la Skill; para usarla, basta con llamarla por su nombre (/nombre-de-tu-skill) o pedir la tarea y dejar que se active sola. Si con la Skill el resultado se parece más a como lo harías tú, vas bien. Si no notas diferencia, es que las instrucciones son demasiado genéricas y aún no le has transferido tu criterio.
5. Itera sobre lo que falla: Cada vez que haga algo que no querías, pregúntate si esa corrección debería estar en la Skill. Si le estás diciendo «el resumen va al principio» por tercera vez, eso va a la Skill.
6. Usa a Claude para mejorarla: Pega tu SKILL.md en una conversación y pídele que detecte instrucciones ambiguas, sugiera ejemplos y afine la descripción. Entiende el formato y te ayuda a iterar mucho más rápido.

Y si quieres ir un paso más allá, Anthropic tiene una Skill oficial llamada skill-creator que te guía en todo el proceso, desde definir el caso de uso hasta escribir el frontmatter y validar las instrucciones. Es, posiblemente, la mejor forma de crear tu primera Skill.

Además, cuando tengas una que funcione bien, no tiene por qué quedarse en tu máquina. Puedes guardarla dentro de un repositorio para que se comparta con tu equipo: escribes tu criterio una vez y todos trabajan con él. Ahí es donde esto escala de verdad, porque dejas de mejorar solo tu trabajo y pasas a subir el listón de todo el equipo.

Buenas prácticas

Estas son las que más impacto tienen en la calidad:

• Sé conciso. Claude ya es inteligente. No le expliques lo que ya sabe. Cada línea compite con el resto del contexto. Si te preguntas «¿de verdad necesita saber esto?», probablemente no.
• La descripción lo es todo. Escríbela en tercera persona, diciendo qué hace la Skill y cuándo activarla. «Procesa archivos Excel» no basta. «Analiza hojas de cálculo, crea tablas dinámicas y genera gráficos. Usar cuando el usuario mencione archivos Excel, datos tabulares o .xlsx» sí.
• Mantén el SKILL.md por debajo de 500 líneas. Si necesitas más, mueve el contenido a references/ y referéncialo. Un nivel de profundidad, no más.
• Usa workflows con pasos claros. Para tareas complejas, define el orden exacto. Paso 1, paso 2, paso 3. Sin eso, Claude decide solo qué hacer primero.
• Implementa loops de validación. Si la Skill genera algo, que lo valide antes de darlo por bueno. Ejecutar, validar, corregir, repetir. La calidad sube muchísimo.
• Dale el nivel de libertad correcto. Si la tarea tiene una sola forma correcta, dásela exacta. Si admite varios enfoques válidos, dale margen.
• Enséñale qué hacer cuando algo falla. A mí lo que mejor me funcionó fue probar la Skill e ir anotando los errores que cometía. Cada vez que se equivocaba, le explicaba cómo resolverlo y qué hacer si volvía a pasar. Su decisión por defecto no siempre es la mejor, y tú normalmente sabes mejor que él cómo actuar ante un problema concreto. En mi Skill de UX Audit, por ejemplo, le enseñé que si una web bloquea el acceso por protección antibot, no se rinda ni se invente lo que ve: que escale a un navegador real con un perfil que parezca de usuario, que es lo que termina pasando el filtro. Ese tipo de instrucción, nacida de un fallo real, es la que convierte una Skill que funciona «a veces» en una que funciona siempre.
• Pruébala con casos reales, no ideales. Una Skill puede funcionar perfecta en teoría y fallar en la práctica. Testear con tareas de verdad es lo único que revela los huecos.

Cómo saber si una Skill funciona

Ejecuta la misma tarea tres veces. Si cada vez parece una conversación distinta, la Skill necesita trabajo. Hay tres señales claras de que algo va mal:

• El agente ignora instrucciones. Le pediste que validara antes de ejecutar y se lo salta. Normalmente la instrucción está enterrada o es ambigua. «Ten en cuenta la seguridad» no es una instrucción, es una sugerencia. «Antes de ejecutar cualquier query, valida que los inputs no contengan caracteres especiales» sí lo es.
• La descripción no encaja. La Skill se activa cuando no debería, o no se activa cuando sí. Revisa la descripción antes que el body, casi siempre el problema está ahí.
• El output es genérico. Se parece a lo que Claude haría sin la Skill. La diferencia entre «hazme un buen informe» y «empieza por la conclusión, apoya cada afirmación en un dato, marca lo que es hipótesis frente a lo confirmado y cierra con los próximos pasos» es enorme.

La pregunta después de cada ejecución es siempre la misma: ¿esto es mejor que lo que habría salido sin la Skill? Si la respuesta no es un sí claro, hay algo que afinar.

Conclusión

Volvamos al principio. Una IA sin tu contexto es un junior brillante: capaz, rápido, pero sin tu criterio. Las Skills son la forma de transferirle ese criterio, de enseñarle a trabajar como lo harías tú después de años en el oficio. Y cuando lo haces bien, el salto se nota: deja de darte el resultado promedio y empieza a darte el tuyo.

Diseñarlas no es trivial. Hay que ser preciso en lo que pides y anticipar casos que no siempre ves a la primera. Pero es una habilidad que se entrena, una mezcla de prompt engineering y testing, y que además te obliga a algo muy sano: poner por escrito ese criterio que normalmente llevas solo en la cabeza.

Una vez que te hace click, empiezas a mirar tu día a día de otra forma. Ves tareas repetidas por todas partes que se pueden convertir en Skills, y el agente empieza a ejecutar las cosas a tu manera, no a la suya. Pasa de junior a senior de tu equipo.

Mi consejo es el de siempre: empieza hoy, con algo pequeño. Una Skill que lea un texto y te devuelva un resumen con los puntos clave y un par de temas para profundizar, hecha a tu manera. No importa si luego la borras. Hazla para entrenar el ojo y aprender a distinguir qué merece ser una Skill y qué no.

Estamos al principio de una forma de trabajar que va a cambiar mucho cómo construimos. Y lo mejor es que puedes empezar a probarla esta misma tarde.

¿Te ha resultado útil? ¿Tienes otra forma de trabajarlo? Me encantaría saberlo. Encuéntrame en LinkedIn y hablamos.