Skills de agente (Agent Skills)

 (agentskills.io)
35 puntos por GN⁺ 2026-02-04 | 6 comentarios | Compartir por WhatsApp
  • Los skills de agente son un formato abierto para agregar nuevas capacidades y conocimiento especializado a los agentes de inteligencia artificial
  • Desarrollado por Anthropic y luego publicado como un estándar abierto, hoy está siendo adoptado por diversos productos de agentes
  • Los skills tienen la forma de una carpeta compuesta por instrucciones, scripts y recursos, que el agente puede explorar para realizar tareas con mayor precisión y eficiencia
  • Admiten especialización por dominio, ampliación con nuevas funciones, flujos de trabajo repetibles e interoperabilidad
  • Las empresas y los desarrolladores pueden usarlos para lograr la reutilización del conocimiento organizacional y la automatización del despliegue

Resumen general

  • Agent Skills es un formato simple y abierto para dar a los agentes nuevas capacidades y especialización
  • Cada skill está compuesto por una carpeta con instrucciones, scripts y recursos, que el agente carga para mejorar la precisión y eficiencia de sus tareas

Por qué Agent Skills

  • Los agentes son cada vez más poderosos, pero sigue existiendo el problema de la falta de información contextual para ejecutar trabajo real de forma confiable
  • Los skills permiten cargar cuando se necesite el conocimiento procedimental y el contexto específico de la organización, el equipo o el usuario
  • Un agente con skills puede ampliar sus capacidades según la tarea
  • Los autores de skills pueden desplegar una función creada una vez en múltiples productos de agentes
  • Los agentes compatibles permiten a los usuarios agregar nuevas funciones de inmediato
  • Los equipos y las empresas pueden preservar el conocimiento organizacional como paquetes portátiles con control de versiones

Qué se puede hacer con Agent Skills

  • Especialización por dominio: empaquetar conocimiento especializado, como revisión legal o análisis de datos, en instrucciones reutilizables
  • Nuevas funciones: agregar distintas capacidades, como creación de presentaciones, construcción de servidores MCP o análisis de datasets
  • Flujos de trabajo repetibles: convertir tareas de múltiples pasos en procesos consistentes y auditables
  • Interoperabilidad: reutilizar el mismo skill en múltiples productos de agentes compatibles

Estado de adopción

  • Agent Skills es compatible con varias herramientas de desarrollo de IA
  • Algunos ejemplos incluyen Factory.ai, Gemini CLI, Mux, Ampcode, Letta, Autohand.ai, Spring AI, Goose, Piebald.ai, OpenAI Codex, Cursor, Databricks, Mistral Vibe, Roocode, VS Code, Agentman.ai, Trae.ai, Commandcode.ai, Firebender, Opencode.ai y Claude.ai

Desarrollo abierto

  • El formato Agent Skills fue desarrollado inicialmente por Anthropic y publicado como un estándar abierto
  • Desde entonces, diversos productos de agentes lo han adoptado, permitiendo contribuciones de todo el ecosistema
  • El formato y los skills de ejemplo pueden consultarse en el repositorio de GitHub

Cómo empezar

Lecturas relacionadas

6 comentarios

 
cgl00 2026-02-04

Si hay un repositorio oficial de Anthropic, ¿por qué hacen este tipo de proyecto desde un tercero?
 
skageektp 2026-02-04

> Agent Skills es un formato abierto mantenido por Anthropic y abierto a contribuciones de la comunidad.

Parece que Anthropic fue quien creó el estándar.
 
cgl00 2026-02-04

Aquí también es oficial... https://github.com/anthropics/skills Supongo que es distinto a esto, ¿no?
 
skageektp 2026-02-04

Sí, lo que enviaste es la implementación
Lo que se compartió en el cuerpo del texto es la especificación

Como
el estándar de algo como Docker = OCI
Docker, podman = runtimes de contenedores que implementan OCI

(puede que esté equivocado)
 
cgl00 2026-02-04

Ah, entonces era la especificación y la implementación... gracias
 
GN⁺ 2026-02-04
Opiniones en Hacker News

  • Esta discusión parte de una duda sobre la necesidad de la estandarización
    Yo sigo pensando que la clave de una buena documentación es “escribirla para que sea fácil de leer por personas”. No estoy seguro de que haya que imponer un formato nuevo. Si de verdad mejora la productividad, debería poder demostrarse con estudios comparativos

    • Además de lo que ya dijeron otros, la estandarización también abre oportunidades para usarla en entrenamiento y RL
    • De hecho, sí hubo un experimento comparativo. Un empleado de Hugging Face dijo que al afinar el modelo Qwen3-0.6B con codex + skills, la puntuación de humaneval mejoró en +6. El enlace relacionado está aquí, y el proyecto está en huggingface/upskill
    • El sistema no usa documentación simple, sino que crea un índice de todas las skills y se lo pasa al LLM en cada conversación. Así, el LLM solo lee la skill cuando la necesita. Es un concepto parecido a la capacidad de descubrir funciones en una GUI. En lo personal, me parece más intuitiva una estructura centrada en README
    • Yo automatizo trabajo con Claude Code y conecto cada tarea mediante comandos con slash. Al final, las skills también se sienten como otra forma de documentación. A largo plazo, creo que el paradigma de skills desaparecerá con la expansión de la ventana de contexto y la mejora de la inteligencia de los modelos
    • Pero si vemos los modelos actuales, Claude se detiene con solo leer la descripción de la skill, así que el ahorro de tokens es grande. En repositorios grandes, esa diferencia sí se nota. Vale la pena difundir este patrón

  • Nuestro equipo ha tenido éxito tratando las skills como funciones semideterminísticas reutilizables
    Por ejemplo, la skill /create-new-endpoint incluye todo el boilerplate, como actualizar OpenAPI y agregar pruebas de integración. Si en la CLI ingresas el número de ticket de JIRA, el LLM completa el trabajo con calidad consistente

    • Alguien preguntó “¿cómo prueban la consistencia con el paso del tiempo?”

  • Hubo una propuesta para estandarizar la estructura de carpetas

    .claude/skills
