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

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

Antes de ponerte a construir nada, conviene entender exactamente qué es una Skill a nivel técnico, en qué se diferencia de un prompt y qué lugar ocupa dentro del ecosistema más amplio de Anthropic Claude. Esta sección sienta la base conceptual sobre la que se apoya todo lo demás.

Definiendo las Claude Skills

Una Claude Skill es una unidad de instrucción autónoma, con nombre y versión, que Claude puede invocar cuando lo 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 empezar con un frontmatter en YAML que incluya ciertos metadatos obligatorios: nombre y descripción.

Esa carpeta es todo lo que hay. No hay un modelo aparte, ni un binario propietario, ni un complemento de pago. Las Skills no son modelos, ni plugins en el sentido de WordPress, ni extras de pago. Son instrucciones en markdown de código abierto más algunos archivos de apoyo. Merece la pena tener esto claro desde el principio, porque cambia la forma de abordar el trabajo. No estás programando un sistema. Estás escribiendo documentación tan clara y tan bien delimitada que Claude puede seguirla a la perfección cada vez.

Las Skills aparecen principalmente en dos sitios. En la API de Claude, puedes usar las skills predefinidas de Anthropic y subir skills personalizadas a través de la propia API; crearlas es sencillo, basta con una carpeta con un archivo SKILL.md que contenga el frontmatter en YAML y las instrucciones. En Claude Code, viven en un directorio dentro de tu proyecto o plugin. Creas un directorio de skills en la raíz de tu plugin o proyecto y añades carpetas de skills con sus archivos SKILL.md, y Claude las detecta y las usa automáticamente en cuanto el plugin está instalado.

También existe un registro público de ejemplos. Anthropic mantiene un repositorio abierto de Skills que muestra todo el abanico de posibilidades. 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 probar aplicaciones web o generar servidores MCP, pasando por flujos de trabajo empresariales. Son una referencia muy valiosa cuando empieces a crear las tuyas propias.

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

Conviene fijar ya algunos términos, porque aparecerán a lo largo de toda esta guía:

• SKILL.md: el archivo obligatorio que está en el corazón de cada Skill. Fíjate en que el nombre del archivo va en mayúsculas en la implementación de Anthropic, aunque mucha gente se refiera a él de forma genérica como "el archivo skill.md".
• Frontmatter: el bloque YAML al principio del archivo que contiene metadatos como name y description.
• Cuerpo de la skill: las instrucciones en Markdown que van debajo del frontmatter.
• Creador de skills: el flujo de trabajo para crearlas, ya sea mediante una plantilla, la API o un directorio en Claude Code.
• Invocación: el momento en el que Claude decide que una Skill es relevante y la carga.
• Alcance de la skill: lo específico o amplio que es el propósito de la Skill.

Prompts de Claude frente a Skills: las diferencias clave

Mucha gente se pregunta por qué no puede simplemente seguir usando un buen prompt. A veces es lo correcto. Pero en cuanto una tarea se repite, se comparte o es crítica para el negocio, una Skill gana en casi todos los aspectos. Aquí tienes el desglose.

[CTA BANNER]

Persistencia. Un prompt solo existe dentro del turno de conversación en el que se ha pegado. Una vez termina la sesión, desaparece. Una Skill persiste entre sesiones y usuarios. Se almacena, se indexa y está disponible siempre que sea relevante.

Capacidad de descubrimiento. Este es el matiz 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, aportando justo la información necesaria para que Claude sepa cuándo debe usar cada skill sin necesidad de cargarla entera 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 hay que compartirlo y volverlo a compartir manualmente, y cada vez se degrada un poco más.

Control de versiones. Las Skills se pueden iterar y seguir su evolución 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 incorporar esa estructura de forma nativa.

Composición. Las Skills pueden hacer referencia a otros recursos y conectarse a subagentes para trabajos delegados. Los prompts son bloques de texto monolíticos.

Aquí tienes una comparación en paralelo según ocho dimensiones:

Cuándo usar un prompt y cuándo crear una Skill. El criterio para decidir es sencillo. Usa un prompt para peticiones puntuales, exploratorias o muy específicas de un contexto concreto. Crea una Skill cuando una tarea se repite con regularidad, necesita producir un resultado coherente, la va a usar más de una persona, o incorpora un conocimiento que de otro modo habría que volver a explicar en cada sesión. Si te encuentras pegando las mismas instrucciones dos veces, esa es la señal.

Qué lugar ocupan 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 evita que acabes creando una Skill para algo que otro mecanismo ya resuelve mejor.

Skills frente a Projects. En Claude.ai, los Projects agrupan conversaciones y archivos en torno a un objetivo común. Las Skills mejoran los Projects al añadir conocimiento procedimental reutilizable, pero no son lo mismo. Un Project 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 frente a MCP. Esta distinción es muy importante. 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 indican a Claude cómo y cuándo actuar. Muchas veces se usan ambas cosas juntas: MCP conecta Claude con tu base de datos, y una Skill le indica el procedimiento exacto para consultar y dar formato a esos datos. Una de las Skills de ejemplo de Anthropic incluso trata sobre la generación de servidores MCP, lo que demuestra lo estrechamente relacionados que están ambos conceptos.

Skills frente a 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, implementarlas en toda la organización e integrarlas en subagentes personalizados para delegar tareas de forma aislada y experta. La Skill aporta el conocimiento especializado; el subagente proporciona el contexto de ejecución aislado.

Skills frente a 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 la automatización en producción, los pipelines de CI y las funciones integradas en productos.

Skills frente a la jerarquía de contexto. Cuando Claude responde, evalúa el system prompt, el contenido de la Skill que ha cargado, los mensajes del usuario y los resultados de las herramientas. Las Skills se sitúan por encima del mensaje individual, pero por debajo de las barreras de seguridad inamovibles a nivel de sistema. Conocer esta jerarquía te ayuda a escribir Skills que orienten el comportamiento sin entrar en conflicto con los valores predeterminados de Claude.

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

El valor estratégico de las Skills se multiplica. Aquí es de donde viene esa ventaja.

