Blog

Cómo Crear Claude Skills: Guía Completa (2026)

27 July 2026  ·  Actualizado 27 July 2026

Gabriel Caetano

Gabriel Caetano

ARTIFICIAL INTELIGENCE

Cómo Crear Claude Skills: Guía Completa (2026)

Aprende a crear Claude Skills desde cero. Descubre SKILL.md, la integración con MCP, pruebas, implementación y mejores prácticas para crear flujos de IA reutilizables.

how-to-create-claude-skills

1. ¿Qué son las Claude Skills? (Y en qué se diferencian de los prompts)

Antes de construir nada, conviene entender exactamente qué es una Skill a nivel técnico, cómo se diferencia de un prompt, y dónde encaja dentro del ecosistema más amplio de Anthropic Claude. Esta sección sienta las bases conceptuales sobre las que descansa todo lo demás.

Definiendo las Claude Skills

Una Claude Skill es una unidad de instrucción autocontenida, con nombre y versionada, que Claude puede invocar cuando la necesita. En términos prácticos, es una carpeta. En su forma más simple, una skill es un directorio que contiene un archivo SKILL.md, y este archivo debe comenzar con un frontmatter en YAML que incluya cierta metadata obligatoria: name y description.

Esa carpeta es todo lo que hay. No hay un modelo separado, ni un binario propietario, ni un complemento de pago. Las Skills no son modelos, ni plugins en el sentido de WordPress, ni add-ons pagados. Son instrucciones en markdown de código abierto más archivos de soporte. Vale la pena tener esto claro desde el principio, porque cambia la forma en que piensas el trabajo. No estás programando un sistema. Estás escribiendo documentación tan clara y tan bien delimitada que Claude puede seguirla perfectamente, todas las veces.

Las Skills aparecen principalmente en dos lugares. En la API de Claude, puedes usar las skills prediseñadas de Anthropic, y subir skills personalizadas, a través de la API de Claude, y las skills son fáciles de crear: solo una carpeta con un archivo SKILL.md que contiene frontmatter en YAML e instrucciones. En Claude Code, viven en un directorio dentro de tu proyecto o plugin. Creas un directorio de skills en tu plugin o en la raíz de tu proyecto y agregas carpetas de skills que contienen archivos SKILL.md, y Claude las descubre y las usa automáticamente cuando el plugin está instalado.

También hay un registro público de ejemplos. Anthropic mantiene un repositorio abierto de Skills que muestran el rango de lo que es posible. Este repositorio contiene skills que demuestran lo que se puede hacer con el sistema de skills de Claude, desde aplicaciones creativas como arte, música y diseño, hasta tareas técnicas como pruebas de aplicaciones web y generación de servidores MCP, e incluso flujos de trabajo empresariales. Son una referencia muy útil cuando empieces a crear las tuyas.

El mejor modelo mental es este: si los prompts son notas adhesivas que garabateas y luego tiras a la basura, las Skills son Procedimientos Operativos Estándar (SOP) documentados. Una nota adhesiva le recuerda algo a una persona, una sola vez. Un SOP estandariza cómo todos hacen una tarea, para siempre, con un responsable claro y un número de versión.

Hay algunos términos que conviene tener claros desde ahora, porque aparecen a lo largo de toda esta guía:

  • SKILL.md: el archivo obligatorio que está en el corazón de cada Skill. Nota que en la implementación de Anthropic el nombre del archivo va en mayúsculas, aunque muchas veces la gente se refiere a él simplemente como "el archivo skill.md".
  • Frontmatter: el bloque YAML al inicio del archivo que contiene metadatos como name y description.
  • Cuerpo de la Skill: las instrucciones en Markdown debajo del frontmatter.
  • Constructor de Skills (Skill builder): el flujo de trabajo para crearlas, ya sea usando una plantilla, la API, o un directorio en Claude Code.
  • Invocación: el momento en que Claude decide que una Skill es relevante y la carga.
  • Alcance de la Skill: qué tan específico o amplio es el propósito de la Skill.
¿Corres Claude en varios repos toda la semana para probar tu librería de Skills? Eso normalmente es un plan Max 20x de $200 USD al mes, facturado en dólares. Con Bleap pagas al tipo de cambio real, 0% de comisión por conversión, y ganas un cashback fijo del 20% en tus renovaciones de Claude, ChatGPT y Gemini, sin necesidad de suscripción de tarjeta. Obtén la tarjeta Bleap →

Prompts de Claude vs Skills: las diferencias clave

Es común que la gente pregunte por qué no simplemente seguir usando un buen prompt. A veces esa es la mejor opción. Pero en cuanto una tarea se repite, se comparte con otros o se vuelve crítica para el negocio, una Skill gana en casi todos los aspectos. Aquí te explicamos por qué.

Persistencia. Un prompt solo existe dentro del turno de conversación donde se pega. Una vez que termina la sesión, desaparece. Una Skill persiste a través de sesiones y usuarios distintos. Se almacena, se indexa y está disponible siempre que sea relevante.

Capacidad de descubrimiento. Este es el punto más sutil. Claude no puede ver un prompt hasta que alguien lo inyecta. Una Skill, en cambio, se anuncia a sí misma. Al arrancar, el agente precarga el nombre y la descripción de cada skill instalada en su prompt de sistema, dando justo la información suficiente para que Claude sepa cuándo usar cada una sin tener que cargar todo su contenido en el contexto. Claude decide activamente cuándo recurrir a una Skill. Nunca puede decidir recurrir a un prompt que jamás ha visto.

Reutilización. Cualquier usuario o subagente autorizado puede llamar a una Skill sin que nadie tenga que copiar y pegar texto. Un prompt tiene que compartirse y volver a compartirse manualmente, y cada vez se distorsiona un poco más.

Control de versiones. Las Skills se pueden iterar y dar seguimiento a lo largo del tiempo. Los prompts sueltos dentro de mensajes de usuario no se pueden versionar de forma significativa.

Integración con herramientas. Las Skills pueden incluir scripts y material de referencia, además de describir exactamente cómo y cuándo usarlos. Los prompts no pueden llevar esa estructura de forma nativa.

Composabilidad. Las Skills pueden hacer referencia a otros recursos y conectarse con subagentes para trabajo delegado. Los prompts son bloques de texto monolíticos.

Aquí tienes una comparación lado a lado en ocho dimensiones:

Dimensión

Prompt sin formato

Claude Skill

Persistencia

Solo dura un turno de conversación

Persiste entre sesiones y usuarios

Reutilización

Copiar y pegar cada vez

Se invoca automáticamente, sin copiar nada

Versionado

Ninguno

Versionado semántico, con seguimiento a lo largo del tiempo

Descubrimiento

Invisible hasta que se inyecta

Se anuncia mediante nombre y descripción

Acceso a herramientas

No puede incluir herramientas

Puede incluir scripts y recursos

Compartir

Manual, se desactualiza constantemente

Una única fuente de verdad

Pruebas

Improvisadas

Biblioteca de casos de prueba estructurada

Seguridad / acceso

Sin control de acceso

Niveles de acceso delimitados

Cuándo usar un prompt y cuándo construir una Skill. El criterio para decidir es sencillo. Usa un prompt para solicitudes puntuales, exploratorias o muy específicas al contexto. Construye una Skill cuando una tarea se repite regularmente, necesita producir un resultado consistente, la va a usar más de una persona, o encapsula conocimiento que de otro modo tendrías que volver a explicar en cada sesión. Si te encuentras pegando las mismas instrucciones dos veces, esa es tu señal.

Dónde encajan las Skills en el ecosistema de Anthropic Claude

Las Skills no existen de forma aislada. Entender cómo se relacionan con el resto del ecosistema de Claude te evita construir una Skill para algo que otro mecanismo maneja mejor.

Skills vs Proyectos. En Claude.ai, los Proyectos agrupan conversaciones y archivos en torno a un objetivo compartido. Las Skills mejoran los Proyectos al agregar conocimiento procedimental reutilizable, pero no son lo mismo. Un Proyecto es un espacio de trabajo. Una Skill es una capacidad que puedes invocar dentro de ese espacio de trabajo o en cualquier otro lugar.