.codex/skills
.opencode/skills
.github/skills
    • No es un estándar, pero la mayoría de las herramientas CLI ejecutan escaneando archivos .md. Aun así, estaría bien una estandarización integrada que incluya plugins
    • Según comentan, Codex fue el primero y OpenCode lo siguió inmediatamente. Tuit relacionado
    • Esta discusión también sigue en agentskills/agentskills#15
    • Alguien dijo que “todavía es demasiado temprano, y estandarizar podría limitar la creatividad”
    • Otra persona sostuvo que sería mejor usar rutas como ~/.config/claude siguiendo la especificación base de XDG. Dicen que el esquema actual de ~/.claude es incómodo

  • Hubo una recomendación de crear un README.md en cada subcarpeta para enlazar las skills relacionadas. También es útil para humanos. Texto relacionado: Claude Skills Considered Harmful

    • Surgió la opinión de que “las skills al final no son más que README sobre temas específicos”. Si hay contenido que tienes que explicar repetidamente, puedes organizarlo como una skill. Ni siquiera hace falta seguir una carpeta estándar; puedes agregarlo al contexto directamente cuando lo necesites
    • Otra persona dijo que usar un ejecutor de comandos como just ayuda tanto a humanos como a agentes

  • A mí me resultó efectivo tratar las skills como workflows explícitos
    Si se definen como un procedimiento completo, tipo “haz X, luego Y y valida Z”, el agente lo reconoce como un modo de operación. En cambio, las guías ambiguas tienden a ser ignoradas

    • Alguien dijo que aplicó a Claude un sistema de hooks que activa una skill automáticamente en ciertas situaciones. Por ejemplo, cuando se trabaja con archivos Python, carga sola la skill relacionada
    • Otra persona señaló que la diferencia entre skill y command es difusa. Si al final ambos se usan como comandos, surge la duda de si realmente hace falta distinguirlos
    • Alguien comentó que esta estructura se parece a notas de Obsidian o a colecciones de comandos CLI
    • Otra persona enfatizó que hay que describir con mucha claridad las condiciones de activación de una skill. En Claude Code se puede invocar explícitamente como /foo, y por eso prefieren ese método

  • Algunas personas creen que las skills permiten documentar conocimiento de dominio implícito. Se pueden registrar reglas que antes solo estaban en la cabeza de los desarrolladores y reutilizarlas para entrenamiento de LLM

  • Surgió la pregunta de si “el agente no usa skills a menos que se le pidan”

    • Varias personas están viendo el mismo problema. Los modelos actuales no han sido entrenados con RLVR alrededor de skills, así que se confunden. Esperan que la próxima generación de modelos, por ejemplo Opus, use skills con mucha más estabilidad
    • En evaluaciones de Vercel, también dijeron que en el 56% de los casos no se invocó ninguna skill. En cambio, reportaron que el enfoque de AGENTS.md fue más efectivo en un rango más amplio. Blog relacionado
    • Una persona que usa Codex dijo que funciona bastante bien si en AGENTS.md se especifica el directorio de skills. Eso sí, mientras más skills haya, mayor es la posibilidad de conflictos, así que conviene mantenerlo simple
    • Otra persona dijo que casi no pudo usar skills, y que le resultó más preciso poner el contenido de la skill directamente dentro de AGENTS.md

  • Según comentaron, la tercera skill más popular en skills.sh era simplemente un enlace de descarga de comandos. Archivos como SKILLS.md/AGENTS.md/COMMANDS.md al final no son más que colecciones de prompts, y si se usan mal pueden ser peligrosos

    • Pero alguien respondió que, al final, con las herramientas lo importante es el uso responsable

  • Una persona que está desarrollando un nuevo lenguaje de programación dijo que usa AGENTS.md y SKILLS para que el LLM entienda un lenguaje con el que no fue entrenado. Gracias a la estandarización, dijo, la integración con herramientas se volvió más fácil

  • El verdadero valor no está en el formato, sino en la divulgación progresiva (progressive disclosure)
    Si metes todas las instrucciones en un solo documento, desperdicias tokens innecesariamente. El patrón de skills permite cargar los detalles solo cuando hacen falta. La estandarización sirve sobre todo para distribución y reutilización

    • Sobre esto, el desarrollador del proyecto MOOLLM explicó que lo extendió con el concepto de Semantic Image Pyramid.
      Aplica un refinamiento progresivo en el orden GLANCE.yml → CARD.yml → SKILL.md → README.md.
      GLANCE, con 5 a 70 líneas, solo decide “¿es relevante?”, CARD define la interfaz, SKILL contiene el procedimiento real y README da la explicación para humanos.
      Dice que INDEX.md tiene una tasa de compresión más de 80% mayor que INDEX.yml y además ofrece una estructura narrativa.
      Enlaces relacionados: INDEX.yml, INDEX.md
      También menciona la estructura de sniffable-python, pensada para que leyendo solo las primeras 50 líneas del código ya se pueda entender la API.
      Material relacionado: explicación de Semantic Image Pyramid, sister-script, sniffable-python README, sniffable-python SKILL