Elimina la deriva de los prompts. Cuando un equipo depende de una Skill compartida, todos invocan las mismas instrucciones de referencia. Se acabó eso de "¿qué versión del prompt estás usando?". La Skill es la fuente única de verdad.

Amplía el acceso. Una Skill bien diseñada permite que perfiles no técnicos se beneficien de automatizaciones sofisticadas. No necesitan saber cómo escribir un system prompt de 400 palabras. Simplemente describen lo que quieren, y Claude recurre a la Skill adecuada.

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

El efecto biblioteca acumulativo. Cada Skill que construyes hace que la siguiente sea más valiosa, 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 se dedica a pegar prompts. Un equipo que ejecuta decenas de Skills informó que la sobrecarga es de aproximadamente 1.500 tokens en total para las 40 skills, y que solo se expande la relevante cuando hace falta.

Casos de uso reales. Este patrón aparece por todas partes: automatización de revisión de código, guías de atención al cliente, normalización de datos, control de calidad de contenidos, generación de documentos conforme a la marca y síntesis de investigación. El poder de las skills reside en su capacidad para codificar el conocimiento institucional, estandarizar resultados y gestionar flujos de trabajo complejos de varios pasos que, de otro modo, requerirían explicaciones repetidas o la inversión en construir un agente personalizado.

La tesis de la productividad es sencilla. Cada minuto que un trabajador del conocimiento dedica a volver a explicarle el mismo contexto a una IA es tiempo perdido, y es un tiempo que escala 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 conviene tomarse con cierto escepticismo cualquier porcentaje concreto que veas por ahí, pero la tendencia está clara: menos repetición, más coherencia, más rendimiento.

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

Ahora que ya sabes qué son las Skills y por qué son importantes, 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 fiable y quienes escriben Skills que acaban sin usarse porque Claude nunca detecta que son relevantes.

La arquitectura de las Claude Skills de un vistazo

A grandes rasgos, el flujo funciona así: un usuario o un agente hace una petición, Claude revisa los metadatos de cada Skill instalada, decide si alguna es relevante, carga el contenido completo de esa Skill en el contexto si es así, y 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.

Cada 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 en todo momento.
• Contenido. Lo que la Skill aporta al contexto: las instrucciones completas, ejemplos y cualquier recurso al que haga referencia. Esto se carga solo cuando hace falta.
• Ejecución. Cómo usa Claude 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. Muchos equipos suelen guardar las versiones canónicas en su propio repositorio de Git y distribuirlas desde ahí.

¿Cómo "sabe" Claude que existe una Skill? A través de la capa de metadatos que se carga siempre. El frontmatter YAML se carga siempre en el system prompt de Claude, con un coste de unos 100 tokens por skill, independientemente de cuántas skills haya instaladas, y esta capa de metadatos le da a Claude la información justa para decidir si la skill es relevante para la tarea actual sin necesidad de cargar el contenido completo. Ese coste de 100 tokens es el precio de entrada para que una Skill sea descubrible, y es lo que permite que el diseño escale a decenas de Skills.

Por último, hay dos formas de invocar una Skill. La invocación implícita ocurre cuando el propio Claude decide que una Skill es relevante en función de la descripción y de la petición del usuario. La invocación explícita ocurre cuando un usuario o un agente nombra la Skill directamente. Ambas son válidas; el equilibrio entre ellas es algo que diseñas tú mismo al redactar 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 la 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 apoyo. Aquí es donde se gana o se pierde la mayor parte de la calidad. Error habitual: ponerte a escribir antes de haber definido bien el problema. Antes de escribir nada, aclara qué problema resuelve tu skill, porque las skills sólidas abordan 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 habitual: publicarla en el lugar equivocado u olvidarte de instalar el plugin, de modo que Claude nunca llega a descubrirla.

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

Etapa 4, Invocación. Claude compara una solicitud con la descripción de la Skill y decide usarla. Riesgo: si la descripción es demasiado restrictiva, Claude nunca llega a activar la 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 la skill es relevante para la tarea actual, la cargará leyendo su SKILL.md completo en el contexto. Riesgo: un cuerpo demasiado extenso 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 la Skill. Riesgo: instrucciones que entran en conflicto con los comportamientos por defecto de Claude, lo que produce resultados incoherentes.

Etapa 7, Iteración. Tú te encargas de versionar, editar y volver a publicar. Riesgo: modificar una Skill sin actualizar la versión, de modo que nadie sabe qué comportamiento va a obtener.

El hábito más útil aquí es tratar la activación y la ejecución como aspectos independientes a la hora de probar. Prueba la activación y la ejecución por separado: si las skills no se activan, amplía la descripción y añade casos de uso, y si los resultados son inconsistentes, añade 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 la razón por la que la gente da vueltas sin avanzar.

Tipos de contenido en una Skill

No todas las Skills cumplen la misma función. Reconocer el tipo que estás creando determina cómo debes estructurar el SKILL.md.

Las Skills de solo instrucciones proporcionan 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 fiable que Claude sigue cada vez.

Las Skills de enriquecimiento de contexto aportan conocimiento específico del dominio, datos de referencia o terminología. Piensa en una Skill que incluya 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 concretos. Suelen combinarse con conexiones MCP y dirigen a Claude hacia funciones ejecutables situadas en el directorio scripts/.

Las Skills de plantilla aportan formatos de salida estructurados: un esquema JSON, una plantilla de informe, un esqueleto de código. Aquí el valor está en la coherencia de la forma, no solo en el contenido.

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

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

Cómo afecta el tipo a la estructura. Las Skills de solo instrucciones y las de plantilla suelen ser breves y pueden vivir enteramente 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á pensado el sistema de divulgación progresiva. Como regla general, mantén el cuerpo del SKILL.md centrado en lo esencial y por debajo de 500 líneas, y si te acercas a ese límite, divide el contenido en archivos separados.

Cómo decide Claude cuándo invocar una Skill

Esta es la parte que más se suele hacer mal, así que merece atención especial. 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 aciertas con la descripción, la Skill se activa de forma fiable. Si te equivocas, hasta la Skill más brillante se queda sin usar.