Skills vs MCP. Esta distinción importa mucho. El Model Context Protocol es la capa de conectividad, la forma en que Claude accede a herramientas externas, fuentes de datos y servicios. Las Skills son la capa de instrucciones, que le dicen a Claude cómo y cuándo actuar. Muchas veces usas ambas cosas juntas: MCP conecta a Claude con tu base de datos, y una Skill le indica a Claude el procedimiento exacto para consultar y dar formato a esos datos. Uno de los ejemplos de Skills de Anthropic incluso trata sobre la generación de servidores MCP, lo que muestra qué tan entrelazados están ambos conceptos.

Skills vs subagentes. Las Skills se pueden integrar en subagentes personalizados para que un agente especializado se encargue de una tarea delegada de forma aislada. Puedes compartir skills con tu equipo subiéndolas a un repositorio, distribuirlas mediante plugins, desplegarlas en toda la organización, e integrar Skills en subagentes personalizados para delegar tareas de forma aislada y experta. La Skill aporta el conocimiento especializado; el subagente ofrece el contexto de ejecución aislado.

Skills vs la API. Las Skills no están limitadas a la interfaz de chat. Se puede acceder a ellas de forma programática, lo que las hace viables para automatización en producción, pipelines de CI y funciones integradas en productos.

Skills vs la jerarquía de contexto. Cuando Claude responde, pondera el system prompt, el contenido de la Skill que ha cargado, los mensajes del usuario y cualquier resultado de herramientas. Las Skills se ubican por encima del mensaje individual, pero por debajo de los límites inamovibles a nivel de sistema. Conocer esta jerarquía te ayuda a escribir Skills que guíen el comportamiento sin ir en contra de los valores predeterminados de Claude.

Por qué las Skills de Claude son un parteaguas para la automatización con IA

El valor estratégico de las Skills se va acumulando. Aquí es de donde sale la ventaja.

Eliminan el "prompt drift". Cuando un equipo depende de una Skill compartida, todos usan las mismas instrucciones autorizadas. Se acabó eso de "¿cuál versión del prompt estás usando?" La Skill se convierte en la única fuente de verdad.

Amplían el acceso. Una Skill bien construida permite que personas sin conocimientos técnicos se beneficien de automatizaciones sofisticadas. No necesitan saber cómo escribir un system prompt de 400 palabras. Solo describen lo que quieren, y Claude recurre a la Skill correcta.

Reducen el desperdicio de la ventana de contexto. Aquí está el genio técnico del diseño. Las Skills usan un sistema de carga de tres niveles para administrar el contexto de forma eficiente, y esta divulgación progresiva te permite instalar muchas skills diferentes para realizar tareas complejas sin saturar tu ventana de contexto. Las instrucciones estáticas se quedan fuera de la conversación hasta el momento en que se necesitan.

El efecto de biblioteca acumulativa. Cada Skill que construyes hace que la siguiente valga más, porque las Skills pueden referenciar recursos compartidos y combinarse en flujos de trabajo. Un equipo con 40 Skills bien definidas tiene un perfil de capacidades genuinamente distinto al de un equipo que solo copia y pega prompts. Un equipo que corre docenas de Skills reportó que el overhead total es de apenas unos 1,500 tokens para las 40 skills, y solo la relevante se expande cuando se necesita.

Casos de uso reales. Este patrón aparece por todos lados: automatización de revisión de código, playbooks de atención al cliente, normalización de datos, control de calidad de contenido, generación de documentos que cumplen con la identidad de marca, y síntesis de investigación. El poder de las Skills radica en su capacidad para codificar el conocimiento institucional, estandarizar resultados y manejar flujos de trabajo complejos de varios pasos que de otra forma requerirían explicaciones repetidas o invertir en construir un agente personalizado.

La tesis de productividad es sencilla. Cada minuto que un trabajador del conocimiento pasa re-explicándole el mismo contexto a una IA es tiempo perdido, y es tiempo que se acumula mal a nivel de equipo. Los flujos de trabajo estructurados y reutilizables eliminan ese desperdicio. El ahorro exacto depende de tus propios flujos de trabajo, así que toma con cierto escepticismo cualquier porcentaje específico que veas por ahí, pero la dirección es clara: menos repetición, más consistencia, más ventaja competitiva.

2. Cómo funcionan las Skills de Claude: arquitectura, ciclo de vida del contenido y tipos de Skills

Ahora que ya sabes qué son las Skills y por qué importan, vamos a abrir el capó. Entender la arquitectura y el ciclo de vida es lo que marca la diferencia entre quienes escriben Skills que se activan de forma confiable y quienes escriben Skills que terminan sin usarse porque Claude nunca detecta que son relevantes.

La arquitectura de las Skills de Claude, en resumen

A grandes rasgos, el flujo funciona así: un usuario o agente hace una solicitud, Claude revisa los metadatos de cada Skill instalada, decide si alguna es relevante, carga el contenido completo de esa Skill en el contexto si aplica, y luego genera una respuesta enriquecida con ese contenido. Puedes imaginarlo como Usuario o Agente → escaneo de metadatos de la Skill → decisión de relevancia → carga de contenido → respuesta enriquecida.

Toda Skill tiene tres capas conceptuales:

  • Definición. Qué es la Skill: su nombre, descripción, versión y metadatos. Esto es lo que Claude ve todo el tiempo.
  • Contenido. Lo que la Skill entrega al contexto: las instrucciones completas, ejemplos y cualquier recurso referenciado. Esto se carga solo cuando se necesita.
  • Ejecución. Cómo Claude usa realmente el contenido cargado para completar la tarea, incluyendo cualquier script o herramienta a la que apunte la Skill.

¿Dónde se almacenan las Skills? Depende de tu configuración. En Claude Code viven en un directorio skills/ dentro de tu proyecto o plugin. A través de la API, se suben a un almacenamiento gestionado por Anthropic. Los equipos suelen mantener las versiones oficiales en su propio repositorio de Git y distribuirlas desde ahí.

¿Cómo "sabe" Claude que existe una Skill? Gracias a la capa de metadatos que siempre está cargada. El frontmatter en YAML se carga siempre en el system prompt de Claude, con un costo de alrededor de 100 tokens por skill sin importar cuántas skills tengas instaladas, y esta capa de metadatos le da a Claude justo la información suficiente para decidir si la skill es relevante para la tarea actual sin necesidad de cargar el contenido completo. Ese costo de 100 tokens es el precio de entrada para que una Skill sea detectable, y por eso el diseño puede escalar a decenas de Skills.

Por último, hay dos formas en que se invoca una Skill. La invocación implícita ocurre cuando el propio Claude decide que una Skill es relevante según la descripción y la solicitud del usuario. La invocación explícita ocurre cuando un usuario o agente nombra la Skill directamente. Ambas son válidas; el equilibrio entre ellas es algo que tú defines al momento de escribir la descripción.

El ciclo de vida del contenido de una Skill

Una Skill pasa por un ciclo de vida predecible, desde la idea hasta producción y más allá. Entender cada etapa, y sus posibles fallos, te ahorra horas de depuración.

Etapa 1, Creación. Escribes el SKILL.md y cualquier archivo de soporte. Aquí es donde se gana o se pierde la mayor parte de la calidad. Error común: ponerte a escribir antes de tener claro el problema. Antes de escribir nada, deja bien claro qué problema resuelve tu skill, porque las skills sólidas atienden necesidades concretas con resultados medibles.

Etapa 2, Publicación. Subes la Skill al lugar donde Claude la va a leer: un directorio, la API o un pipeline de CI/CD. Error común: publicarla en el lugar equivocado o olvidar instalar el plugin, con lo que Claude nunca la descubre.

Etapa 3, Indexación. Claude carga los metadatos de la Skill en el system prompt al iniciar. Error común: esperar que una Skill recién agregada esté disponible a mitad de sesión sin reiniciar o recargar.

Etapa 4, Invocación. Claude compara una solicitud con la descripción del Skill y decide usarlo. Riesgo: si la descripción es demasiado limitada, Claude nunca activa el Skill.

Etapa 5, Inyección. El cuerpo completo del SKILL.md se carga en el contexto. El cuerpo real del archivo es el segundo nivel de detalle, y si Claude considera que el skill es relevante para la tarea actual, lo cargará leyendo todo su SKILL.md dentro del contexto. Riesgo: un cuerpo demasiado grande que consume contexto y entierra las instrucciones importantes.

Etapa 6, Ejecución. Claude procesa el contexto enriquecido y genera su respuesta, ejecutando cualquier script al que apunte el Skill. Riesgo: instrucciones que entran en conflicto con el comportamiento predeterminado de Claude, lo que genera resultados inconsistentes.

