Agent Skills - personalizar la IA según tu flujo de trabajo

 (anthropic.com)
17 puntos por GN⁺ 2025-10-17 | 4 comentarios | Compartir por WhatsApp
  • Agent Skills de Anthropic permite ampliar la especialización de la IA según el flujo de trabajo del usuario
  • Un Skill es un componente organizado por carpetas que incluye instrucciones, scripts y recursos, y Claude lo carga solo cuando lo necesita durante una tarea
  • Otorga capacidades especializadas para áreas de trabajo específicas, como crear archivos de Excel y PowerPoint o seguir guías de marca
  • Los usuarios o desarrolladores pueden crear Skills directamente para usarlos en Claude app, Claude Code y en toda la API
  • También está previsto que admita funciones de despliegue y administración a nivel empresarial, por lo que servirá como base para construir flujos de trabajo de IA personalizados

Resumen de Skills y cómo funciona

  • Con la función Agent Skills, Claude puede usar habilidades personalizadas para desempeñarse mejor en tareas específicas
  • Los Skills se ofrecen en forma de carpetas que incluyen instrucciones, scripts y recursos, y Claude accede a ese Skill solo cuando necesita una tarea relacionada
  • Esto permite aprovechar mucho mejor a Claude en trabajos especializados, como la gestión de documentos de Excel o el cumplimiento de lineamientos de marca de una organización
  • Los usuarios pueden crear Skills personalizados para usarlos de forma integral en Claude app, Claude Code y la API

Cómo funcionan los Skills

  • Claude tiene un algoritmo que escanea todos los Skills disponibles durante la ejecución de una tarea para encontrar el más relevante
  • Si encuentra un Skill coincidente, carga solo la información y los archivos mínimos necesarios, lo que mantiene la velocidad mientras asegura capacidad para tareas especializadas
  • Características de los Skills
    • Composición: se pueden usar varios Skills juntos, como si se apilaran, y Claude ajusta automáticamente cuáles necesita
    • Portabilidad: están escritos en el mismo formato, por lo que pueden usarse en toda la familia de productos Claude
    • Eficiencia: solo carga la funcionalidad necesaria en el momento necesario
    • Potencia: también pueden incluir código ejecutable (p. ej., Python, Shell), por lo que pueden aprovechar la eficiencia de la programación tradicional
  • Los Skills se conciben como material de onboarding personalizado que empaqueta el conocimiento especializado de una organización para entregárselo a Claude, de modo que esa experiencia quede empaquetada y Claude pueda actuar como experto en un dominio específico

Integración con los productos Claude

Claude Apps

  • Los usuarios de Pro, Max, Team y Enterprise pueden usar la función de Skills
  • De forma predeterminada, se ofrecen varios Skills de ejemplo para tareas generales, como redacción de documentos, y también pueden personalizarse directamente
  • Cuando el usuario ingresa una tarea, Claude carga automáticamente el Skill adecuado, y el funcionamiento del Skill también puede verse dentro de la cadena de pensamiento
  • El Skill skill-creator facilita la creación de Skills con guía conversacional, consultas sobre el flujo de trabajo, generación de estructura de carpetas, formateo automático de SKILL.md, empaquetado de recursos y más
  • En Team/Enterprise, un administrador debe activar la función a nivel organizacional
  • Disponible en la página de configuración

Claude Developer Platform (API)

  • Mediante solicitudes a la Messages API y el nuevo endpoint /v1/skills, se puede gestionar el versionado y el control operativo de Skills personalizados
  • Para usar Skills se requiere la función beta Code Execution Tool, que proporciona un entorno seguro de ejecución de código
  • Con los Skills proporcionados por Anthropic, es posible crear y editar documentos de nivel profesional en Excel, PowerPoint, Word y PDF
  • Los desarrolladores pueden crear Skills personalizados para flujos de trabajo específicos y ampliar libremente los usos de Claude
  • Claude Console permite crear, consultar y actualizar versiones de Skills fácilmente
  • Se puede aprender más en la documentación y en Anthropic Academy