Hay una peculiaridad de comportamiento conocida que conviene tener en cuenta a la hora de diseñar. Claude tiende a infrautilizar las skills, es decir, a no usarlas cuando serían útiles, y para contrarrestar esto conviene hacer que las descripciones de las skills sean un poco más insistentes. La recomendación de Anthropic es detallar explícitamente las situaciones que deberían activar la Skill, incluso las implícitas. Por ejemplo, en lugar de una simple línea, podrías añadir: "asegúrate de usar esta skill siempre que el usuario mencione paneles de control, 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 menciona la Skill por su nombre, o un comando con barra la activa. Es la vía más fiable, pero depende de que quien la invoca sepa que la Skill existe.

Frases activadoras y ejemplos. Incluir ejemplos de frases y casos de uso en tu descripción afina la coincidencia semántica. Esto le da 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 añade casos de uso.

Confianza y activación excesiva. El fallo contrario es una descripción tan amplia que la Skill se activa con casi cualquier cosa, colándose en conversaciones que no tienen nada que ver. La solución está en el alcance. Una descripción bien acotada, con condiciones de activación específicas, se dispara cuando debe y permanece en silencio cuando no debe.

Varias Skills y priorización. Cuando varias Skills podrían encajar, Claude evalúa la relevancia de cada una. Los conflictos de prioridad son una categoría real de problemas a resolver, y parte de un buen diseño de Skills consiste en asegurarse de que dos Skills no compitan por el mismo terreno con descripciones que se solapan.

Contexto dinámico. Las variables en tiempo de ejecución, los archivos concretos que están 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á más fácilmente cuando haya una conexión a una base de datos disponible. Diseñar teniendo en cuenta este contexto dinámico es lo que hace que una Skill dé la sensación de "saber" cuándo tiene que echar una mano.

Crear y probar Skills todo el día significa consumir a toda velocidad tu plan de Claude. Claude Pro cuesta 20 $/mes y Max va de 100 $ a 200 $/mes, facturados en USD. Paga con Bleap y consigues un 0% de comisiones de cambio de divisa además de un cashback plano del 20% en Claude, ChatGPT y Gemini, sin cuota de suscripción de la tarjeta. Consigue la tarjeta Bleap →

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

Basta de teoría. Vamos a construir una Skill funcional de principio a fin. Usaremos un ejemplo real, una Skill de Checklist de Revisión de Código, y recorreremos 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 de organización todavía está madurando. Según las indicaciones actuales, en Claude.ai las skills son por ahora individuales para cada usuario, aunque próximamente llegarán funciones de gestión y uso compartido a nivel de organización. Mientras tanto, se recomienda crear un repositorio de documentos compartido con las especificaciones de las skills, para prepararte de cara a estas futuras funciones y establecer desde ya una buena gobernanza.

En cuanto al acceso de pago, los planes de Claude 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 $/puesto/mes), Team Premium (125 $/puesto/mes) y Enterprise (a medida). Si estás creando Skills como parte del flujo de trabajo de un equipo, los planes Team y Enterprise añaden los controles de administración que acabarás necesitando. Si estás automatizando de forma programática, la API se factura aparte, por token.

Conocimientos necesarios. Sinceramente, no hace falta mucho. Markdown básico y tener 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 llevadero. Git te da control de versiones desde el primer día. Mantén abierta una conversación de Claude dedicada exclusivamente a las pruebas, separada de tu trabajo real, para que el contexto no contamine tus tests.

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

Tres formas de crear una Skill. Puedes escribirla directamente en un directorio skills/ en Claude Code, subirla a través de la API de Claude, o partir de la plantilla de Anthropic. Puedes crear skills que transformen Claude de asistente de propósito general a experto especializado, ya sea con la plantilla del creador de skills o de forma manual, y para simplificar el proceso se recomienda construir tu archivo SKILL.md a partir de la plantilla y adaptarlo desde ahí.

Planifica tu Skill antes de escribir una sola línea

Resiste la tentación de abrir tu editor. Las mejores Skills se planifican primero. La guía de Anthropic es clara al respecto: identifica dos o tres casos de uso concretos antes de tocar ningún archivo, y pregúntate qué conocimiento del dominio o buenas prácticas deberían incorporarse para que el usuario no tenga que explicarlo en cada sesión.

Responde a estas cinco preguntas antes de empezar a escribir:

1. ¿Qué tarea específica permite realizar esta Skill? En nuestro ejemplo: "Revisar un diff de código según la checklist de calidad de nuestro equipo y generar un informe de hallazgos estructurado."
2. ¿Cómo sabrá Claude o un usuario cuándo invocarla? Cuando alguien comparta un diff, una pull request, o pida una revisión de código.
3. ¿Qué información debe estar en el contexto para que la Skill funcione? Los criterios de la checklist y el formato de salida. El código en sí lo aporta el usuario.
4. ¿Qué herramientas, si las hay, necesita la Skill? Para una checklist pura, ninguna. Si ejecutara linters, necesitaría acceso a scripts.
5. ¿Quién debería tener acceso? Empieza en privado y amplía al equipo una vez que esté probada.

Alcance estrecho, no amplio. Una Skill que "ayuda con código" es inútil porque se activa con todo y no aporta nada concreto. Una Skill que "revisa pull requests de Python según la checklist de nuestro equipo y devuelve hallazgos agrupados por gravedad" es precisa, se activa correctamente y aporta un valor consistente. Cuanto más estrecho, mejor, casi siempre.

Escribe primero la descripción, como si fuera una especificación. Trata la descripción como un documento de especificación. Si no puedes describir en dos o tres frases exactamente qué hace la Skill y cuándo debe activarse, aún 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 e itera a partir de ahí. Anthropic plantea el objetivo con claridad: al final del proceso serás capaz de crear una skill funcional en una sola sesión, que es justo lo que promete la guía oficial a quien sigue la estructura correctamente.

Paso 1: Configura el directorio de tu Skill

Crea una carpeta para la Skill. La estructura recomendada es:

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

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

Convenciones de nomenclatura. Usa kebab-case para los nombres de carpeta (code-review-checklist, no CodeReviewChecklist). Añade un prefijo por categoría para que una biblioteca grande siga siendo fácil de navegar: qa-, dev-, ops-, content-. Nuestro ejemplo podría llamarse 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 forma independiente, algo que da enormes frutos 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 utiliza Claude.