Etapa 7, Iteración. Aquí versionas, editas y vuelves a publicar. Riesgo: modificar un Skill sin actualizar su versión, de modo que nadie sabe realmente qué comportamiento está obteniendo.

El hábito más útil en todo esto es probar la activación y la ejecución como cosas separadas. Prueba la activación y la ejecución por separado: si los skills no se activan, amplía la descripción y agrega casos de uso; y si los resultados son inconsistentes, dale más especificidad a las instrucciones e incluye pasos de validación. Son dos problemas distintos con dos soluciones distintas, y tratarlos como uno solo es justo la razón por la que la gente termina dando vueltas en círculos.

Tipos de contenido en un Skill

No todos los Skills hacen el mismo trabajo. Reconocer qué tipo estás construyendo define cómo debes estructurar el SKILL.md.

Los Skills de solo instrucciones entregan un conjunto de reglas de comportamiento o un procedimiento paso a paso. Una checklist de revisión de código es el ejemplo clásico: sin datos externos, sin herramientas, solo un proceso confiable que Claude sigue cada vez.

Las Skills de enriquecimiento de contexto aportan conocimiento especializado, datos de referencia o terminología. Piensa en una Skill que lleva el glosario de tu empresa, la taxonomía de productos o el tono de marca, para que Claude hable el idioma correcto sin que tengas que volver a explicárselo.

Las Skills de activación de herramientas describen cómo y cuándo usar herramientas o scripts específicos. Suelen combinarse con conexiones MCP y le indican a Claude dónde encontrar los ayudantes ejecutables dentro del directorio scripts/.

Las Skills de plantillas entregan formatos de salida estructurados: un esquema JSON, una plantilla de reporte, un armazón de código. Aquí lo valioso es la consistencia en la forma, no solo en el contenido.

Las Skills híbridas combinan varios de estos tipos en una sola unidad. Las propias Skills de edición de documentos de Anthropic son un buen ejemplo. Una de las skills que le da a Claude sus capacidades de edición de documentos aborda el hecho de que Claude ya sabe mucho sobre cómo entender archivos PDF, pero tiene limitaciones para manipularlos directamente, como llenar un formulario, y esta skill de PDF le da a Claude estas nuevas capacidades. Ahí se combinan instrucciones, herramientas y plantillas.

Cómo elegir el tipo correcto. Pregúntate qué necesita realmente la tarea. ¿Solo un cambio de comportamiento? Solo instrucciones. ¿Falta conocimiento? Enriquecimiento de contexto. ¿Necesita hacer algo externo? Activación de herramientas. ¿Necesita un formato de salida específico? Plantilla. ¿Varias de estas a la vez? Híbrida, pero mantenla lo más enfocada posible.

Cómo el tipo afecta la estructura. Las Skills de solo instrucciones y las de plantillas suelen ser cortas y pueden vivir completamente en el cuerpo del SKILL.md. Las Skills de enriquecimiento de contexto e híbridas suelen necesitar archivos de apoyo, que es justo para lo que está diseñado el sistema de divulgación progresiva. Como regla general, mantén el cuerpo del SKILL.md enfocado en lo esencial y por debajo de 500 líneas; si te estás acercando a ese límite, divide el contenido en archivos separados.

Cómo decide Claude cuándo invocar una Skill

Esta es la parte en la que la gente más se equivoca, así que vale la pena tratarla con cuidado. La invocación depende principalmente del campo de descripción. Claude lee la descripción de cada Skill instalada y la compara semánticamente con la solicitud actual. Si defines bien la descripción, la Skill se activa de forma confiable. Si la defines mal, hasta la Skill más brillante se queda sin usarse.

Hay una particularidad de comportamiento conocida que conviene tener en cuenta al diseñar. Claude tiende a subactivar las skills, es decir, a no usarlas cuando serían útiles, y para combatir esto conviene hacer que las descripciones de las skills sean un poco más "insistentes". La recomendación de Anthropic es detallar las situaciones que deberían activar la Skill, incluso las implícitas. Por ejemplo, en lugar de una simple línea, podrías agregar "asegúrate de usar esta skill cada vez que el usuario mencione dashboards, visualización de datos, métricas internas, o quiera mostrar cualquier tipo de dato de la empresa, incluso si no pide explícitamente un dashboard."

La invocación explícita funciona mediante referencia directa: un usuario o agente nombra la Skill, o un comando con slash la activa. Este es el camino más confiable, pero depende de que quien la invoca sepa que la Skill existe.

Frases disparadoras y ejemplos. Incluir ejemplos de frases y casos de uso en tu descripción afina la coincidencia semántica. Estos le dan a Claude señales concretas de cuándo aplica la relevancia. El consejo de Anthropic cuando una Skill no se activa es directo: si las skills no se activan, amplía tu descripción y agrega casos de uso.

Confianza y sobreactivación. El fallo opuesto es tener una descripción tan amplia que la Skill se activa en casi todo, secuestrando conversaciones que no tienen nada que ver. La solución es acotar el alcance. Una descripción bien delimitada, con condiciones de activación específicas, se activa cuando debe y se mantiene en silencio cuando no debe.

Múltiples Skills y priorización. Cuando varias Skills podrían coincidir, Claude evalúa la relevancia. Los conflictos de prioridad son una categoría real de solución de problemas, y parte de un buen diseño de Skills consiste en asegurarse de que dos Skills no compitan por el mismo territorio con descripciones que se traslapan.

Contexto dinámico. Las variables en tiempo de ejecución, los archivos específicos abiertos, las herramientas conectadas, la forma en que está redactada la solicitud, todo esto influye en qué Skill se activa. Una Skill que hace referencia a una base de datos se activará con más facilidad cuando haya una conexión a una base de datos presente. Diseñar pensando en este contexto dinámico es lo que hace que una Skill parezca que "simplemente sabe" cuándo ayudar.

Crear y probar Skills todo el día significa consumir rápido tu plan de Claude. Claude Pro cuesta $20 USD al mes y Max va de $100 a $200 USD al mes, facturados en dólares. Si pagas con Bleap, obtienes 0% de comisión por tipo de cambio más un cashback fijo del 20% en Claude, ChatGPT y Gemini, sin necesidad de suscripción a la tarjeta. Consigue la tarjeta Bleap →

3. Cómo crear tu primer Skill de Claude: guía paso a paso

Ya fue suficiente teoría. Vamos a construir un Skill funcional de principio a fin. Usaremos un ejemplo real, un Skill de Checklist de Revisión de Código, y repasaremos cada paso, desde la configuración hasta la primera invocación exitosa.

Requisitos previos y configuración del entorno

Primero, confirma que tienes acceso. La creación de Skills está disponible a través de Claude Code, la API de Claude y Claude.ai, aunque la gestión a nivel organización todavía sigue madurando. Según las indicaciones actuales, en Claude.ai los skills son por ahora individuales para cada usuario, aunque pronto llegarán funciones de gestión y compartición a nivel organización. Mientras tanto, se recomienda crear un repositorio de documentos compartido con las especificaciones de los skills para ir preparándote para estas nuevas funciones y, de paso, ir estableciendo buenas prácticas de gobernanza desde ahora.

Para el acceso de pago, los planes de Claude relevantes son bastante sencillos. Los precios de Claude en 2026 abarcan siete niveles: Free ($0), Pro ($20/mes), Claude Max 5x ($100/mes), Max 20x ($200/mes), Team Standard ($25/usuario/mes), Team Premium ($125/usuario/mes) y Enterprise (personalizado). Si estás construyendo Skills como parte del flujo de trabajo de un equipo, los planes Team y Enterprise suman los controles de administrador que tarde o temprano vas a necesitar. Si estás automatizando de forma programática, la API se factura por separado, por token.

Conocimientos necesarios. Honestamente, no mucho. Markdown básico y tener bien claro qué tarea quieres automatizar. Con eso basta.

Herramientas recomendadas. VS Code con una extensión de vista previa de Markdown hace que escribir el SKILL.md sea mucho más cómodo. Git te da control de versiones desde el primer día. Mantén abierta una conversación de Claude dedicada exclusivamente a hacer pruebas, separada de tu trabajo real, para que el contexto no contamine tus pruebas.

Carpeta de desarrollo local. Configura una carpeta antes de publicar nada, para que tus Skills tengan un lugar ordenado y un historial de versiones.

