- Claude Skills, presentado por Anthropic, es un nuevo patrón en el que las instrucciones, scripts y recursos necesarios para que el modelo realice tareas específicas se proporcionan en forma de carpetas, permitiendo cargar dinámicamente especialización por tarea
- Skills se compone de archivos Markdown y scripts opcionales; al iniciar la sesión solo se carga el metadato de cada skill con unas cuantas decenas de tokens, y el contenido completo se trae solo cuando realmente hace falta, lo que ofrece una eficiencia de tokens muy alta
- A través de Claude Code, Skills va más allá de una simple herramienta de programación y se expande como un agente de automatización de propósito general; con solo un sistema de archivos y un entorno para ejecutar comandos, puede automatizar tareas muy diversas
- A diferencia de MCP, Skills no es un protocolo sino una estructura simple basada en Markdown y YAML, por lo que puede usarse de inmediato también con otros modelos o herramientas, y resulta fácil de compartir y difundir
- Gracias a esa simplicidad y eficiencia, se espera que Skills expanda su ecosistema mucho más rápido que MCP, y permita construir agentes especializados en áreas que van desde el periodismo de datos hasta guías de marca (evitando los problemas de consumo de tokens y la complejidad de especificación de MCP)
Concepto y estructura de Skills
- Anthropic anunció oficialmente Claude Skills el 16 de octubre de 2025
- Un sistema de ampliación de capacidades por carpetas que contiene instrucciones, scripts y recursos necesarios para que el modelo realice tareas específicas (por ejemplo, trabajar con Excel o seguir la guía de marca de una organización)
- Claude accede a ese skill solo cuando es relevante para la tarea, mejorando así su capacidad para ejecutar trabajos especializados
- El repositorio de GitHub anthropic/skills ofrece ejemplos oficiales de skills
- Conceptualmente, Skills es extremadamente simple
- La pieza central es un archivo Markdown que le explica al modelo cómo realizar la tarea
- Opcionalmente puede incluir documentación adicional y scripts ya preparados para ayudar a completar el trabajo
- La función de generación de documentos de Claude anunciada en septiembre en realidad estaba implementada por completo con Skills
- En el repositorio público pueden verse skills para procesar archivos
.pdf, .docx, .xlsx y .pptx
Eficiencia de tokens: la ventaja clave de Skills
- Al iniciar una sesión, Claude escanea todos los archivos de skills disponibles y solo lee una breve descripción del frontmatter YAML de cada skill
- El costo inicial en tokens de cada skill es de apenas unas decenas, lo que lo hace extremadamente eficiente
- Solo cuando el usuario pide una tarea en la que un skill podría ayudar, se cargan todos los detalles
- Esto no es simplemente guardar archivos en disco: es la diferencia clave que lo convierte en una capacidad funcional
Caso práctico: skill para crear GIFs de Slack
- Descripción de los metadatos del skill slack-gif-creator
- Un toolkit para generar GIF animados optimizados para Slack
- Incluye un validador de restricciones de tamaño y bloques básicos de animación combinables
- Se aplica a solicitudes como: “Hazme un GIF para Slack de X haciendo Y”
- Proceso de prueba real
- Activación del skill slack-gif-creator en la app web móvil de Claude con el modelo Sonnet 4.5
- Ingreso del prompt:
Make me a gif for slack about how Skills are way cooler than MCPs
- Claude genera el GIF automáticamente (la calidad aún necesita mejorar, pero el skill puede iterarse fácilmente)
- Aspectos destacados del script de Python generado
- Agrega el directorio del skill a la ruta de Python:
sys.path.insert(0, '/mnt/skills/examples/slack-gif-creator')
- Usa la clase
GIFBuilder del directorio core/ del skill
- Guarda el archivo en
/mnt/user-data/outputs/
- Verifica el cumplimiento con el uso de la función de validación del límite de tamaño de Slack (2 MB)
check_slack_size()
- Si el tamaño supera el límite, el modelo puede intentar regenerar automáticamente un archivo más pequeño
Dependencias del entorno para Skills
- Para que el mecanismo de Skills funcione por completo, el modelo debe poder acceder a lo siguiente
- Sistema de archivos
- Herramientas para explorar el sistema de archivos
- Capacidad de ejecutar comandos en el entorno
- Este es un patrón común en el tooling de LLM
- ChatGPT Code Interpreter fue el primer caso masivo a inicios de 2023
- Después se expandió a máquinas locales con herramientas de agentes de programación como Cursor, Claude Code, Codex CLI y Gemini CLI
- Este requisito marca la mayor diferencia frente a intentos anteriores de ampliar capacidades de los LLM, como MCP o ChatGPT Plugins
- Es una dependencia importante, pero la magnitud de las nuevas capacidades que desbloquea es sorprendentemente grande
- La seguridad sigue siendo importante
- Hace falta ofrecer un entorno de programación seguro
- También se necesita una forma de construir un entorno sandbox que limite ataques como el prompt injection a un nivel de daño aceptable
Claude Code: evolución hacia un agente de propósito general
- En enero de 2025, el autor predijo que los “agentes” fracasarían, pero se equivocó por completo
- 2025 terminó siendo de hecho el año de los “agentes” (aunque existan varias definiciones, aquí se define como tools in a loop)
- Claude Code tiene un nombre engañoso
- No es una herramienta puramente de programación, sino una herramienta de automatización informática de propósito general
- Puede automatizar cualquier tarea que pueda lograrse introduciendo comandos en una computadora
- La mejor descripción sería la de un agente general
- Skills hace esta posibilidad mucho más clara y explícita
- El abanico de aplicaciones es mareantemente amplio
- Ejemplo en periodismo de datos: puede organizarse una carpeta de skills para tareas como
- Entender las fuentes y la estructura de los datos del censo de EE. UU.
- Cargar datos de varios formatos en SQLite/DuckDB usando bibliotecas de Python
- Publicar datos en línea como archivos Parquet en S3 o tablas de Datasette Cloud
- Encontrar historias interesantes en nuevos datasets (con guía de un reportero de datos con experiencia)
- Construir visualizaciones de datos limpias y legibles con D3
- Resultado: con solo archivos Markdown y algunos ejemplos de scripts en Python, ya se puede construir un “agente de periodismo de datos” capaz de descubrir y publicar historias a partir de datos del censo de EE. UU.
Comparación entre Skills y MCP
- Model Context Protocol (MCP) atrajo enorme atención desde su lanzamiento en noviembre de 2024
- Todas las empresas necesitaban una “estrategia de IA”, y anunciar una implementación de MCP era una forma fácil de cubrir esa necesidad
- Poco a poco fueron apareciendo las limitaciones de MCP
- El problema más importante es el uso de tokens
- El MCP oficial de GitHub por sí solo consume decenas de miles de tokens de contexto
- Si se agregan algunos más, casi no queda espacio para que el LLM haga trabajo realmente útil
- Desde que el autor empezó a tomarse en serio a los agentes de programación, su interés por MCP disminuyó
- Casi todo lo que puede lograrse con MCP puede sustituirse por herramientas CLI
- El LLM sabe cómo invocar
cli-tool --help, así que no hace falta gastar muchos tokens en explicar su uso
- El modelo puede averiguarlo por sí mismo cuando lo necesite
- Skills ofrece exactamente la misma ventaja, e incluso más, porque ni siquiera hace falta implementar una nueva herramienta CLI
- Basta con soltar un archivo Markdown que explique cómo hacer la tarea
- Solo se añaden scripts extra cuando ayudan a mejorar la estabilidad o la eficiencia
Perspectiva de crecimiento explosivo del ecosistema de Skills
- Uno de los aspectos más interesantes de Skills es lo fácil que resulta compartirlo
- Se espera que muchos skills se implementen en un solo archivo
- Los más sofisticados tomarán la forma de una carpeta con unos cuantos archivos
- Materiales proporcionados por Anthropic
- El autor también está pensando en ideas de skills como cómo construir un plugin de Datasette
- También puede usarse con otros modelos: otra ventaja del diseño de Skills
- Si conectas una carpeta de skills a Codex CLI o Gemini CLI y dices “lee
pdf/SKILL.md y crea un PDF que explique este proyecto”, funciona
- Eso es posible aunque la herramienta y el modelo no tengan conocimiento incorporado del sistema de skills
- Predicción: ocurrirá una explosión cámbrica de Skills capaz de hacer ver pálido el rush de MCP de este año
La simplicidad es la fortaleza principal
- Algunas personas reaccionan diciendo que Skills es demasiado simple como para considerarlo una funcionalidad
- Mucha gente ya venía experimentando con el truco de poner instrucciones adicionales en archivos Markdown y hacer que los agentes de programación las leyeran
- AGENTS.md ya es un patrón bien establecido, y puede incluir instrucciones como “lee PDF.md antes de generar un PDF”
- La simplicidad central del diseño de Skills es precisamente lo que entusiasma al autor
- MCP es toda una especificación de protocolo
- Hosts, clientes, servidores, recursos, prompts, herramientas, sampling, roots, elicitation
- Incluye tres métodos de transporte (
stdio, HTTP transmisible y originalmente SSE)
- Skills es Markdown + un poco de metadatos YAML + scripts ejecutables opcionales
- Está mucho más cerca del espíritu de los LLM: lanzar texto y dejar que el modelo resuelva el resto
- Skills subcontrata las partes difíciles al arnés del LLM y al entorno informático relacionado
- Considerando todo lo que se ha aprendido en los últimos años sobre la capacidad de los LLM para ejecutar herramientas, es una estrategia muy inteligente
12 comentarios
Creo que también podría integrarse al usar Claude Code para programar.
Ahora mismo también tengo guías puestas en
Claude.mdy voy avanzando separando cada guía detallada por su cuenta.Si se quiere realizar mucho trabajo con pocos tokens, parece que podría resolverse de forma sencilla usando multiagentes y resúmenes, más que optimización de prompts. Estoy de acuerdo con el problema, pero la forma de resolverlo me da la impresión de tener limitaciones.
¿Skills también usa tokens? Si es así, parece que volvería a surgir el problema del consumo de tokens, pero no tengo muy claro cómo responderían en ese caso.
Parece que en el contexto no entra siempre todo
SKILLS.md, sino que al principio se incluye de forma fija solo la parte del nombre y la descripción, como lo de abajo.name: skill-creator
description: Guía para crear skills efectivas. Esta skill debe usarse cuando los usuarios quieran crear una skill nueva (o actualizar una existente) que amplíe las capacidades de Claude con conocimiento especializado, flujos de trabajo o integraciones de herramientas.
license: Complete terms in LICENSE.txt
Cuando trabajas con Claude Code, terminas alimentándole instrucciones o reglas al contexto una y otra vez, y al final acabas pensando en el equilibrio entre el uso de tokens y el contexto. Entonces se me ocurrió crear una carpeta, escribir ahí los detalles en archivos
.mdseparados por función, y dejar enclaude.mdsolo un montón de punteros de qué mirar para hacer cada cosa; y funcionó bastante bien y a bajo costo. Si al finalSkillsno es más que una recopilación de algo así, entonces parece que va a ser bastante útil.Y además, si como anunciaron también sale un marketplace de skills, me pareció que estaría bastante bien poder tomar solo las skills necesarias y activarlas cuando haga falta.
Oh, gracias por la explicación clave.
¿Qué relación habrá entre el manejo de contexto y las Claude Skills? Yo ya estaba pensando: ¿en qué se diferencian de los comandos personalizados de Claude Code que ya existían antes? Pero al leer la documentación, sentí que la diferencia más grande es, sin duda, que dentro de una sola skill se puede incluir y ejecutar código de script como Python o JavaScript.
Opiniones en Hacker News
Para mí, Claude Skills parece una prueba de que RAG se volvió innecesariamente difícil desde el punto de vista de la experiencia de usuario. No es que sea técnicamente complejo; el problema es el UX. Si esa parte se resolviera bien, creo que Claude Skills en sí dejaría de ser necesario. Lo que Claude Skills hace mejor que MCP es que es fácil de crear. Como se puede hacer simplemente escribiendo, cualquiera puede usarlo. Pero depende mucho del entorno. Por ejemplo, si se necesita una herramienta específica para que funcione, ¿cómo se configura el sandbox para automatizar eso? Incluso es difícil tener certeza de si se está usando la versión correcta
En mi empresa estamos intentando algo parecido internamente. Como los archivos de contexto de nuestro monorepo se volvieron demasiado grandes, construimos un árbol de fragmentos que se carga de forma progresiva según la tarea. Estos documentos de contexto se parecen muchísimo a la documentación tradicional para desarrolladores, pero en la práctica son mucho más útiles y orientados a tareas. Me hace preguntarme por qué no habíamos podido crear este tipo de documentos antes.
Esto es básicamente un problema de principal-agente mezclado con algo del marshmallow test. Si un desarrollador escribe documentación para otras personas y no para una IA, no sabe quién la va a leer, qué necesita esa persona, ni siquiera si realmente la verá. Claro, puede que también le sirva a él más adelante, pero es difícil entenderlo así o tener el tiempo y la disciplina para hacerlo. En cambio, si la IA usa la documentación para ayudarme directamente, aparece una motivación inmediata enorme para registrar la información necesaria. Además, el ciclo de retroalimentación también se vuelve más corto. Por cierto, como los comentarios de código tienden a desaparecer con los LLM, últimamente estoy dejando más documentación y reduciendo muchísimo los comentarios
Los desarrolladores nuevos no suelen quejarse de que la documentación está hecha un desastre porque sienten que quedarían como tontos. El autor ya tiene el modelo mental en la cabeza, así que no percibe bien el problema, y escribir buena documentación era como poner en riesgo su propio puesto. Pero si le entregas documentación desordenada a un robot tonto, si no funciona bien, tienes que culparte a ti mismo. Al final, creo que es #2 + #3. El gran cambio es que la “reemplazabilidad” pasó de algo negativo a algo positivo (te reemplazas tú mismo con un agente antes de que un agente barato te quite tu lugar)
Es parecido a por qué existe la deuda técnica: presión del negocio, mal diseño, falta de recursos. Antes era realmente muy costoso mantener una buena documentación cada vez que cambiabas el código
Cuando dijeron que imaginara varias skills dentro de una carpeta, pensé en algo que cubriera tareas como ubicar datos del censo de EE. UU. o interpretar su estructura. Apenas escuché eso, me acordé de la primera vez que usé Wolfram Alpha. A diferencia de un buscador general, me dejó impresionado resolver problemas con una herramienta verdaderamente estructurada. La volví a usar ahora y sigue siendo increíble: Consultar la población de EE. UU. con Wolfram Alpha. El modelo de Skills que tengo en la cabeza se parece a agregar extensiones personalizadas a Wolfram Alpha
Hice clic en el enlace que compartiste y en Wolfram Alpha la consulta se abre como
what%27s the total population of the United States%3F. El resultado es curioso: muestra6.1% mod 3 °F (2015-2019 American Community Survey 5-year estimates). Me pregunto cómo calculó esoSinceramente, el Wolfram Alpha de antes fue una locura de logro. Todavía me asombra cómo pudieron implementar en esa época, sin IA, un sistema que manejara incluso problemas matemáticos complejos
Me confunde un poco la diferencia entre Skills y las herramientas tradicionales. Muchas skills podrían verse simplemente como herramientas, o como un conjunto de varias herramientas con una explicación añadida. Pero ¿la definición de herramienta y la definición de skill no están en lugares distintos? Me pregunto cómo se expresa la dependencia entre ambas. Si una skill especifica “requiere uso de línea de comandos, python, tool A y tool B”, ¿eso significa que al cargar la skill esas herramientas también se activan juntas?
Lo realmente notable es que todo el mundo se obsesionó con MCP y actuó con dependencia del camino. Lo verdaderamente interesante es simplemente el “tool call” en sí. El tool call es realmente útil y sorprendente. MCP es solo uno de varios medios para lograrlo. Y ni siquiera es una forma tan buena
Creo que MCP se expandió tanto porque el timing lo fue todo. Ya existía la llamada de herramientas antes de MCP, pero los modelos no lo hacían bien. La llegada de MCP coincidió justo con el momento en que los modelos empezaron a hacerlo bien. Así que, en el fondo, lo esencial del boom de MCP es que la gente descubrió que los LLM pueden invocar herramientas para interactuar con otros sistemas
Un servidor MCP es básicamente un registro para registrar tool calls. Entonces, ¿qué tiene de peor frente a un tool call común?
Lo valioso de MCP es que le enseña al LLM el concepto de oauth. Por eso fue posible la llamada de herramientas basada en servidores. Antes, había que instalar por separado cada cli que quisieras usar y gestionar la autenticación por tu cuenta dentro de cada una. Estoy de acuerdo en que el tool calling es la mayor fortaleza de los LLM, pero también creo que fue bastante valioso que quedara claro el mensaje de “hay que prestar atención a la autenticación de herramientas”
Por cierto, eso también muestra que MCP fue una funcionalidad innovadora de Anthropic
Incluso dejando de lado Skills, me pregunto qué forma habría mejor que MCP
El impacto de MCP va mucho más allá de la terminal. Se puede usar en ChatGPT, Claude Web, n8n y LibreChat, y también se consideraron autenticación, recursos e incluso UI (
apps-sdk, etc.). Si te enfocas en flujos de trabajo de programación o agentes basados en CLI (como Claude Code), las herramientas CLI tienen muchísimo valor, pero en áreas como CRM, ventas, soporte, operaciones y finanzas, las herramientas basadas en MCP son una forma más adecuada. Skills y MCP no compiten; tienen propósitos complementarios. El verdadero salto ocurre cuando el código Python de Skills puede invocar directamente MCP mediante el intérprete (nosotros también lo probamos y funciona muy bien)Una de las grandes ventajas de MCP frente a las herramientas basadas en terminal es que puede funcionar sin un sandbox como un entorno Linux completamente aislado. Y también puede usarse con modelos mucho más simples. Incluso modelos que corren en una laptop o hasta en un teléfono pueden manejar perfectamente dos o tres MCP. Sinceramente, pedirle a esos modelos que lean archivos y además hagan
curlde forma confiable ya es demasiadoIntegrar LLM con software externo o con el mundo físico se siente realmente genial hoy en día. Todo esto es posible en lenguaje natural. Incluso el propio LLM puede generar el código del servidor MCP, así que es posible crear capacidades totalmente nuevas con facilidad
Sinceramente, creo que MCP está sobrevalorado y que sus límites también son claros. El 95% de los servidores MCP actuales no sirven para nada y se podrían reemplazar sin problema por un simple tool call
Aunque suene obvio, un servidor MCP bien hecho es realmente bueno. En cambio, un servidor MCP mal hecho crea problemas todavía peores. Normalmente, todos los equipos de producto reciben la presión de que “MCP está de moda”, así que sienten que tienen que construir un servidor MCP sí o sí. Los clientes también siempre tienen objetivos relacionados con usar IA, así que piden este tipo de cosas. Pero en realidad no saben qué quieren; les basta con poder decir “tiene IA”. Así, los equipos de producto pueden promocionar rápidamente “somos un producto de IA” gracias a MCP, aunque la adopción de IA no tenga un efecto claro. Es un fenómeno bastante desconectado de la esencia de la IA
Solo puedes usar MCP si confías en quien provee el servidor. En la práctica, dependes de la honestidad del servidor. En realidad, empresas como Uber seguramente van a usar todo tipo de prompt engineering para empujar constantemente al LLM a considerar que su servicio es la mejor opción. Al final, los incentivos entre el publisher de MCP y el consumidor están completamente desalineados
Coincido en que al final el tool call es lo esencial. Pero MCP tiene al menos dos ventajas frente a CLI. Una es que, cuando un LLM con tool calling necesita implementar interacciones complejas exigiendo salidas estructuradas, MCP es más fácil que CLI. La otra es que en un servidor MCP puedes mantener el estado entre tool calls de forma natural. Al principio yo también pensé que quizá me estaba dejando llevar demasiado por el hype, pero hace poco construí una demo pequeña para aprender MCP (https://github.com/cournape/text2synth) y me resultó más fácil que hacerla con CLI. Creo que ejemplos así muestran bien el potencial curioso de MCP
Los servidores MCP parecen ser extremadamente populares entre hackers. Hay demasiadas instancias mal configuradas y desplegadas de manera descuidada. Las empresas han eliminado todas sus defensas habituales de despliegue
Nuestro equipo de frontend está sacando muchísimo valor del MCP de Figma. Pudimos terminar en un día algo que habría tomado tres semanas
Yo también hice algo equivalente a skills con unos cuantos archivos markdown. Basta con recordarle la skill al agente una vez por sesión. No entiendo bien qué tiene de especial que Claude haga esto
Una parte importante es ponerle nombre a una especie de patrón. Ya era un patrón útil que mucha gente había descubierto y usado de forma natural, pero al tener nombre permite discusiones de mucho más nivel. Anthropic además detectó que este patrón ayuda a resolver el problema crónico de los agentes de programación: la “contaminación de contexto”. Antes,
AGENTS.mdo MCP metían demasiada información en el contexto y se volvían poco prácticos, pero el patrón de skills es mucho más eficienteSe siente como estructurar oficialmente un problema ya resuelto y agregar un poco más de automatización. Entre los MCP que había usado antes, muchos no eran más que una búsqueda documental elegante, y espero que skills de este tipo los reemplacen
Yo tengo la misma duda. Llevo más de un año usando esto con Aider o CC
Esto quizá suene un poco negativo, pero quiero ver si alguien más siente lo mismo. Si le pides al usuario promedio que configure por sí mismo este tipo de servicios, su reacción correcta sería “¿estás loco?”. La mayoría solo quiere iniciar sesión, pedir algo y que el sistema se encargue del resto. MCP, Apps, Skills, Gems, todo eso está atacando el problema equivocado. Se parece a esos canales de YouTube que cada seis meses dicen “el nuevo lenguaje o framework de programación es el mejor”, hacen una app de tareas y pueden repetir básicamente el mismo video hasta seis veces. Solo hay mejoras superficiales repetitivas y el problema de fondo sigue sin resolverse. Algo salió mal en alguna parte del género tecnológico, y cuando entra dinero a raudales solo salen este tipo de anuncios, luego sacan el siguiente release, ascienden, cambian de trabajo y no queda ningún valor esencial
Sobre la afirmación de que no se está resolviendo el problema de fondo: hoy en día las soluciones ya vienen empaquetadas con problemas completamente nuevos. Abres la caja y el problema y la solución saltan juntos, persiguiéndose y escapando uno del otro. Y uno siente que se volvió un ser humano técnicamente más avanzado
Respecto a la idea de que MCP, Apps, Skills, Gems y todo lo demás están atacando el problema equivocado, desde mi perspectiva pesimista estamos creando más documentación y más APIs para la IA, cuando probablemente el resultado habría sido parecido si hubiéramos hecho esa documentación para personas. La mitad de mi tiempo se iba arrastrada por depurar sistemas complejos sin documentación
Me pregunto cuál sería exactamente el “problema de fondo” y cada cuánto se resolvía ese tipo de “problema de fondo” antes de la popularización masiva de ChatGPT en 2023
Tomando como ejemplo eso de “hacen la misma app de tareas seis veces y luego la olvidan”, no entiendo muy bien cuál es el problema. La tecnología siempre avanza de manera gradual e iterativa. Mañana alguien volverá a subir un video sobre el mejor framework de frontend, y antes fue Nextjs, antes React, Angular, JQuery, PHP, HTML, y así lo mismo una y otra vez. Si no se hubiera volcado tanto capital a la IA, probablemente seguiríamos estancados en GPT-3 y Claude 2. A veces también salen cosas medio chafas a nivel de herramientas (yo creo que Skills está bastante bien), pero no por eso diría que toda la industria está podrida
Bueno, todo esto todavía está en una etapa muy inicial y nadie sabe realmente qué funciona de verdad. Parece un intento superficial, pero en realidad está en la frontera más avanzada
Esto es un concepto completamente distinto. MCP incluye conexión con servicios externos e incluso manejo de autenticación como oauth. Skills es básicamente una combinación de herramientas CLI + prompts. Como sus áreas de uso son distintas, no se pueden comparar fácilmente. Por cierto, antes de que apareciera MCP nosotros también habíamos creado y usado un sistema llamado Skillset, y ahora que lo veo pienso que era el mejor híbrido posible, porque combinaba las ventajas de MCP y Skills
Es puro escándalo exagerado, de verdad.