Control de versiones. Inicializa Git en la carpeta o en su directorio superior, y usa etiquetas de Git para las versiones de la Skill. Cuando pases una Skill de la versión 1.2.0 a la 1.3.0, etiquétala. Tu yo del futuro, intentando averiguar por qué el comportamiento cambió el martes pasado, te lo 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 Checklist de Revisión de Código. Este es el archivo entero, desde el frontmatter hasta el cuerpo.

---
name: code-review-checklist
description: >
Revisa diffs de código y pull requests según la checklist de
calidad del equipo y devuelve los hallazgos agrupados por
gravedad. Usa esta skill siempre que el usuario comparta un diff,
una pull request, un fragmento de código para revisar, o pida una
revisión de código, un control de calidad o feedback sobre una PR,
incluso si no menciona explícitamente la palabra "checklist".
version: 1.0.0

# Checklist de Revisión de Código

Estás realizando una revisión de código estructurada. Recorre cada
punto de la checklist a continuación sobre el código que proporcione
el usuario.

## Checklist

1. **Corrección**, ¿El código hace lo que dice que hace? Señala errores de lógica.
2. **Manejo de nulos y errores**, ¿Se gestionan los casos límite y los fallos?
3. **Seguridad**, Señala secretos hardcodeados, manejo inseguro de
entradas o riesgos de inyección.
4. **Tests**, ¿Hay cobertura de pruebas adecuada para el cambio?
5. **Nomenclatura y estilo**, ¿Los nombres siguen nuestras convenciones
(archivos en kebab-case, variables en camelCase)?
6. **Legibilidad**, ¿Podría un nuevo compañero entender esto en 60 segundos?

## Formato de salida

Agrupa los hallazgos bajo tres encabezados: **Bloqueante**, **Debería
arreglarse** y **Sería recomendable**. Para cada hallazgo, cita la línea
o función correspondiente y da una recomendación de una línea, accionable.
Termina con un veredicto general de una sola frase.

## Directrices

- Si el código está limpio, dilo claramente. No inventes problemas.
- Sé específico. "Mejora el manejo de errores" no sirve de nada;
"envuelve la lectura del archivo en un try/except" sí es útil.
- No reescribas todo el archivo a menos que se pida. Señala la solución.

Esta estructura sigue 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 instrucciones que Claude seguirá cuando la skill esté activa, una sección de Ejemplos y una sección de Directrices.

Vamos a señalar lo que realmente importa:

• La description es la que hace todo el trabajo pesado. Fíjate en que está redactada de forma deliberadamente "insistente", enumerando las situaciones que deberían activarla y cubriendo explícitamente el caso en el que el usuario no usa la palabra "checklist". Esto combate la infraactivación.
• 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á fijado. Esto es lo que convierte "algo de feedback" en un informe coherente y comparable cada vez.
• Las indicaciones cierran los resquicios, diciéndole a Claude que no invente problemas y que no reescriba de más.

Errores habituales en el primer borrador. Descripciones demasiado escuetas. Instrucciones que entran en conflicto con el comportamiento por defecto de Claude (por ejemplo, decirle que sea conciso y luego pedirle explicaciones detalladas). Cuerpos que se hinchan más allá del punto de 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 confundirá a Claude. La claridad al escribir no es un capricho aquí; es la tarea de ingeniería en sí misma.

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 detectará automáticamente. Creas un directorio de skills en la raíz de tu plugin o proyecto y añades carpetas de skills que contengan archivos SKILL.md, y Claude las descubre y las usa automáticamente cuando el plugin está instalado.

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 de inicio rápido de la Skills API precisamente para esto.

En Claude.ai, añade 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. Ten en cuenta que, por ahora, en Claude.ai las Skills están limitadas al usuario individual, aunque un uso compartido más amplio ya está en la hoja de ruta.

Configurar el nivel de acceso. Empieza en modo privado. Comprueba que la Skill funciona de forma aislada antes de exponerla a un equipo o espacio de trabajo. Siempre es más fácil ampliar el acceso más adelante que desmontar una Skill defectuosa de la que ya dependen una docena de personas.

Después de publicarla, hay un breve proceso de indexación en el que los metadatos se cargan en el system prompt. En una sesión ya iniciada, puede que necesites recargarla o empezar de cero para que una Skill recién añadida esté disponible.

Paso 4: Ejecuta tu primera prueba de invocación

Abre una conversación nueva. Esto es importante. Una conversación ya existente arrastra contexto que puede enmascarar si tu Skill realmente se ha activado o si Claude simplemente está respondiendo a mensajes anteriores.

Prueba primero la invocación implícita. Pega un diff de código y simplemente di: "¿Puedes revisar esto?". No menciones la Skill por su nombre. Si tu descripción está bien redactada, Claude debería recurrir a la Skill automáticamente y devolver el resultado en el formato que has definido.

Después, prueba la invocación explícita. Haz referencia directa a la Skill y confirma que se activa a demanda.

Interpreta la respuesta. La señal más clara de que la Skill se ha cargado es que el resultado coincide exactamente con el formato que has definido: hallazgos agrupados bajo Bloqueante, Debería corregirse y Estaría bien tenerlo, junto con un veredicto de una sola frase. Si en su lugar recibes comentarios genéricos en prosa, es probable que la Skill no se haya activado.

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

1. El resultado sigue tu formato especificado con precisión.
2. Claude aplica los puntos concretos de tu checklist, no solo buenas prácticas genéricas.
3. Respeta tus directrices (no inventa problemas en código limpio).
4. Se activa con solicitudes naturales sin que tengas que mencionarla.
5. Su comportamiento es coherente en pruebas repetidas con distintas entradas.

Si la activación no es fiable, recuerda la regla de separación de responsabilidades: para solucionar problemas de activación, amplía y afina la descripción; para solucionar problemas de calidad en el resultado, añade especificidad y pasos de validación en el cuerpo.

Errores habituales de principiante y cómo solucionarlos

Un puñado de errores explica la mayor parte de la frustración inicial.