Tres formas de crear un Skill. Puedes crearlo directamente en un directorio skills/ en Claude Code, subirlo mediante la API de Claude, o partir de la plantilla de Anthropic. Puedes crear skills que transformen a Claude de asistente de propósito general en experto especializado ya sea con la plantilla de creación de skills o de forma manual, y para facilitarlo se recomienda armar tu archivo SKILL.md con la plantilla y ajustarlo a partir de ahí.

Planea tu Skill antes de escribir una sola línea

Resiste las ganas de abrir tu editor de inmediato. Los mejores Skills se planean primero. La guía de Anthropic es clara al respecto: identifica dos o tres casos de uso concretos antes de tocar cualquier archivo, y pregúntate qué conocimiento del dominio o buenas prácticas deberían quedar integradas ahí para que el usuario no tenga que explicarlas cada vez.

Responde estas cinco preguntas antes de empezar a escribir:

  1. ¿Qué tarea específica habilita este Skill? Para nuestro ejemplo: "Revisar un diff de código contra el checklist de calidad de nuestro equipo y generar un reporte estructurado de hallazgos."
  2. ¿Cómo va a saber Claude o un usuario cuándo invocarlo? Cuando alguien comparte un diff, un pull request, o pide una revisión de código.
  3. ¿Qué información debe estar en el contexto para que el Skill funcione? Los criterios del checklist y el formato de salida. El código en sí lo aporta el usuario.
  4. ¿Qué herramientas necesita el Skill, si es que necesita alguna? Para un checklist puro, ninguna. Si corriera linters, necesitaría acceso a scripts.
  5. ¿Quién debería tener acceso? Empieza en modo privado y amplía al equipo una vez que esté probado.

Alcance acotado, no amplio. Un Skill que "ayuda con código" no sirve de mucho porque se activa con todo y no entrega nada concreto. Un Skill que "revisa pull requests de Python contra el checklist de nuestro equipo y entrega hallazgos agrupados por severidad" es preciso, se activa correctamente y entrega valor consistente. Entre más acotado, casi siempre mejor.

Escribe primero la descripción, como si fuera una especificación. Trata la descripción como un documento de especificaciones. Si no puedes describir en dos o tres oraciones exactamente qué hace la Skill y cuándo debe activarse, todavía no estás listo para escribir el cuerpo.

Identifica la Skill mínima viable. Empieza con la versión más pequeña que aporte valor, publícala y ve iterando. Anthropic plantea el objetivo de forma clara: al final del proceso podrás construir una skill funcional en una sola sesión, que es justo lo que promete la guía oficial para quien siga la estructura correctamente.

Paso 1: Configura el directorio de tu Skill

Crea una carpeta para la Skill. La estructura recomendada:

code-review-checklist/
├── SKILL.md ← obligatorio
├── references/ ← conocimiento de soporte opcional
├── scripts/ ← ayudantes ejecutables opcionales
└── assets/ ← archivos estáticos opcionales

Esto refleja la convención que usa el propio Anthropic. Dentro de la carpeta de la skill vive un archivo SKILL.md (obligatorio) y, de forma opcional, un directorio scripts/ para código ejecutable, un directorio references/ para documentación que Claude carga según la necesite, y un directorio assets/ para plantillas y archivos de soporte.

Convenciones de nomenclatura. Usa kebab-case para los nombres de las carpetas (code-review-checklist, no CodeReviewChecklist). Agrega un prefijo por categoría para que una biblioteca grande siga siendo fácil de navegar: qa-dev-ops-content-. Nuestro ejemplo podría quedar como dev-code-review-checklist.

Un directorio por Skill. Mantener cada Skill autocontenida no es solo cuestión de orden. Significa que puedes versionar, compartir y mover Skills de manera independiente, algo que rinde frutos enormes cuando ya tienes decenas de ellas. Cada skill está autocontenida en su propia carpeta con un archivo SKILL.md que incluye las instrucciones y los metadatos que Claude utiliza.

Control de versiones. Inicializa Git en la carpeta o en su carpeta superior, y usa etiquetas de Git para las versiones del Skill. Cuando actualices un Skill de la 1.2.0 a la 1.3.0, ponle su etiqueta correspondiente. Tu "yo" del futuro, tratando de descubrir por qué el comportamiento cambió el martes pasado, te lo va a agradecer.

Paso 2: Escribe el archivo SKILL.md (versión mínima viable)

Aquí tienes un SKILL.md completo y funcional para nuestra Skill de Lista de Verificación para Revisión de Código. Este es el archivo entero, desde el frontmatter hasta el cuerpo.

---
name: code-review-checklist
description: >
Reviews code diffs and pull requests against the team's quality
checklist and returns findings grouped by severity. Use this skill
whenever the user shares a diff, a pull request, a code snippet for
review, or asks for a code review, quality check, or PR feedback,
even if they do not explicitly say "checklist."
version: 1.0.0

# Code Review Checklist

You are performing a structured code review. Work through every
item in the checklist below against the code the user provides.

## Checklist

1. **Correctness**, Does the code do what it claims? Flag logic errors.
2. **Null and error handling**, Are edge cases and failures handled?
3. **Security**, Flag hardcoded secrets, unsafe input handling, or
injection risks.
4. **Tests**, Is there adequate test coverage for the change?
5. **Naming and style**, Do names follow our conventions
(kebab-case files, camelCase variables)?
6. **Readability**, Could a new teammate understand this in 60 seconds?

## Output format

Group findings under three headings: **Blocking**, **Should fix**, and
**Nice to have**. For each finding, cite the relevant line or function
and give a one-line, actionable recommendation. End with a one-sentence
overall verdict.

## Guidelines

- If the code is clean, say so plainly. Do not invent issues.
- Be specific. "Improve error handling" is useless;
"wrap the file read in a try/except" is useful.
- Do not rewrite the whole file unless asked. Point to the fix.

Esta estructura sigue muy de cerca la plantilla de Anthropic. La plantilla pública muestra el mismo esqueleto: un nombre y una descripción clara de qué hace la skill y cuándo usarla, un encabezado con las instrucciones que Claude seguirá cuando la skill esté activa, una sección de Ejemplos y una sección de Lineamientos.

Vamos a resaltar lo que realmente importa:

  • La description es la que hace todo el trabajo pesado. Fíjate que es deliberadamente "insistente", enumerando las situaciones que deben activarla y cubriendo explícitamente el caso en que el usuario no use la palabra "checklist". Eso combate el problema de que no se active cuando debería.
  • El cuerpo es un procedimiento claro, no una sugerencia vaga. Los elementos de la checklist son concretos y cada uno es accionable.
  • El formato de salida está fijo. Esto es justo lo que convierte "algo de retroalimentación" en un reporte consistente y comparable cada vez.
  • Las guías cierran los huecos, indicándole a Claude que no invente problemas ni que reescriba de más.

Errores comunes en un primer borrador. Descripciones demasiado escuetas. Instrucciones que chocan con el comportamiento predeterminado de Claude (por ejemplo, decirle que sea breve y luego pedirle explicaciones detalladas). Cuerpos que crecen más de la cuenta y pierden utilidad. Y formatos de salida que se dejan implícitos, lo que genera resultados inconsistentes.

La prueba de leerlo en voz alta. Lee tu SKILL.md en voz alta. Si una frase te suena enredada o ambigua a ti, también va a confundir a Claude. Escribir con claridad no es un detalle bonito aquí; es toda la tarea de ingeniería.

Paso 3: Publica la Skill

Cómo la publiques depende de tu entorno.

En Claude Code, coloca la carpeta en el directorio skills/ de tu proyecto y Claude la detecta automáticamente. Creas un directorio de skills en la raíz de tu plugin o proyecto y agregas carpetas de skills que contengan archivos SKILL.md, y Claude las descubre y las usa automáticamente cuando se instala el plugin.

A través de la API, sube la carpeta de la Skill usando la Skills API. La documentación de Anthropic incluye una Guía rápida de la Skills API justo para esto.

En Claude.ai, agrega la Skill a través de la interfaz de Skills en tu espacio de trabajo, pega o sube el SKILL.md, y define el nivel de acceso inicial. Recuerda que en Claude.ai, por ahora, las Skills están limitadas al usuario individual, aunque compartirlas de forma más amplia ya está en el roadmap.

Definir el nivel de acceso. Empieza en modo privado. Comprueba que la Skill funcione de forma aislada antes de exponerla a un equipo o espacio de trabajo. Es mucho más fácil ampliar el acceso después que tener que deshacer una Skill defectuosa de la que ya dependen varias personas.

