El 22 de octubre, Anthropic dejó de ser la única dueña de Claude Skills: donó el estándar a la Agentic AI Foundation, un proyecto que vive bajo la Linux Foundation. Si todavía no has tocado un Skill, este es un buen momento para empezar — ya no es una función exclusiva de Claude, es un formato que más de 70 plataformas, entre ellas ChatGPT, Cursor, GitHub Copilot y VS Code, empezaron a adoptar desde que se publicó por primera vez en diciembre de 2025.
Qué es un Skill, en la práctica
Un Skill es una carpeta con un archivo SKILL.md que le enseña a Claude cómo resolver algo específico — desde seguir el checklist de code review de tu equipo hasta generar un reporte con el formato exacto que pide tu jefe. En vez de repetir el mismo prompt largo cada vez que necesitas eso, empaquetas la instrucción una sola vez y Claude la carga solo cuando la tarea coincide con lo que describe el Skill. Es básicamente la diferencia entre explicarle algo a un colega nuevo cada lunes y dejarle un documento que él mismo consulta cuando lo necesita.
Por qué ahora es un estándar y no solo una función de Claude
Que el formato pase a la Linux Foundation significa que, en teoría, un Skill que armas para Claude Code también sirve en Cursor o en GitHub Copilot sin reescribirlo desde cero. Para un equipo de desarrollo esto cambia la conversación: ya no se trata de "qué le enseñamos a Claude", sino de "qué le enseñamos a cualquier herramienta de IA que usemos en el equipo, sea cual sea". Dicho esto, en noviembre de 2026 la compatibilidad real todavía varía bastante entre plataformas — no asumas que un Skill complejo corre exactamente igual en todos lados sin probarlo primero en cada una.
Anthropic también actualizó sus recomendaciones de diseño justo este mes, y vale la pena tenerlas presentes antes de armar el primero:
- ▸Dale a Claude solo la latitud que la tarea necesita: Anthropic ahora recomienda pensar en tres niveles, de instrucciones rígidas paso a paso a libertad casi total para que Claude decida cómo resolver.
- ▸Prueba cada Skill en cada modelo que vayas a usar: los modelos de razonamiento más nuevos suelen rendir peor si el Skill los sobre-especifica con demasiado detalle.
- ▸Mantén los archivos de referencia a un solo nivel de profundidad del SKILL.md: si anidas un archivo dentro de otro archivo dentro de otro, Claude puede quedarse a medio camino leyendo esa cadena y perder contexto.
La idea de los tres niveles de latitud merece un ejemplo. Un Skill de "instrucciones rígidas" le dice a Claude paso a paso qué hacer, útil cuando el proceso no puede variar — por ejemplo, el formato exacto de un commit para que pase tu linter de mensajes. Un Skill de "libertad casi total" solo le da el objetivo y el contexto, y deja que Claude decida cómo llegar — útil para algo como "investiga por qué falló este test", donde el camino cambia cada vez. La mayoría de los Skills que vale la pena escribir quedan en un punto intermedio: reglas claras sobre el qué, libertad sobre el cómo.
Lo que nadie te cuenta cuando empiezas: tu primer Skill casi seguro va a quedar demasiado largo. Es más fácil escribir instrucciones exhaustivas para cubrir cada caso que confiar en que Claude va a inferir el resto solo — y eso termina saliendo caro, tanto en tokens como en rigidez cuando la tarea cambia un poco.
Un ejemplo concreto para entender la diferencia
Imagina que en tu equipo cada pull request necesita un resumen con un formato específico: qué cambió, por qué, y qué se probó. Sin Skill, le explicas eso a Claude cada vez que lo usas, o lo pegas de un documento aparte y esperas que no se te olvide ningún punto. Con un Skill, guardas esa estructura una sola vez en un SKILL.md con una descripción clara — "usar cuando el usuario pida un resumen de pull request" — y Claude la detecta sola la próxima vez que la tarea calza. La diferencia no es que Claude haga algo que antes no podía hacer; es que deja de depender de que tú te acuerdes de pedirlo bien cada vez.
Esto se vuelve más interesante en equipo: si cuatro developers usan Claude Code con el mismo Skill de code review versionado en el repo, el criterio deja de depender de quién escribió el prompt ese día. Es la misma lógica de un linter, pero para juicio de negocio en vez de sintaxis.
Cómo crear tu primer Skill sin complicarte
No necesitas nada exótico: una carpeta con un SKILL.md que describa en lenguaje simple cuándo usarlo y qué hacer. Empieza con una tarea repetitiva de verdad — un formato de commit, una plantilla de reporte semanal, un checklist de QA que siempre se te olvida un paso — y deja que el Skill crezca solo cuando notes que Claude se equivoca dos veces en el mismo punto. Ese es el momento de agregar una regla más, no antes.
Qué revisar antes de dejar que todo el equipo use el mismo Skill
Un Skill mal escrito escala el error tan rápido como escala el beneficio. Si tu checklist de code review tiene un punto equivocado, ahora los cuatro developers del equipo lo están aplicando mal, no solo uno. Antes de compartir un Skill más allá de tu propio uso, vale la pena que alguien más lo pruebe con un caso real y revise si el resultado coincide con lo que el equipo espera — lo mismo que harías antes de mergear cualquier cambio a una configuración compartida.
Qué pasa con los Skills que ya tenías antes de octubre
Si venías usando Skills desde que se publicaron en diciembre de 2025, no necesitas reescribir nada: la donación a la Linux Foundation formaliza el estándar que ya existía, no lo rompe. Lo que sí vale la pena revisar son los Skills que armaste en los primeros meses, cuando la documentación era más escasa y la mayoría terminamos escribiendo instrucciones más largas de lo necesario por las dudas. Con las recomendaciones de octubre ya publicadas, es un buen momento para releer tus SKILL.md más viejos y recortar lo que sobra — menos texto suele significar un Skill más confiable, no uno más débil.
Dónde aprender esto con proyectos reales
En el curso de Claude Code para developers vemos cómo construir Skills, subagentes y flujos de trabajo completos dentro de tu propio repositorio — no son slides, son proyectos que terminas corriendo en tu terminal. Si lo que te interesa es ir un paso más allá y construir agentes completos, no solo Skills sueltos, la ruta AI Agentic Engineer cubre justamente eso, desde el diseño del agente hasta ponerlo en producción.
Si prefieres resolver dudas en vivo en vez de solo leer documentación, cada semana armamos un taller práctico en la Comunidad AI Builders — ahí puedes mostrar tu Skill y que alguien más lo rompa antes de que lo uses en producción.
Claude Skills va a seguir evolucionando ahora que es un estándar compartido entre varias plataformas — la base que no cambia es entender bien a Claude Code primero. Revisa el catálogo completo de cursos si quieres ver por dónde seguir.