Instrucciones que chocan con el comportamiento predeterminado de Claude. Si tu Skill le indica a Claude que se comporte de una forma que contradice su comportamiento base sin un razonamiento claro, obtendrás resultados inconsistentes. Solución: explica claramente por qué es necesaria esa desviación, y valida.

Descripciones tan amplias que la Skill se activa con todo. Una Skill que salta con cada mensaje es peor que inútil. Solución: acota el alcance, añade condiciones de activación específicas.

Nivel de acceso incorrecto antes de compartir. Publicar a nivel de todo el equipo antes de probar, o dejar expuesta una Skill defectuosa. Solución: primero en privado, y amplía el acceso solo después de validarla.

Cuerpos sobrecargados. Un SKILL.md abultado desperdicia contexto y entierra las instrucciones clave. Solución: mantén el cuerpo por debajo de 500 líneas y traslada los detalles adicionales a references/. Como indica la recomendación, mantén el cuerpo de SKILL.md centrado en lo esencial y por debajo de 500 líneas, y si te acercas a ese límite, divide el contenido en archivos independientes.

No probar casos límite. Una Skill que funciona en el caso ideal pero falla con entradas inusuales erosionará la confianza rápidamente. Solución: crea una biblioteca de casos de prueba adecuada. Crea una biblioteca de casos de prueba que cubra el uso normal, los casos límite y las solicitudes fuera de alcance.

4. Estructurar el archivo SKILL.md: metadatos, frontmatter y cuerpo

Ya has creado una Skill que funciona. Ahora vamos a profundizar en el propio archivo, porque dominar la estructura de SKILL.md es lo que marca la diferencia entre Skills que funcionan casi siempre y Skills que funcionan siempre, a gran escala y en equipo.

Entendiendo el formato del archivo SKILL.md

¿Por qué Markdown? Porque es legible para humanos, funciona bien con diffs en Git, es compatible universalmente y obliga a ser claro. Además, Markdown es la forma en que Claude ya "piensa" el texto estructurado, así que las instrucciones en Markdown son instrucciones que Claude sigue de forma natural. Es una elección deliberada: 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 consta de un bloque de frontmatter en YAML seguido de un cuerpo en Markdown. Un archivo SKILL.md debe empezar con un frontmatter YAML que incluya un nombre de archivo y una descripción, que se carga en el system prompt al arrancar. El frontmatter son los metadatos; el cuerpo son las instrucciones.

Cómo se tratan de forma diferente las dos partes. Aquí está la clave de la arquitectura de divulgación progresiva. El frontmatter se carga siempre. El cuerpo solo se carga cuando es relevante. El frontmatter YAML se carga siempre en el system prompt de Claude, con un coste aproximado de 100 tokens por skill, dando a Claude justo lo necesario para decidir si es relevante sin tener que cargar el contenido completo; el cuerpo del SKILL.md se carga cuando Claude determina que la skill es relevante, y contiene las instrucciones completas, los flujos de trabajo paso a paso, ejemplos y pautas para resolver problemas.

Límites de tamaño del archivo. No existe una cifra universal fija, pero la recomendación práctica es mantener el cuerpo por debajo de 500 líneas. Si lo superas, deberías dividir el contenido en archivos de references/ que Claude cargue bajo demanda. Anthropic diseñó un tercer nivel de divulgación precisamente para esto: cuando una Skill crece demasiado para caber en un único SKILL.md, los archivos de apoyo absorben el exceso. A medida que las skills se vuelven más complejas, pueden contener demasiado contexto como para caber en un solo SKILL.md.

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

Lo que contiene el archivo frente a 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 arrancar, solo recibe tus ~100 tokens de metadatos. Al invocarse, recibe el cuerpo. Solo lee los archivos referenciados si el cuerpo se lo indica. Diseñar teniendo en cuenta esta transformación marca la diferencia entre una Skill eficiente y una que desperdicia contexto sin que te des cuenta.

El frontmatter YAML: cada campo explicado

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

name, el identificador canónico de la Skill. Usa kebab-case, hazlo descriptivo y asegúrate de que sea único dentro de tu espacio de trabajo, para que no haya ambigüedad sobre qué Skill es cuál. code-review-checklist es un buen ejemplo; helper no lo es. El nombre es a la vez una etiqueta legible para humanos y, en la invocación explícita, lo que la gente utiliza para llamarla.

version, versionado semántico en formato MAJOR.MINOR.PATCH. Sube el PATCH para pequeñas correcciones y aclaraciones, el MINOR para nuevas capacidades que mantengan la compatibilidad 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 permite a un equipo saber exactamente qué comportamiento va a obtener, 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 con diferencia. Es el que dirige el enrutamiento de invocación mediante coincidencia semántica, y se carga siempre, así que debe justificar sus ~100 tokens. Algunas pautas que funcionan en la práctica:

• Apunta a unas 100-200 palabras. Lo bastante largo para ser específico, lo bastante corto para mantenerse dentro del presupuesto de carga permanente.
• Escribe pensando en la similitud semántica, no en amontonar palabras clave. Describe las situaciones que gestiona la Skill, no una lista de términos.
• Sé "insistente" para combatir la infraactivación. Enumera explícitamente los escenarios que la activan, incluidos los implícitos. Recuerda el ejemplo de Anthropic sobre detallar que una Skill de dashboards debería activarse siempre que un usuario mencione visualización de datos o métricas internas, aunque no pida explícitamente un dashboard.
• Una descripción sólida diría: "Revisa diffs de código y pull requests según la checklist de calidad del equipo y devuelve los hallazgos agrupados por gravedad. Úsala siempre que el usuario comparta un diff, una PR o un fragmento de código para revisar." Una débil diría: "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 el dueño de esta Skill y a quién preguntar cuando falla) y respalda la gobernanza a medida que tu biblioteca crece.

tags, una estrategia de taxonomía para facilitar la localización en bibliotecas grandes. Categorías recomendadas: dominio (security, data, content), función (review, generation, analysis), audiencia (engineering, support, marketing) y madurez (experimental, stable, deprecated). Un etiquetado coherente es lo que mantiene navegable una biblioteca de 40 Skills, en lugar de convertirla en un caos.