Después de publicarla, hay un breve proceso de indexación en el que los metadatos se cargan en el system prompt. Si ya tienes una sesión en curso, puede que necesites recargarla o empezar una nueva para que una Skill recién agregada esté disponible.

Paso 4: Ejecuta tu primera prueba de invocación

Abre una conversación nueva. Esto es importante. Una conversación existente arrastra contexto que puede ocultar si tu Skill realmente se activó o si Claude solo está respondiendo en función de mensajes anteriores.

Primero, prueba la invocación implícita. Pega un diff de código y simplemente pregunta: "¿Puedes revisar esto?". No menciones la Skill por su nombre. Si tu descripción está bien hecha, Claude debería recurrir a la Skill automáticamente y devolver la respuesta en el formato que definiste.

Luego prueba la invocación explícita. Menciona la Skill directamente y confirma que se activa cuando se le pide.

Interpreta la respuesta. La señal más clara de que la Skill se cargó es que la salida coincide exactamente con el formato que definiste: hallazgos agrupados en Bloqueantes, Se debe corregir y Bueno tenerlo, junto con un veredicto de una sola oración. Si en cambio recibes retroalimentación en forma de texto genérico, es probable que la Skill no se haya activado.

Cinco señales de que tu Skill está funcionando:

  1. La salida sigue con precisión el formato que especificaste.
  2. Claude aplica los puntos específicos de tu checklist, no solo buenas prácticas genéricas.
  3. Respeta tus lineamientos (no inventa problemas en código limpio).
  4. Se activa con solicitudes naturales sin que tú lo menciones directamente.
  5. El comportamiento es consistente en pruebas repetidas con diferentes datos.

Si la activación no es confiable, recuerda la regla de separación de responsabilidades: corrige la activación ampliando y afinando la descripción; corrige la calidad de la salida agregando especificidad y pasos de validación en el cuerpo.

Errores comunes de principiantes y cómo corregirlos

Unos cuantos errores explican la mayoría de las frustraciones iniciales.

Instrucciones que van en contra de lo que Claude hace por defecto. Si tu Skill le dice a Claude que se comporte de una forma que contradice su comportamiento base sin una razón clara, vas a obtener resultados inconsistentes. Solución: explica claramente por qué se necesita esa desviación, y valídala.

Descripciones tan amplias que el Skill se activa con todo. Un Skill que se dispara con cada mensaje es peor que inútil. Solución: acota el alcance, agrega condiciones de activación específicas.

Nivel de acceso incorrecto antes de compartir. Publicar para todo el equipo antes de probar, o dejar expuesto un Skill que no funciona bien. Solución: primero privado, y amplía el acceso solo después de validarlo.

Cuerpos sobrecargados. Un SKILL.md inflado desperdicia contexto y sepulta las instrucciones clave. Solución: mantén el cuerpo en menos de 500 líneas y manda los detalles de apoyo a references/. Como dice la guía, mantén el cuerpo del SKILL.md en lo esencial y por debajo de 500 líneas, y si te estás acercando a ese límite, divide el contenido en archivos separados.

No probar casos límite. Un Skill que funciona en el camino ideal pero falla con entradas fuera de lo común va a erosionar la confianza rápidamente. Solución: arma una biblioteca de casos de prueba como se debe. Crea una biblioteca de casos de prueba que cubra el uso normal, los casos límite y las solicitudes fuera de alcance.

4. Cómo estructurar el archivo SKILL.md: metadatos, frontmatter y cuerpo

Ya construiste una Skill funcional. Ahora profundicemos en el archivo en sí, porque dominar la estructura de SKILL.md es lo que hace la diferencia entre Skills que "más o menos funcionan" y Skills que funcionan siempre, a escala, en todo un equipo.

Cómo entender el formato del archivo SKILL.md

¿Por qué Markdown? Porque es fácil de leer para los humanos, funciona bien con los diffs de Git, es compatible con casi todo y obliga a que las cosas queden claras. Además, Markdown es básicamente cómo Claude ya "piensa" el texto estructurado, así que las instrucciones en Markdown son instrucciones que Claude sigue de forma natural. Esta elección no es casualidad: las Skills están pensadas para que las personas las escriban y revisen tanto como para que Claude las ejecute.

La estructura de dos partes. Todo archivo SKILL.md consiste en un bloque de frontmatter en YAML seguido de un cuerpo en Markdown. Un archivo SKILL.md debe comenzar con un frontmatter en YAML que incluya un nombre de archivo y una descripción, la cual se carga en el system prompt desde el arranque. El frontmatter son los metadatos; el cuerpo son las instrucciones.

Cómo se tratan de manera distinta estas dos partes. Aquí está el corazón de la arquitectura de divulgación progresiva. El frontmatter siempre se carga. El cuerpo solo se carga cuando es relevante. El frontmatter en YAML siempre se carga en el system prompt de Claude, con un costo aproximado de 100 tokens por skill, dándole a Claude justo lo necesario para decidir si es relevante sin tener que cargar todo el contenido; el cuerpo del SKILL.md se carga cuando Claude determina que la skill es relevante, y ahí es donde están las instrucciones completas, los flujos de trabajo paso a paso, los ejemplos y las guías para resolver problemas.

Límites de tamaño de archivo. No hay un número universal fijo, pero la guía práctica es mantener el cuerpo por debajo de las 500 líneas. Si lo superas, deberías dividir el contenido en archivos dentro de references/ que Claude carga cuando los necesita. Anthropic diseñó un tercer nivel de divulgación justo para esto: cuando un Skill crece demasiado para caber en un solo SKILL.md, los archivos de soporte absorben el excedente. A medida que los skills se vuelven más complejos, pueden contener demasiado contexto para caber en un solo SKILL.md.

Codificación y formato. Usa codificación UTF-8 y saltos de línea estándar. Mantén tu Markdown limpio y bien estructurado, porque la estructura misma es una señal para Claude sobre cómo priorizar la información.

Lo que contiene el archivo vs. lo que recibe Claude. No son lo mismo. El archivo contiene todo: frontmatter, cuerpo y referencias a recursos. Lo que Claude recibe en un momento dado depende del nivel de divulgación. Al iniciar, recibe solo tus metadatos de ~100 tokens. Al invocarse, recibe el cuerpo. Solo lee los archivos referenciados si el cuerpo se lo indica. Diseñar teniendo en cuenta esta transformación es la diferencia entre un Skill eficiente y uno que desperdicia contexto sin que te des cuenta.

Frontmatter YAML: cada campo explicado

El frontmatter es pequeño pero decisivo. Dos campos son obligatorios (name y description); el resto son opcionales pero valiosos a gran escala. Aquí está la referencia completa.

name, el identificador canónico del Skill. Usa kebab-case, mantenlo descriptivo y hazlo único dentro de tu espacio de trabajo para que no haya ninguna ambigüedad sobre qué Skill es cuál. code-review-checklist es bueno; helper no lo es. El nombre es tanto una etiqueta legible para humanos como, en la invocación explícita, lo que la gente menciona.

version, versionado semántico en formato MAJOR.MINOR.PATCH. Sube el PATCH para correcciones menores y aclaraciones, el MINOR para nuevas funciones que sigan siendo compatibles con versiones anteriores, y el MAJOR para cambios que alteren el comportamiento existente de forma que puedan sorprender a los usuarios actuales. El versionado es lo que le permite a un equipo saber exactamente qué comportamiento está obteniendo, y es la columna vertebral de una iteración segura. Cuando vuelvas a publicar, etiqueta la versión en Git para que el historial del archivo y el número de versión se mantengan sincronizados.

description, el campo más importante de todos, sin duda. Es lo que impulsa el enrutamiento de invocación mediante coincidencia semántica, y siempre se carga, así que debe justificar sus ~100 tokens. Algunas recomendaciones que funcionan en la práctica:

  • Apunta a unas 100 a 200 palabras. Lo suficientemente extenso para ser específico, pero lo suficientemente breve para caber en el presupuesto de lo que siempre se carga.
  • Escribe pensando en similitud semántica, no en rellenar de palabras clave. Describe las situaciones que maneja el Skill, no una lista de palabras clave.
  • Sé "insistente" para combatir la subactivación. Enumera explícitamente los escenarios que deben activarlo, incluyendo los implícitos. Recuerda el ejemplo de Anthropic sobre detallar que un Skill de dashboards debería activarse cada vez que un usuario mencione visualización de datos o métricas internas, aunque no pida explícitamente un dashboard.
  • Una descripción sólida dice: "Revisa diffs de código y pull requests según la lista de verificación de calidad del equipo, y devuelve los hallazgos agrupados por gravedad. Se usa siempre que el usuario comparta un diff, PR o fragmento de código para revisión." Una débil dice: "Ayuda con código." La primera se activa correctamente; la segunda se activa con todo o con nada.