Casos de uso de socios

  • Box: convierte automáticamente contenido almacenado para generar documentos de PowerPoint, Excel y Word, y apoya la documentación automatizada alineada con los estándares de la organización
  • Notion: convierte preguntas complejas en acciones ejecutables al instante, y reduce la carga de tener que ajustar prompts
  • Canva: personaliza agentes mediante Skills para automatizar diseño y apoyar la producción de contenido de alta calidad a nivel de equipo
  • Rakuten: usa Skills para automatizar finanzas y contabilidad, procesar varias hojas de cálculo de forma integrada y reducir el tiempo de creación de reportes de 1 día → 1 hora

Integración con Claude Code

  • Claude Code admite la instalación de Skills para ampliar la especialización y los flujos de trabajo del equipo
    • Se pueden usar mediante el plugin del marketplace anthropics/skills o agregando carpetas directamente en ~/.claude/skills
  • Ofrece funciones para compartir Skills y colaborar entre equipos mediante integración con sistemas de control de versiones
  • También admite el desarrollo de agentes personalizados mediante Claude Agent SDK

Cómo empezar

Planes futuros y consideraciones

  • En el futuro se prevé simplificar el proceso de creación de Skills y reforzar las funciones de despliegue a nivel organizacional
  • Como los Skills permiten que Claude ejecute código, solo deben usarse Skills de fuentes confiables
  • Es importante prestar atención a la protección de datos y al mantenimiento de la seguridad; para más detalles, consulta la guía

Lecturas relacionadas

4 comentarios

 
ahwjdekf 2025-10-21

Asa una papa, hiérvela, saltéala, guísala, tritúrala...
 
ahwjdekf 2025-10-21

Cada vez le ponen toda clase de nombres rimbombantes. Al final, todo sabe a papa.
 