trigger_phrases, un array opcional de frases de ejemplo que deberían activar la Skill. Estas afinan la puntuación de invocación al darle a Claude anclas concretas. El punto óptimo está entre cinco y diez: suficientes para cubrir las formulaciones principales, pero no tantas como para acabar 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; cuando 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 suele especificar un nombre, un tipo, si es obligatorio u opcional, y un valor por defecto. Los argumentos son lo que hace flexible a una Skill: una Skill de generación de informes podría tener un argumento format (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 invoca la Skill tiene que entender, y una ruta más que tienes que probar.

Cómo escribir un cuerpo de SKILL.md eficaz

El cuerpo es donde reside la experiencia real, y la forma en que lo redactes determina directamente la fiabilidad con la que Claude la ejecuta.

Ajusta la guía al margen de libertad de la tarea. Anthropic utiliza aquí una analogía muy útil. Imagina a Claude explorando un camino: un puente estrecho con precipicios necesita barreras muy concretas (poca libertad), mientras que un campo abierto permite muchas rutas (mucha libertad), así que ajusta la guía de tu Skill al terreno. Una Skill que verifica el cumplimiento normativo necesita pasos estrictos y prescriptivos. Una Skill de lluvia de ideas puede dejar mucho más margen. No sobrerrestrinjas las tareas creativas ni infrarrestrinjas las de alto riesgo.

Estructura el cuerpo de forma predecible. Un patrón fiable es: una descripción de la tarea en una línea, un procedimiento paso a paso, un formato de salida fijo y una sección de directrices que cierre posibles lagunas. Los propios ejemplos de flujo de trabajo de Anthropic siguen esta estructura, terminando con un control de calidad: redactar siguiendo la estructura de encabezados y las directrices de tono, y luego pasar la lista de verificación de calidad antes de entregar el borrador.

Incluye ejemplos y validación. Los ejemplos concretos ayudan a Claude a entender mejor, y los pasos explícitos de validación detectan errores antes de que lleguen al usuario. Cuando los resultados son inconsistentes, la solución casi siempre es más precisión y más validación, no más extensión.

Que sea ligero. Cada línea que añades se carga en el contexto al invocar la 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 contenido cuando lo necesita. Este es el tercer nivel de la divulgación progresiva.

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

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

assets/ contiene archivos estáticos: plantillas, esquemas, contenido predefinido, imágenes. Una Skill de generación de documentos guarda aquí su plantilla de informe.

El principio general es elegante. Para activar las skills, solo hace falta escribir un archivo SKILL.md con instrucciones personalizadas para tu agente, y una skill es un directorio que contiene un archivo SKILL.md junto con carpetas organizadas de instrucciones, scripts y recursos que otorgan a los agentes capacidades adicionales. Empieza solo con el SKILL.md y añade directorios de apoyo únicamente cuando el contenido realmente supere lo que cabe en un solo archivo.

Control de acceso y empaquetado para equipos

Dos cuestiones de producción completan el panorama: quién puede usar una Skill y cómo la distribuyes.

Control de acceso. Define los niveles de acceso con criterio. Privado durante el desarrollo y las pruebas, y de equipo o espacio de trabajo una vez validado. Como Claude.ai actualmente limita las 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 las skills, lo que prepara a tu organización para futuras funcionalidades a la vez que establece buenas prácticas de gobernanza desde ya.

Empaquetado y distribución. Una vez que una Skill está bien afinada, distribúyela de forma adecuada en lugar de pasar archivos sueltos de un lado a otro. El camino más maduro es combinar Git, plugins y configuraciones empresariales. Puedes compartir skills con tu equipo subiéndolas a un repositorio, distribuirlas de forma más amplia mediante plugins, e implementarlas en toda la organización usando ajustes gestionados a nivel empresarial. Para una gobernanza 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 implementación y marcos de gobernanza adicionales.

Pruebas antes de distribuir. Nunca distribuyas una Skill que no hayas probado con una batería realista de casos. Cubre el camino normal, los casos límite y, sobre todo, las solicitudes fuera de alcance que no deberían activar la Skill. Esta última categoría es la que te permite detectar activaciones no deseadas antes de que lo hagan tus compañeros de equipo.

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

Una vez que te sientes cómodo con Skills individuales, el verdadero potencial surge al combinarlas con el resto de la plataforma Claude. Esta sección repasa los patrones que convierten una biblioteca de Skills en automatización de verdad.

Integración de MCP con Claude Skills

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

Un ejemplo concreto: MCP conecta Claude con tu base de datos de analítica. Por sí solo, Claude puede consultarla, pero no conoce las convenciones de tus tablas, las definiciones de tus métricas clave ni el formato en el que tu equipo espera los informes. Una Skill aporta todo eso. Le indica a Claude qué tablas contienen qué datos, cómo se define "usuario activo" en tu organización y exactamente cómo debe estructurarse el resultado. Juntas, convierten una conexión en bruto en un analista fiable.

La biblioteca de ejemplos de Anthropic incluye incluso la generación de servidores MCP como una de las Skills de demostración, lo que subraya lo bien que encajan de forma natural ambas capas. Cuando diseñes una Skill de activación de herramientas, asume que MCP es el transporte y centra tu SKILL.md en la lógica de decisión: cuándo recurrir a la herramienta, qué parámetros pasar y cómo validar lo que se recibe.

Subagentes de Claude y delegación de Skills

Los subagentes te permiten delegar una tarea acotada a un agente independiente con su propio contexto aislado. Combinar un subagente con una Skill te da un trabajador experto para una tarea concreta que no sobrecarga tu conversación principal.

El patrón resulta muy potente para flujos de trabajo de varios pasos. Imagina un flujo de lanzamiento: un subagente, equipado con una Skill de revisión de código, revisa el diff; otro, equipado con una Skill de changelog, redacta las notas de la versión; un tercero, equipado con una Skill de QA, genera un plan de pruebas. Cada uno funciona de forma aislada, con solo el contexto que necesita. Anthropic describe exactamente esta capacidad. Puedes integrar Skills en subagentes personalizados para delegar tareas de forma aislada y especializada, y existe una guía completa de resolución de problemas para diagnosticar incidencias, 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 coste es la complejidad de coordinación, así que recurre a los subagentes cuando una tarea realmente se beneficie 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, especialmente 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 convierte en una cuestión crítica para la seguridad. El principio es el de mínimo privilegio: una Skill solo debería desbloquear las herramientas concretas que realmente necesita, y las acciones con consecuencias reales deberían requerir confirmación.

Diseña tus Skills de activación de herramientas de forma que las operaciones de solo lectura fluyan libremente, pero las operaciones de escritura o destructivas se detengan a la espera de aprobación. Documenta en el cuerpo del SKILL.md exactamente qué herramientas usa la Skill y en qué condiciones, para que tanto Claude como cualquier revisor humano entiendan el radio de impacto. Aquí es también donde el campo author y un versionado claro demuestran su valor: cuando una Skill puede ejecutar acciones, necesitas una responsabilidad inequívoca sobre quién es su propietario y qué versión está activa.

Para las organizaciones, esto enlaza con la gestión empresarial de ajustes, donde los administradores pueden controlar qué Skills y herramientas están disponibles para cada usuario. La aprobación de herramientas debe formar parte del diseño de la Skill desde el principio, no ser un añadido posterior. Una Skill que puede actuar es una Skill que puede causar daños si se activa por error, lo que 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 escala

Probar una sola Skill es sencillo. Mantener la calidad en una biblioteca en crecimiento requiere disciplina. Tres prácticas marcan la diferencia.

Separa las pruebas de activación de las pruebas de ejecución. Como ya vimos, son dos tipos de fallo 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 debe), y otro que verifique la calidad del resultado una vez activada. Prueba la activación y la ejecución por separado; si las skills no se activan, amplía la descripción y añade casos de uso, y si los resultados son inconsistentes, añade especificidad a las instrucciones e incluye pasos de validación.