author, atribución individual o de equipo. Esto importa más de lo que parece. Establece responsabilidad (quién es dueño de este Skill y a quién preguntarle cuando algo falla) y respalda la gobernanza a medida que tu biblioteca crece.

tags, una estrategia de taxonomía para facilitar la búsqueda en bibliotecas grandes. Categorías recomendadas: dominio (securitydatacontent), función (reviewgenerationanalysis), audiencia (engineeringsupportmarketing) y madurez (experimentalstabledeprecated). Un etiquetado consistente es lo que mantiene navegable una biblioteca de 40 Skills, en lugar de que se vuelva un caos.

trigger_phrases, un arreglo opcional de frases de ejemplo que deberían activar la Skill. Estas afinan la puntuación de invocación al darle a Claude referencias concretas. El punto ideal está entre cinco y diez: suficientes para cubrir las formas principales de decirlo, pero no tantas que termines simplemente repitiendo la descripción. Ten en cuenta que el soporte de este campo varía según el entorno, así que revisa el esquema actual de tu configuración; donde no exista como campo formal, incorpora ejemplos equivalentes dentro del cuerpo de la descripción.

arguments, definiciones para las entradas dinámicas que quienes invocan la Skill le pasan. Cada argumento típicamente especifica un nombre, un tipo, si es obligatorio u opcional, y un valor por defecto. Los argumentos son lo que le da flexibilidad a una Skill: una Skill de generación de reportes podría recibir un argumento format (con valor por defecto markdown) o un severity_threshold. Mantén el conjunto de argumentos mínimo y bien documentado, porque cada argumento es algo más que quien la invoca tiene que entender, y una ruta más que tú tienes que probar.

Cómo escribir un cuerpo de SKILL.md efectivo

El cuerpo es donde vive la experiencia real, y la forma en que lo escribas determina directamente qué tan confiable es la ejecución de Claude.

Ajusta la guía a la libertad que permite la tarea. Anthropic usa aquí una analogía muy útil. Piensa en Claude explorando un camino: un puente angosto con precipicios necesita barreras específicas (poca libertad), mientras que un campo abierto permite muchas rutas (mucha libertad), así que ajusta la guía de tu Skill al terreno. Un Skill que verifica cumplimiento necesita pasos precisos y prescriptivos. Un Skill para hacer lluvia de ideas puede dejar mucho más espacio libre. No sobre-restrinjas las tareas creativas ni sub-restrinjas las de alto riesgo.

Estructura el cuerpo de forma predecible. Un patrón confiable es: una declaración de una línea sobre la tarea, un procedimiento paso a paso, un formato de salida fijo y una sección de lineamientos que cierre los vacíos. Los propios ejemplos de flujo de trabajo de Anthropic siguen esta estructura, terminando con un filtro de calidad: redactar siguiendo la estructura de encabezados y los lineamientos de tono, y luego correr la lista de verificación de calidad antes de entregar el borrador.

Incluye ejemplos y validación. Los ejemplos concretos le dan a Claude un punto de referencia claro, y los pasos de validación explícitos detectan errores antes de que lleguen al usuario. Cuando los resultados son inconsistentes, la solución casi siempre es más especificidad y más validación, no más extensión.

Mantenlo ligero. Cada línea que agregas se carga en el contexto al invocar el Skill. La recomendación de menos de 500 líneas no es arbitraria; protege tu presupuesto de contexto y evita que las instrucciones importantes se diluyan.

Uso de archivos de apoyo: referencias, scripts y recursos

Los directorios opcionales son la forma de mantener el SKILL.md ligero mientras le das a Claude acceso a más información cuando la necesita. Este es el tercer nivel de divulgación progresiva.

references/ contiene documentación que Claude carga bajo demanda: especificaciones detalladas, tablas de referencia largas, guías de estilo. El cuerpo principal apunta a estos archivos y Claude los lee solo cuando la tarea lo requiere. Así es como manejas un Skill con una base de conocimiento grande sin pagar el costo de contexto en cada invocación.

scripts/ contiene ayudantes ejecutables. Cuando un Skill necesita hacer algo determinista, como correr un linter, parsear un archivo o llamar a una API, un script es más confiable que pedirle a Claude que simule el trabajo. El cuerpo principal le dice a Claude cuándo y cómo ejecutar cada script.

assets/ contiene archivos estáticos: plantillas, esquemas, boilerplate, imágenes. Un Skill de generación de documentos guarda aquí su plantilla de reporte.

El principio general es elegante. Para activar skills, todo lo que necesitas hacer es escribir un archivo SKILL.md con instrucciones personalizadas para tu agente, y un skill es un directorio que contiene un archivo SKILL.md junto con carpetas organizadas de instrucciones, scripts y recursos que le dan a los agentes capacidades adicionales. Empieza solo con el SKILL.md y agrega directorios de apoyo únicamente cuando el cuerpo principal realmente supere lo que cabe en un solo archivo.

Control de acceso y empaquetado para equipos

Dos temas de producción completan el panorama: quién puede usar un Skill y cómo lo distribuyes.

Control de acceso. Define los niveles de acceso de forma deliberada. Privado para desarrollo y pruebas, de equipo o de workspace una vez que ya esté probado. Como Claude.ai actualmente limita los Skills a usuarios individuales, mientras tanto los equipos deberían mantener un repositorio compartido de especificaciones. Se recomienda crear un repositorio de documentos compartido con las especificaciones de los skills, lo que prepara a tu organización para las próximas funciones mientras establece buenas prácticas de gobernanza desde ahora.

Empaquetado y distribución. Una vez que una Skill esté sólida, distribúyela de forma adecuada en lugar de andar pasando archivos por ahí. El camino recomendado es Git más plugins más configuraciones empresariales. Puedes compartir Skills con tu equipo subiéndolas a un repositorio, distribuirlas más ampliamente a través de plugins, y desplegarlas en toda la organización usando configuraciones administradas empresariales. Para el gobierno a gran escala, los clientes Enterprise cuentan con soporte adicional. Los clientes Enterprise pueden trabajar con el equipo de éxito del cliente de Anthropic para explorar opciones de despliegue adicionales y marcos de gobernanza.

Probar antes de distribuir. Nunca distribuyas una Skill que no hayas probado contra una biblioteca realista de casos. Cubre el flujo normal, los casos límite y, muy importante, las solicitudes fuera de alcance que no deberían activar la Skill. Esta última categoría es la que te permite detectar activaciones excesivas antes de que lo haga tu equipo.

5. Patrones avanzados: integración con MCP, subagentes y aprobación de herramientas

Una vez que ya le agarraste la onda a las Skills individuales, el verdadero potencial aparece cuando las combinas con el resto de la plataforma de Claude. Esta sección cubre los patrones que convierten una biblioteca de Skills en una automatización de verdad.

Integración de MCP con Claude Skills

El Model Context Protocol conecta a Claude con sistemas externos: bases de datos, APIs, almacenes de archivos, herramientas internas. Las Skills y MCP se complementan, no compiten entre sí. MCP aporta la conexión; la Skill aporta el procedimiento para usar esa conexión de la mejor manera.

Un ejemplo concreto: MCP conecta a Claude con tu base de datos de analítica. Por sí solo, Claude puede hacer consultas, pero no conoce las convenciones de tus tablas, cómo defines tus métricas clave, ni el formato en que tu equipo espera los reportes. Una Skill le da todo eso. Le dice a Claude en qué tablas está cada dato, cómo se define "usuario activo" en tu organización y exactamente cómo debe verse el resultado final. Juntos, convierten una conexión sin pulir en un analista confiable.

La biblioteca de ejemplos de Anthropic incluso incluye la generación de servidores MCP como una de las Skills que demuestra, lo que deja claro qué tan bien encajan estas dos capas de forma natural. Cuando diseñes una Skill de activación de herramientas, asume que MCP es el medio de transporte y enfoca tu SKILL.md en la lógica de decisión: cuándo recurrir a la herramienta, qué parámetros mandar y cómo validar lo que regresa.