GN⁺ 2025-10-17
Opiniones de Hacker News

  • Da la impresión de que, igual que pasó antes en el desarrollo frontend, habrá bastante confusión conceptual alrededor de ChatGPT, Claude y compañía. Ahora están desbordándose conceptos como herramientas, funciones, skills, agentes, subagentes, comandos, apps, etc., y encima de esa confusión siguen apareciendo todo tipo de frameworks de “vibe”.

    • Tampoco hay que olvidarse de las funciones relacionadas con MCP. Sí, de acuerdo, hay confusión, pero debajo de todo eso hay conceptos básicos fáciles de aprender. Aunque se agreguen funciones nuevas, se pueden acomodar fácilmente dentro de un modelo mental, o incluso ignorarlas por completo y construir tus propias herramientas para usarlas directamente, que también es una buena opción. Ese modelo mental básico consiste en llamar al LLM en un bucle, guardar continuamente en la sesión el historial de lo que fue haciendo (= contexto) y permitir llamadas a herramientas como lectura de archivos, escritura, invocación de bash, etc. A eso también se le puede llamar “agent loop”, y hasta se puede implementar con 100 líneas de Python. Si eres desarrollador y te interesan los LLM, de verdad te recomiendo que lo construyas tú mismo. Una vez que lo haces, de verdad te cambia la perspectiva. Si creas un agente simple por tu cuenta, aunque aparezcan herramientas nuevas podrás explicar fácilmente cómo funcionan desde el punto de vista de implementación. Por ejemplo, Claude Skills sería: 1) varios archivos con instrucciones para el LLM, 2) al iniciar solo revisa qué skills están disponibles y reúne en el contexto del LLM descripciones breves, 3) le indica al LLM cómo usar esas skills y, en Claude, usa la herramienta bash, 4) cuando realmente va a usar una skill, hace “call bash” para leer el archivo y ejecutar la tarea. Claro, aquí estoy omitiendo detalles importantes como la gestión de permisos, pero la estructura central es esa.
    • Siento que el ecosistema ya se volvió tan complejo que hasta podría colapsar por sí solo. Todo sistema o plataforma tiene algo así como un presupuesto total de complejidad que la gente puede retener en su memoria cotidiana, y en qué se gasta ese presupuesto es especialmente importante. Cuando el proveedor de la plataforma agrega nueva complejidad, eso se descuenta del valor que se puede construir encima. Últimamente los proveedores agregan complejidad sin parar para diferenciarse, pero al final solo elevan la barrera de entrada para los clientes que realmente necesitan y además reducen el valor real que se puede construir sobre la plataforma. Incluso ahora parece que conceptos redundantes y parecidos se están comiendo ese nuevo presupuesto de complejidad sin aportar muchas funciones adicionales. Internamente quizá se engañen pensando “si metemos esto será más fácil de aprender”, pero en la práctica puede que por cada persona que atraen expulsen a otra, así que quizá el balance no sea muy bueno.
    • Como es una tecnología completamente nueva, todavía hay demasiadas zonas desconocidas. Elegir herramientas cloud o librerías de Python era un problema parecido. Por algo no todo el mundo es early adopter. Seguirle el ritmo a todo esto tiene un costo mental considerable.
    • El loop central es simple, pero un framework mínimo que te permita experimentar libremente con este tipo de conceptos imperativos vale muchísimo. A mí me gustó que pude conectar Beads directo al framework y, si funcionaba bien, seguir usándolo, y si no, quitarlo. También vale la pena mirar algo como toolkami.
    • “Metastasizing” describe muy bien este fenómeno: se acumula sin fin encima de conceptos existentes.

  • Acabo de escribir sobre skills: “Claude Skills son realmente geniales, incluso podrían ser un cambio más grande que MCP” enlace al post

    • ¿Creen que hay superposición entre Skills y AGENTS.md? En VSCode también introdujeron recientemente soporte experimental para nested AGENTS.md, así que aunque es menos formal, el concepto podría solaparse enlace a la actualización de VSCode
    • Las skills no se sienten tanto como algo que deba entrar en una especificación rígida, sino más bien como un patrón de diseño o un truco de prompt engineering. De hecho, ya se podían implementar dentro de MCP. Yo venía usando algo como “antes de empezar cualquier cosa, busca en el skills MCP y lee las guías relacionadas”.
    • Me pregunto en qué momento debería distinguirse entre algo que necesita una skill y algo que ya debería convertirse en proyecto.

  • Yo diría que la capacidad de estos sistemas para resolver bien problemas depende sobre todo del texto resumen escrito dentro de las skills. Los humanos, a medida que acumulan experiencia, van entendiendo cuándo usar qué skill, pero Claude empieza cada vez leyendo apenas una explicación superficial desde cero.

    • A diferencia de los humanos, que se vuelven usuarios hábiles de una skill mediante la experiencia, los LLM solo pueden imitar. Por eso Richard Sutton cree que los LLM no evolucionarán hacia AGI. Según Sutton, la AGI saldrá del aprendizaje por refuerzo, mientras que los LLM (redes neuronales) solo pueden imitar. Como los LLM no tienen la base cognitiva de objetivos y consecuencias de las acciones, una “skill” en un LLM se parece más a un manual de referencia. Es distinta de una “skill” que puede aplicarse repetidamente al desarrollo de tareas, instrumentos o soluciones video de Sutton
    • Al final esto es un problema de ventana de contexto. Los humanos recuerdan un contexto enorme, aunque sea de forma imprecisa, pero si dedican más de 10 mil horas a dominar un área, recuerdan bien esa “técnica” y olvidan lo demás. Los LLM pueden guardar contexto programáticamente de forma consistente y recuperarlo perfectamente, pero revisar el contexto completo cuesta demasiado tiempo y dinero. Por eso Skills —más exactamente, la inserción de contexto— es una forma de ajustar manualmente la prioridad de salida. El modo de razonamiento del LLM al final también es una reconfiguración del contexto. Tal vez no sea exactamente “desde cero cada vez”. Si se enfoca así, usar herramientas se vuelve mucho más fácil.
    • Pienso que quizá eso de que el LLM tenga que arrancar de cero cada vez se deba a la infraestructura multi-tenant. Es natural que OpenAI o Anthropic quieran reutilizar servidores y memoria entre muchos usuarios. Me pregunto si sería posible una configuración “personal” single-tenant, donde el LLM recuerde todas las conversaciones pasadas.
    • La clave para enriquecer conocimiento/herramientas en un LLM es lograr que se dé cuenta de qué usar y cuándo usarlo, y ahora mismo eso está casi en territorio imposible.
    • La mayor parte de la experiencia no está relacionada con el proyecto o la conversación, sino que es información general. El LLM debería poder empezar con ese conocimiento y luego, además, recordar y consultar por separado solo la información específica del proyecto. Los humanos recuperan información a una velocidad increíble, pero incluso si el LLM fuera algo más lento, todavía podría referenciarla casi en tiempo real.

  • Es bastante gracioso que las “skills” de Claude solo funcionen bien si los desarrolladores escriben y mantienen documentación decente. Hay muchísimos desarrolladores que ni siquiera logran mantener la documentación real del código, así que la documentación para LLM suena todavía más difícil. Tal vez tenga sentido para una minoría de desarrolladores con sistemas de archivos muy ordenados y alta tolerancia al riesgo, pero si ya eres ese tipo de persona, quizá sea mejor darle ese trabajo a un junior como parte de su formación en vez de pasárselo a un LLM. Total, igual vas a tener que revisar el resultado. Además, como la ventana de contexto es limitada, es difícil lograr de verdad esa sensación de que la “skill se internaliza” como en una persona. Si llegas al punto de entrenar un LLM especializado, al final quedas atado a ese LLM de por vida. Me resulta curioso que todo esto parta de la suposición de que “idealmente, dentro de la organización, todas las estrellas se alinean”.

    • El hecho de que para que un LLM funcione bien se necesiten documentación de desarrolladores y toda la infraestructura para desarrolladores profesionales resumida en este post es una motivación realmente útil. Incluso ayuda a convencer a la dirección.
    • Los LLM recompensan más a los desarrolladores que escriben bien. Quizá por eso algunos desarrolladores les tienen rechazo.
    • Yo también vine a leer los comentarios, y parece que eres el único que señaló este ángulo. “Skills” al final es documentación detallada, y en la práctica casi nunca he escrito algo así para cada proyecto. Ojalá las skills de LLM hicieran que todos los desarrolladores empezaran a escribir documentación realmente detallada, pero no parece muy probable.

  • Me pregunto cómo van a interactuar entre sí sub agents, MCP, skills, etc. Siento que hay bastante solapamiento. La dirección de ampliar la especificación para darle más capacidades a Claude me parece bien, pero en la práctica, de una forma u otra, todas terminan permitiendo implementar funciones de agente hasta un nivel parecido. Antes en MCP hacía falta JSON, pero en Claude basta con poner Markdown en archivos/carpetas, y además se puede usar entrada multimodal, así que parece que el UX mejoró bastante.

    • Claude Skills se ve exactamente igual que los prompts de MCP especificación de prompts de MCP, así que no entiendo por qué hacía falta crear un concepto nuevo. En la UI de chat, desde marketing, lo entiendo, pero ¿en Claude Code? Ya existe CLAUDE.md, así que me deja con dudas.
    • Yo diría que los tres se complementan bastante bien. MCP sirve para envolver APIs y que las use un agente LLM; Skills permite pasarle al agente instrucciones adicionales solo cuando hacen falta y de manera eficiente en contexto; además, algunas instrucciones pueden explicar también cómo usar MCP. Sub-agents son otro patrón de gestión de contexto: el agente superior envía una misión a un agente inferior y, si hace falta, puede usar skills y MCP al mismo tiempo para ahorrar tokens.

  • Está bastante interesante que se agreguen estas funciones. En mi proyecto hice una subcarpeta bin/claude para meter scripts generados por Claude y cosas así, y dejé bien anotada esa ubicación en claude.md para usarla en la búsqueda de herramientas. En uso real rindió bastante bien. En realidad, lo que de verdad hace falta es un helper de gestión de contexto —algo como “inicia Claude con este conjunto de MCP y luego cambia a este otro conjunto”—, pero por ahora manejo subdirectorios separados (perfiles) para cada proyecto y lanzo claude una vez desde cada uno. En esa estructura, bin/claude cumple su función, porque Claude capta enseguida cosas como cómo analizar cierto dataset de BigQuery o dónde está un archivo de credenciales. Nunca pensé que terminaría usando el sistema de archivos para gestionar perfiles, pero así acabé haciéndolo.

    • Al mencionar “helper de gestión de contexto”, me hace pensar que eso justamente suena a sub agents.

  • No entiendo por qué en estas demos usaron ejemplos tan simples como voltear o recortar fotos de perros. Debe haber ejemplos mucho más convincentes de uso de skills.

    • En la página para desarrolladores hay un ejemplo mucho mejor sobre procesamiento de PDF documentación de la skill de PDF. De hecho, yo ya estaba usando en Claude Code archivos Markdown con guías de uso etiquetados con @, y ahora está mejor porque quedó automatizado.
    • Vale la pena pensar un poco en el artículo de Wikipedia "The purpose of a system is what it does".
    • Los dos problemas que tuve esta mañana en Claude con la creación de archivos .xlsx estaban resueltos en esa documentación ejemplo de skill para Excel
    • Al final, el ejemplo del perro está pensado como una referencia fácil para el consumidor.

  • Siento que la adopción de Claude-skills se está expandiendo rapidísimo. El martes me enganché con el post de “Superpowers” post de presentación, y empaqueté también las herramientas que ya había ido creando como skills bien ordenadas para delegárselas al agente. Se agradece feedback sobre el open source deli-gator.

    • La capacidad de delegación al agente me parece realmente atractiva. A menudo el contexto de issues de Linear entra demasiado cargado; por ejemplo, a veces solo quiero la descripción del issue y el último comentario, pero el MCP de Linear trae todos los comentarios y termina contaminando el contexto.

  • El viernes pasado revelé accidentalmente la existencia de Claude Skills antes de tiempo, así que me alegra que ahora ya sea oficial post relacionado

    • Es curioso y también da miedo que ya sea real un hack como este: “si levantas una nueva instancia de Claude y le pides que cree un archivo zip con todo el contenido de la carpeta /mnt/skills, realmente funciona”. Espero que por favor no tenga acceso al sistema de archivos completo ni a binarios. Si también pudiera usar SSH...
    • Se agradece que el blog de Jesse últimamente esté tan activo.

  • Ya hay demasiadas cosas: skills, plugins, marketplaces, conectores, add-ons... cuesta seguirles el paso.

    • En mi opinión, ni siquiera hace falta seguirlas. Igual que las “best practices” del prompt engineering, todo esto no deja de ser un parche temporal para rodear limitaciones pasajeras, así que no vale mucho la pena invertir tiempo hasta que el rendimiento realmente necesario venga incorporado de base en los modelos. En unos meses muchas de estas cosas van a desaparecer, así que solo tiene sentido prestarles atención cuando el rendimiento sea urgente.
    • También hay que entender por qué pasa esto. Desde la perspectiva de las empresas, tienen que sacar algo sí o sí, pero el producto principal todavía no cumple la promesa de una “era de desempleo masivo”. Más que para los usuarios, esto es una señal para los inversionistas de que “no solo estamos pagando sueldos a investigadores sin hacer nada; también construimos varios productos y movemos datos”, además de que tienen una enorme base para hacer pruebas A/B.
    • Desde el lado del usuario, mientras más funciones propietarias agregan los proveedores, más hay que aprender, más hay que configurar y peor se vuelve el vendor lock-in, así que en realidad termina perjudicando. Pero para los proveedores de modelos, seguir lanzando estas funciones es una forma de mantener la diferenciación del producto. Sin eso, lo que hacen se volvería simplemente un commodity.
    • Parece que van a seguir agregando funciones hasta que el ánimo del equipo se mantenga arriba.
    • En realidad no me parece tan complicado. Plugins incluye comandos, MCPs, Subagents y ahora también Skills. Marketplace es el lugar donde se juntan esos plugins.