Crea una biblioteca de casos de prueba como es debido. 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 detecta regresiones antes de que lleguen a los usuarios y es el hábito más valioso para una biblioteca que va madurando.

Vigila los conflictos de prioridad. A medida que tu biblioteca crece, dos Skills con descripciones que se solapan empezarán a competir entre sí. Parte del control de calidad a escala consiste en auditar las descripciones en busca de solapamientos y acotar el alcance para que cada Skill tenga un territorio claro. Las guías de resolución de problemas de Anthropic señalan específicamente los conflictos de prioridad como una categoría conocida, así que cuenta con ellos y diseña teniéndolos en cuenta.

¿Ejecutas Claude en varios repos toda la semana para probar tu librería de Skills? Eso suele suponer un plan Max 20x a 200 $/mes, facturado en USD. Con Bleap pagas al tipo de cambio real, sin comisiones de cambio de divisa, y consigues un 20% de cashback fijo en las renovaciones de Claude, ChatGPT y Gemini, sin necesidad de suscripción a ninguna tarjeta. Consigue la tarjeta Bleap →

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

Ya tienes todo lo necesario para crear, estructurar y combinar Skills. Dos últimas piezas marcan la diferencia entre un proyecto de aficionado y una práctica de producción: la disciplina operativa y tratar el coste de tu suscripción a Claude como algo que se puede optimizar.

Checklist de buenas prácticas en producción

• Alcance reducido. Cada Skill debería hacer una sola cosa y hacerla bien. Un alcance reducido significa una activación fiable y una salida consistente.
• Escribe descripciones insistentes. Combate la infraactivación enumerando explícitamente los escenarios que deberían activar la Skill, incluidos los implícitos.
• Mantén los cuerpos ligeros. Menos de 500 líneas, con el detalle trasladado a references/. Protege tu presupuesto de contexto.
• Versiona todo. Versionado semántico junto con etiquetas de Git para que todos sepan qué comportamiento está activo.
• Prueba en tres bloques. Normal, caso límite y fuera de alcance, probando la activación y la ejecución por separado.
• Controla el acceso de forma deliberada. Privado primero, ampliar solo después de validarlo. Mínimo privilegio para las herramientas.
• Mantén un repositorio de especificaciones. Sobre todo mientras madura la compartición a nivel de organización, un repo de specs compartido mantiene al equipo alineado y te prepara para configuraciones gestionadas.
• Documenta la propiedad. Usa el campo author para que cada Skill tenga un responsable claro.

Sigue estas pautas y construirás una biblioteca de Skills que suma valor con el tiempo en lugar de acumular deuda técnica.

El ángulo del coste: pagar Claude sin perder dinero

Aquí está la parte que la mayoría de las guías ignoran. Crear Skills implica pagar por Claude, y las suscripciones de Claude se facturan en USD. Claude Pro cuesta 20$/mes (o 17$/mes con facturación anual), y Claude Max va de 100 a 200$/mes. Para equipos, el plan Team empieza en 25$ por usuario al mes, y 150$/mes para los puestos premium que incluyen el entorno de desarrollo Claude Code.

Si estás en el EEE y pagas una suscripción en USD con una tarjeta europea típica, estás perdiendo dinero silenciosamente en cada renovación. La mayoría de las tarjetas añaden una comisión del 2-3% por operaciones en el extranjero, además de un tipo de cambio inflado. En un plan Max equivalente a 200€, ese 2-3% supone aproximadamente entre 4 y 6€ al mes, o entre 48 y 72€ al año, solo en comisiones de cambio de divisa. Multiplicado por un equipo de cinco personas con puestos Team, esa 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 depende esta guía. Aquí aplican dos ventajas concretas:

• 0% de comisiones de cambio en suscripciones en USD. Pagas tu factura de Claude Pro, Max o Team al tipo de cambio real, sin comisión por operaciones en el extranjero y sin recargo de fin de semana. El dinero que se habría 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 en concreto. En un plan Claude Pro de 20$/mes, eso es dinero real de vuelta cada mes, y en un plan Max de 200$/mes es considerablemente más.