Subagentes de Claude y delegación de Skills

Los subagentes te permiten delegar una tarea acotada a un agente separado con su propio contexto aislado. Si combinas un subagente con una Skill, obtienes un trabajador experto para una tarea específica que no satura tu conversación principal.

El patrón es muy útil para flujos de trabajo de varios pasos. Imagina un proceso de release: un subagente, equipado con una Skill de revisión de código, revisa el diff; otro, con una Skill de changelog, redacta las notas de la versión; y un tercero, con una Skill de QA, genera un plan de pruebas. Cada uno corre de forma aislada, con solo el contexto que necesita. Anthropic describe exactamente esta capacidad. Puedes conectar Skills a subagentes personalizados para delegar tareas especializadas de forma aislada, y existe una guía completa de solución de problemas para diagnosticar fallas, desde skills que no se activan hasta conflictos de prioridad y errores en tiempo de ejecución.

El beneficio es doble: un contexto más limpio (la conversación principal no se contamina con las notas de trabajo del subagente) y una especialización más clara (cada subagente hace bien una sola cosa). El costo es la complejidad de coordinación, así que conviene usar subagentes cuando una tarea realmente se beneficia del aislamiento, no para todo.

Aprobación de herramientas y control de acceso en Claude

Cuando una Skill le da a Claude la capacidad de usar herramientas, sobre todo herramientas que ejecutan acciones reales como enviar correos, escribir en una base de datos o llamar a una API de pago, la aprobación de herramientas se vuelve un tema crítico de seguridad. El principio es el de mínimo privilegio: una Skill solo debería habilitar las herramientas específicas que realmente necesita, y las acciones con consecuencias reales deberían requerir confirmación.

Diseña tus Skills de activación de herramientas de modo que las operaciones de solo lectura fluyan sin problema, pero que las operaciones de escritura o destructivas se detengan a esperar aprobación. Documenta en el cuerpo del SKILL.md exactamente qué herramientas usa la Skill y bajo qué condiciones, para que tanto Claude como cualquier persona que revise el código entiendan el alcance del impacto. Aquí es también donde el campo author y un versionado claro demuestran su valor: cuando una Skill puede ejecutar acciones, necesitas tener total claridad sobre quién es responsable de ella y qué versión está activa.

Para las organizaciones, esto se relaciona con la configuración empresarial administrada, donde los administradores pueden controlar qué Skills y herramientas están disponibles y para quién. Trata la aprobación de herramientas como parte del diseño de la Skill desde el principio, no como algo que se agrega después. Una Skill que puede actuar es una Skill que puede causar daño si se activa de forma incorrecta, y esta es una razón más para acotar bien las descripciones y probar a fondo las solicitudes fuera de alcance.

Pruebas de Skills y control de calidad a gran escala

Probar una sola Skill es fácil. Mantener la calidad en una biblioteca que sigue creciendo requiere disciplina. Hay tres prácticas que marcan la diferencia.

Separa las pruebas de activación de las pruebas de ejecución. Como ya vimos antes, se trata de dos tipos de fallas distintos. Mantén casos de prueba para cada uno: un conjunto que verifique que la Skill se activa (y que no se activa cuando no debería), y otro que verifique la calidad del resultado una vez que se ejecuta. Prueba la activación y la ejecución por separado; si las skills no se activan, amplía tu descripción y agrega casos de uso, y si los resultados son inconsistentes, agrega más especificidad a las instrucciones e incluye pasos de validación.

Crea una biblioteca de casos de prueba como se debe. Para cada Skill, mantén casos documentados que cubran el uso normal, los casos límite y las solicitudes fuera de alcance. Ejecútalos cada vez que modifiques la Skill. Esto te ayuda a detectar retrocesos antes de que lleguen a los usuarios, y es el hábito más valioso que puedes tener cuando tu biblioteca empieza a madurar.

Cuidado con los conflictos de prioridad. A medida que tu biblioteca crece, dos Skills con descripciones que se traslapan van a empezar a competir entre sí. Parte del control de calidad a gran escala consiste en revisar las descripciones para detectar traslapes y ajustar el alcance para que cada Skill tenga su territorio bien definido. Las guías de solución de problemas que ofrece Anthropic mencionan específicamente los conflictos de prioridad como una categoría conocida, así que hay que anticiparlos y diseñar pensando en evitarlos.

¿Corres Claude en varios repos toda la semana para probar tu librería de Skills? Eso normalmente es un plan Max 20x de $200 USD al mes, facturado en dólares. Con Bleap pagas al tipo de cambio real, 0% de comisión por conversión, y ganas un cashback fijo del 20% en tus renovaciones de Claude, ChatGPT y Gemini, sin necesidad de suscripción de tarjeta. Obtén la tarjeta Bleap →

6. Buenas prácticas de producción y la forma inteligente de pagar por Claude

Ya tienes todo lo que necesitas para crear, estructurar y combinar Skills. Dos últimos elementos marcan la diferencia entre un hobby y una práctica de producción: la disciplina operativa y ver el costo de tu suscripción a Claude como algo que se puede optimizar.

Checklist de buenas prácticas de producción

  • Mantén el alcance acotado. Cada Skill debe hacer una sola cosa y hacerla bien. Un alcance acotado significa activación confiable y resultados consistentes.
  • Escribe descripciones contundentes. Combate la subactivación listando explícitamente los escenarios que deben activar el Skill, incluyendo los implícitos.
  • Mantén los cuerpos ligeros. Menos de 500 líneas, con el detalle empujado a references/. Protege tu presupuesto de contexto.
  • Versiona todo. Versionado semántico más etiquetas de Git para que todos sepan qué comportamiento está activo.
  • Prueba en tres categorías. Casos normales, casos límite y fuera de alcance, probando la activación y la ejecución por separado.
  • Controla el acceso de forma deliberada. Empieza en privado y amplía solo después de validar. Aplica el mínimo privilegio para las herramientas.
  • Mantén un repositorio de especificaciones. Sobre todo mientras madura el uso compartido a nivel organización, un repo de specs compartido mantiene al equipo alineado y te prepara para configuraciones administradas.
  • Documenta la propiedad. Usa el campo author para que cada Skill tenga un dueño claro.

Si sigues esto, construirás una biblioteca de Skills que suma valor con el tiempo en lugar de acumular deuda técnica.

El tema del costo: cómo pagar por Claude sin perder dinero

Aquí está la parte que la mayoría de las guías ignora. Crear Skills implica pagar por Claude, y las suscripciones de Claude se cobran en dólares. Claude Pro cuesta $20 dólares al mes (o $17 al mes si se paga anual), y Claude Max va de $100 a $200 dólares al mes. Para equipos, el plan Team empieza en $25 dólares por usuario al mes, y $150 dólares al mes por los asientos premium que incluyen el entorno de desarrollo Claude Code.

Si estás en la EEA (el Espacio Económico Europeo) y pagas una suscripción en dólares con una tarjeta europea típica, estás perdiendo dinero calladito en cada renovación. La mayoría de las tarjetas cobran entre 2% y 3% de comisión por transacción extranjera, encima de un tipo de cambio ya inflado. En un plan Max equivalente a 200 euros, ese 2-3% son cerca de 4 a 6 euros al mes, o sea entre 48 y 72 euros al año, solo en comisiones de cambio de divisa. Multiplícalo por un equipo de cinco personas con asientos Team, y la fuga de dinero se acumula rápido.

Aquí es donde entra Bleap. Bleap no es una herramienta de IA y no va a crear tus Skills por ti. Es una empresa fintech de tarjetas, y es la forma inteligente de pagar las suscripciones de IA de las que habla esta guía. Aquí aplican dos beneficios concretos:

  • 0% de comisión por cambio de divisa en suscripciones en dólares. Pagas tu recibo de Claude Pro, Max o Team al tipo de cambio real, sin comisión por transacción extranjera y sin recargo de fin de semana. El dinero que se hubiera ido en comisiones de cambio, se queda en tu bolsillo.
  • 20% de cashback en Claude, ChatGPT y Gemini. Bleap te da un 20% de cashback fijo (pagado en USDC) en las suscripciones a esas tres herramientas de IA específicas. En un plan Claude Pro de $20 dólares al mes, eso es dinero real de vuelta cada mes, y en un plan Max de $200 dólares al mes, es bastante más.

Es una tarjeta de débito Mastercard autocustodiada que puedes usar en cualquier lugar donde acepten Mastercard, sin ninguna suscripción mensual propia. No hay nada que sacrificar: mantienes control total de tus fondos, pagas tus facturas de IA exactamente como antes, y dejas de perder dinero en comisiones de cambio de divisa mientras ganas cashback en las tres suscripciones de IA más importantes. Para cualquiera que use Claude en serio, al grado de estar creando Skills, esa es una optimización que se explica sola.

Una nota honesta: el cashback plano del 20% aplica específicamente a Claude, ChatGPT y Gemini. Para otras herramientas de IA sigues obteniendo el beneficio de 0% de comisión por cambio de divisa en cobros en USD, pero no el 20% de cashback. Y las bóvedas de ahorro de Bleap, que pagan 3.65% AER (Steady, el riesgo más bajo) y 3.83% AER (Dynamic, riesgo bajo) en USD con un mínimo de $1 y 0% de comisiones por retiro, son una función aparte que vale la pena conocer si quieres que tu saldo disponible trabaje mientras tú construyes.

Preguntas frecuentes

¿Qué es exactamente un Claude Skill?

Un Claude Skill es una unidad de instrucción autónoma y reutilizable que Claude carga bajo demanda para realizar una tarea específica de forma confiable. Los Skills son carpetas con instrucciones, scripts y recursos que Claude carga dinámicamente para mejorar su desempeño en tareas especializadas, enseñándole a completar tareas concretas de manera repetible. Técnicamente, se trata solo de una carpeta que contiene un archivo SKILL.md con metadatos en YAML e instrucciones en Markdown, además de directorios de soporte opcionales.

¿Cuál es la diferencia entre un archivo skill.md y un prompt?

Un prompt vive solo durante un turno de conversación y luego desaparece. Un archivo SKILL.md, en cambio, es persistente, versionable, detectable y reutilizable. La diferencia estructural clave es que Claude sabe activamente que un Skill existe, ya que al iniciar, el agente precarga el nombre y la descripción de cada skill instalado en su prompt de sistema. Claude nunca puede recurrir a un prompt que no se le ha mostrado, pero sí puede recurrir automáticamente a un Skill relevante.

¿Necesito saber programar para crear Claude Skills?

No. Los Skills son, en esencia, una disciplina de redacción y configuración. No son modelos ni complementos de pago; son instrucciones en markdown de código abierto más archivos de soporte. Si puedes escribir instrucciones claras en Markdown y pensar con cuidado en cuándo debería activarse una tarea, puedes crear un Skill de nivel producción. Los scripts son opcionales y solo se necesitan para tareas que requieren una ejecución determinista.

¿Cómo decide Claude cuándo usar un Skill?

Claude compara la solicitud actual con el campo description de cada Skill instalada usando similitud semántica. Como Claude tiende a subutilizar las skills, es decir, a no usarlas cuando serían útiles, Anthropic recomienda escribir descripciones que enumeren explícitamente los escenarios que deberían activar la Skill, incluyendo los implícitos. Una descripción sólida, específica y un poco insistente es el factor individual más importante para lograr una invocación confiable.

¿Qué tan largo debe ser un archivo SKILL.md?

Mantén el cuerpo enfocado. La recomendación práctica es que el cuerpo del SKILL.md se limite a lo esencial y no supere las 500 líneas; si te estás acercando a ese límite, es mejor dividir el contenido en archivos separados. El frontmatter, que siempre se carga, es diminuto (unos 100 tokens), mientras que el cuerpo solo se carga cuando se invoca la Skill. Por eso, un cuerpo ligero protege tu presupuesto de contexto y evita que las instrucciones importantes se diluyan.

¿Cómo se relacionan las Skills con MCP y los subagentes?

Son capas complementarias. MCP es la capa de conectividad que enlaza a Claude con herramientas y datos externos; una Skill es la capa de instrucciones que le dice a Claude cómo usar esa conexión. Los subagentes agregan aislamiento, y puedes integrar Skills en subagentes personalizados para delegar tareas especializadas de forma aislada. Un patrón común en producción combina los tres: MCP conecta los datos, una Skill define el procedimiento, y un subagente lo ejecuta en un contexto limpio.

¿Puedo compartir Skills con todo mi equipo?

Cada vez más, sí, aunque las herramientas todavía están madurando. En Claude.ai, las Skills actualmente son individuales para cada usuario, aunque pronto llegarán funciones de gestión y uso compartido a nivel de organización. Mientras tanto, puedes compartirlas a través de un repositorio de Git, distribuirlas mediante plugins, e implementarlas en toda la organización con configuraciones administradas empresariales. Mantener un repositorio de especificaciones compartido desde ahora te prepara para las funciones administradas que vienen en camino.

¿Cuánto cuesta usar Claude para crear Skills?

La creación de Skills en sí forma parte de los planes de Claude. Los precios de Claude en 2026 abarcan Free ($0), Pro ($20/mes), Max 5x ($100/mes), Max 20x ($200/mes), Team Standard ($25/asiento/mes), Team Premium ($125/asiento/mes) y Enterprise (personalizado). Como estos planes se cobran en dólares, pagar desde la EEA con una tarjeta que suma un 2-3% de comisión por transacción extranjera te cuesta extra cada mes. Pagar con Bleap te da 0% de comisiones cambiarias y un cashback plano del 20% en las suscripciones de Claude, así que más de tu presupuesto se va al uso real.

¿Cuál es el error más común que cometen los principiantes con las Skills?

Hay dos errores que empatan en el primer lugar: escribir una descripción demasiado vaga (por lo que la Skill nunca se activa o se activa con todo) y sobrecargar el cuerpo. La solución para el disparo es una descripción específica y rica en escenarios; la solución para la calidad del resultado es más especificidad y validación, no más extensión. Y siempre prueba con una biblioteca de casos adecuada, porque deberías crear una biblioteca de casos de prueba que cubra el uso normal, los casos límite y las solicitudes fuera de alcance.

Conclusión

Claude Skills convierte el prompting improvisado en automatización diseñada y reutilizable. La base es realmente simple: una carpeta, un archivo SKILL.md con un nombre claro y una descripción específica, un poco insistente, y un cuerpo de instrucciones ligero que Claude carga solo cuando es relevante. Domina eso, súmale MCP para conectividad, subagentes para aislar tareas y pruebas rigurosas para asegurar confiabilidad, y tendrás una biblioteca de Skills que multiplica su valor en todo tu equipo.

El esfuerzo de ingeniería es, en realidad, un esfuerzo de redacción. Delimita bien el alcance, describe con precisión, versiona todo y prueba en tres categorías. Haz esto de forma consistente y Claude dejará de ser un asistente genérico al que le tienes que explicar todo cada mañana, para convertirse en un experto especializado que ya conoce tus flujos de trabajo.

Un último consejo práctico que no tiene nada que ver con código, pero sí mucho que ver con tu presupuesto. Sin importar qué plan de Claude uses, ni qué otras herramientas de IA utilices junto con él, paga inteligentemente. Esas suscripciones se cobran en dólares, y una tarjeta común te quita silenciosamente entre 2% y 3% en cada renovación por el tipo de cambio. Con Bleap te olvidas por completo de esas comisiones cambiarias, y en Claude, ChatGPT y Gemini ganas un 20% de cashback fijo en cada pago, todo desde una Mastercard autocustodiada y sin ninguna suscripción propia. Construye Skills increíbles. Solo no pagues de más por usarlas.

Ya optimizaste tu flujo de trabajo con Claude. Ahora optimiza lo que pagas por usarlo. Bleap te da 0% de comisiones cambiarias en suscripciones en dólares y un 20% de cashback fijo en Claude, ChatGPT y Gemini, sin cuota mensual de tarjeta y con control total de tu dinero. Abre tu cuenta Bleap →

El 20% de cashback de Bleap aplica a las suscripciones de Claude, ChatGPT y Gemini, y se paga en USDC. Para otras herramientas de IA, el beneficio de 0% de comisión por tipo de cambio aplica a la facturación en USD, pero el 20% de cashback no. Las cifras de precios de Claude son vigentes a partir de 2026 y las establece Anthropic, no Bleap; consulta los precios oficiales de Anthropic para conocer los planes más recientes.

Una forma más inteligente de gastar, enviar, ganar y operar

Imagen de la sección Puntos Clave
  • Artificial Inteligence

Artículos relacionados