Es una tarjeta de débito Mastercard autocustodiada que puedes usar en cualquier sitio donde se acepte Mastercard, sin ninguna suscripción mensual propia. No tienes que renunciar a nada: mantienes el control total de tus fondos, pagas tus facturas de IA exactamente igual que 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, hasta el punto de crear Skills, esto es una optimización evidente.

Una aclaración honesta: el cashback fijo del 20% se aplica específicamente a Claude, ChatGPT y Gemini. Para otras herramientas de IA sigues teniendo la ventaja del 0% en comisiones de cambio en facturación en USD, pero no el 20% de cashback. Y las cuentas de ahorro de Bleap, que pagan un 3,65% TAE (Steady, riesgo más bajo) y un 3,83% TAE (Dynamic, riesgo bajo) en USD con un mínimo de 1$ y 0% de comisión de retirada, son otra función aparte que merece la pena conocer si quieres que tu saldo sobrante trabaje mientras tú construyes.

Preguntas frecuentes

¿Qué es exactamente una Claude Skill?

Una Claude Skill es una unidad de instrucciones autónoma y reutilizable que Claude carga bajo demanda para realizar una tarea específica de forma fiable. Las Skills son carpetas de instrucciones, scripts y recursos que Claude carga dinámicamente para mejorar su rendimiento en tareas especializadas, enseñándole a completar tareas concretas de manera repetible. Técnicamente, no es más que una carpeta que contiene un archivo SKILL.md con metadatos YAML e instrucciones en Markdown, además de directorios de apoyo opcionales.

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

Un prompt existe durante un solo 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 una Skill existe, porque al arrancar, el agente precarga el nombre y la descripción de cada skill instalada 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 una Skill relevante.

¿Necesito saber programar para crear Claude Skills?

No. Las 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 junto con archivos de apoyo. Si sabes escribir instrucciones claras en Markdown y piensas con cuidado en cuándo debería activarse una tarea, puedes crear una Skill de calidad profesional. Los scripts son opcionales y solo son necesarios para tareas que requieren una ejecución determinista.

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

Claude compara la solicitud actual con el campo description de cada Skill instalada usando similitud semántica. Como Claude tiende a infrautilizar 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 algo insistente es el factor individual más importante para lograr una invocación fiable.

¿Cuánto debería ocupar un archivo SKILL.md?

Mantén el cuerpo del archivo centrado en lo esencial. La recomendación práctica es que el cuerpo de SKILL.md no supere las 500 líneas, y que, si te acercas a ese límite, dividas el contenido en archivos separados. El frontmatter, que se carga siempre, es diminuto, unos 100 tokens, mientras que el cuerpo solo se carga cuando se invoca la Skill, así que mantenerlo ligero protege tu presupuesto de contexto y evita que las instrucciones importantes queden diluidas.

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

Son capas complementarias. MCP es la capa de conectividad que enlaza Claude con herramientas y datos externos; una Skill es la capa de instrucciones que le indica a Claude cómo usar esa conexión. Los subagentes añaden aislamiento, y puedes integrar Skills en subagentes personalizados para delegar tareas especializadas de forma aislada. Un patrón habitual en producción combina las tres cosas: 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 evolucionando. En Claude.ai, las Skills son actualmente individuales para cada usuario, aunque próximamente llegarán funciones de gestión y compartición a nivel de organización. Mientras tanto, puedes compartirlas mediante un repositorio Git, distribuirlas a través de plugins y desplegarlas en toda la organización con la configuración gestionada empresarial. Mantener un repositorio de especificaciones compartido ahora te prepara para las futuras funciones de gestión centralizada.

¿Cuánto cuesta usar Claude para crear Skills?

La propia creación de Skills forma parte de los planes de Claude. La tarifa de Claude en 2026 abarca Free (0 $), Pro (20 $/mes), Max 5x (100 $/mes), Max 20x (200 $/mes), Team Standard (25 $/puesto/mes), Team Premium (125 $/puesto/mes) y Enterprise (a medida). Como se facturan en USD, pagar desde el EEE con una tarjeta que añade una comisión del 2-3% por transacción en el extranjero te cuesta un extra cada mes. Pagando con Bleap tienes un 0% de comisiones cambiarias y un 20% de cashback fijo en las suscripciones de Claude, así que más parte de tu presupuesto se destina 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 primer lugar: escribir una descripción demasiado vaga (de modo que la Skill nunca se activa o se activa con todo) y sobrecargar el cuerpo. La solución para la activación es una descripción específica y rica en escenarios; la solución para la calidad de la salida es más precisión y validación, no más extensión. Y prueba siempre con una biblioteca de casos adecuada, ya que conviene crear una biblioteca de casos de prueba que cubra el uso normal, los casos límite y las solicitudes fuera de alcance.

Conclusión

Las Claude Skills convierten el prompting improvisado en automatización diseñada y reutilizable. La base es realmente sencilla: una carpeta, un archivo SKILL.md con un nombre claro y una descripción específica y algo insistente, y un cuerpo de instrucciones ligero que Claude solo carga cuando es relevante. Domina eso, añade MCP para la conectividad, subagentes para el aislamiento y pruebas rigurosas para la fiabilidad, y tendrás una biblioteca de Skills cuyo valor se multiplica en todo tu equipo.

El esfuerzo de ingeniería es, en realidad, un esfuerzo de redacción. Define un alcance concreto, describe con precisión, versiona todo y prueba en tres bloques. Hazlo de forma constante y Claude dejará de ser un asistente genérico al que tienes que volver a explicarle 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 el código y sí mucho con tu presupuesto. Sea cual sea el plan de Claude que uses, y cualesquiera otras herramientas de IA que utilices junto a él, paga con inteligencia. Esas suscripciones se cobran en USD, y una tarjeta normal se queda calladamente con un 2-3% en cada renovación. Con Bleap te olvidas por completo de las comisiones de cambio de divisa, y en Claude, ChatGPT y Gemini consigues un cashback plano del 20% en cada pago, todo desde una Mastercard autocustodiada y sin suscripción propia. Crea grandes Skills. Simplemente, 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 de cambio en suscripciones en USD y un cashback plano del 20% en Claude, ChatGPT y Gemini, sin cuota mensual de tarjeta y con control total de tus fondos. Abre una cuenta Bleap →

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