Nota del traductor: Este artículo fue traducido con asistencia de IA y revisado por Jim Liu (desarrollador independiente en Sídney) para corregir terminología y mejorar fluidez. Si encuentras errores o expresiones poco naturales, escríbeme. Versión original en inglés: English.

Habilidades (Skills) vs. Plugins en Claude Code: Qué hace cada uno y cuándo usarlos

Las habilidades y los plugins son formas de ampliar las capacidades de Claude Code, pero resuelven problemas distintos. Una habilidad (skill) es un archivo Markdown individual con instrucciones reutilizables que Claude carga bajo demanda. Un plugin es una unidad de distribución que agrupa varias habilidades, además de hooks, subagentes, comandos slash y servidores MCP en un único paquete instalable. La confusión surge porque un plugin puede contener cero, una o muchas habilidades; por lo tanto, una "habilidad" nunca es una alternativa al "plugin", sino una pieza fundamental dentro de este.

En resumen (TL;DR)

Una habilidad (skill) reside en un archivo Markdown (normalmente en ~/.claude/skills/{nombre}/SKILL.md) con un frontmatter en YAML que describe cuándo invocarla. Claude la carga automáticamente cuando la solicitud del usuario coincide con su descripción.

Un plugin es un paquete distribuido a través de un mercado (marketplace) o un repositorio Git. Puede incluir habilidades, hooks (scripts de bash que se ejecutan ante eventos), subagentes (personas especializadas), comandos slash y servidores MCP.

Crea una habilidad cuando tengas un flujo de trabajo repetitivo que tu equipo realice más de dos veces por semana y que dependa de conocimientos específicos del proyecto.

Instala un plugin cuando necesites integrarte con un sistema externo (GitHub, Postgres, Figma) y alguien ya haya hecho el trabajo por ti.

Una configuración madura de Claude Code suele tener ambos: un puñado de habilidades locales para los modismos de tu equipo y algunos plugins para sistemas externos.

Qué es realmente una habilidad (Skill)

Una habilidad es un prompt que Claude carga bajo demanda, activado por una descripción específica. En la práctica se ve así:

---
name: publicar-blog
description: Usar cuando el usuario quiera publicar un nuevo artículo sin desplegar código. Maneja la verificación de slugs, inserción multi-idioma y envío a IndexNow.
---

Lee primero `scripts/publish_blog.py --help`.
Luego: (1) verifica duplicados en la DB, (2) analiza drafts/, (3) SSH INSERT, (4) verifica con curl.

Claude observa la conversación. Cuando el usuario dice algo que coincide con la description de la habilidad, el cuerpo se inyecta en el contexto y Claude lo ejecuta. Ese es todo el mecanismo.

Debido a que una habilidad es un archivo Markdown, puedes versionarla en Git, comparar cambios y compartirla mediante un Gist. No hay pasos de compilación, ni gestores de paquetes, ni instalación más allá de colocar el archivo en el directorio correcto.

Cuándo destaca una habilidad:

Tu equipo realiza el mismo flujo de trabajo de varios pasos más de dos veces por semana.
Los pasos dependen de conocimientos específicos del proyecto (rutas de archivos, APIs internas, convenciones de nombres) que una herramienta genérica no podría conocer.
Quieres restringir el comportamiento de Claude a una secuencia de pasos ya probada.

Cuándo es excesivo usar una habilidad:

Quieres que Claude se conecte a una API externa. Eso es territorio de plugins (o MCP).
La tarea es algo puntual. Simplemente pídeselo a Claude directamente en lugar de formalizarlo.

Qué incluye un Plugin

Un plugin es un directorio empaquetado que se distribuye a otras personas. Su estructura canónica es:

mi-plugin/
├── manifest.json         # Metadatos del plugin y puntos de entrada
├── skills/              # Cero o más habilidades
│   └── mi-flujo/SKILL.md
├── hooks/               # Scripts de bash para eventos (PreToolUse, SessionStart)
├── subagents/           # Personas de Claude especializadas
├── commands/            # Comandos slash (/mi-comando)
└── mcp-servers/         # Configuraciones de servidores MCP

Los plugins existen porque la distribución es un problema. Puedes enviar por correo un archivo de habilidad a un compañero, pero no puedes enviarle una integración completa de GitHub con OAuth, hooks de webhooks y un subagente que conozca las convenciones de tu repositorio. Los plugins resuelven esto: instalas una vez mediante el mercado y obtienes todo configurado.

Cuándo tiene sentido un plugin:

Necesitas funciones que van más allá de las instrucciones: hooks que ejecutan bash ante eventos, servidores MCP que exponen herramientas o subagentes que asumen un rol especializado.
Quieres que otras personas instalen tu configuración. El plugin es la unidad de distribución.
La configuración implica credenciales o servicios externos (tokens de GitHub, conexiones a bases de datos) que se benefician de un flujo de instalación estructurado.

Matriz de decisión comparativa

Situación	Usar Habilidad	Usar Plugin
"Cada vez que haga commit, analiza mi TypeScript (lint)"	Habilidad (se invoca por frase de commit)	Plugin (hook en PreToolUse para `git commit`): mejor para una ejecución determinista
"Busca en mi wiki interna"	Habilidad (si la wiki es Markdown en el repo)	Plugin (si la wiki requiere API + autenticación)
"Escribe posts de blog con nuestro estilo editorial"	Habilidad (instrucciones de estilo en Markdown)	Excesivo para un plugin
"Desplegar en staging"	Habilidad (si es una llamada a un script)	Plugin (si requiere credenciales e interfaz de confirmación)
"Consultar nuestro Postgres"	Ambas funcionan: plugin vía MCP es más ergonómico; habilidad llama a psql directamente	Normalmente gana el plugin (MCP ofrece herramientas tipadas)

Ejemplos reales de una configuración activa

Utilizo Claude Code para un agente de SEO multi-sitio. Esto es lo que tengo:

Habilidades (locales, específicas del proyecto):

planificar-seo-hoy: un Markdown de 500 líneas que dirige el ciclo diario (verificación de duplicados, selección de palabras clave vía KGR, puntuación de prioridad). Es demasiado idiosincrásico para ser un plugin.
publicar-blog: lee borradores, ejecuta SQL (INSERT) en Postgres y verifica. Específico para mis dos sitios.
buscar-palabras-nuevas: filtrado KGR con mis reglas personales sobre "océanos rojos vs. azules".

Plugins (de mercados externos):

postgres-best-practices: proporciona a Claude conocimientos estructurados sobre Postgres sin que yo tenga que escribirlos.
commit-commands: ayudantes estándar para commits y Pull Requests.
figma: integración con Figma vía MCP.

La proporción coincide aproximadamente con lo que documenta el equipo de Claude Code: la mayoría de las personas terminan con 5-10 habilidades locales adaptadas a su flujo de trabajo y 3-5 plugins para sistemas externos. Las habilidades son lo que tú escribes; los plugins son lo que instalas.

Una advertencia honesta

La línea entre "demasiado específico para ser un plugin" y "suficientemente genérico para distribuir" es difusa. Empecé publicar-blog como candidato a plugin, pero me di cuenta de que los detalles de SSH y la estructura SQL están tan ligados a mi infraestructura que empaquetarlo solo crearía una plantilla confusa. Se quedó como una habilidad.

Cómo elige el sistema entre ambos en tiempo de ejecución

Cuando un usuario escribe un mensaje:

Claude lee las descripciones de las habilidades activas cargadas en el contexto.
Si una habilidad coincide, se carga en el prompt y se ejecuta.
Los plugins con comandos slash coincidentes (/figma-use) activan su flujo.
Los hooks de los plugins se disparan según eventos (antes del uso de herramientas, inicio de sesión) independientemente del mensaje del usuario.

Las habilidades son de tipo "pull" (Claude decide cuándo cargar). Los hooks dentro de los plugins son de tipo "push" (el sistema los dispara según lo programado). Esa es la diferencia estructural más importante: los hooks obligan, las habilidades sugieren.

Preguntas frecuentes (FAQ)

¿Puede un plugin contener una habilidad?

Sí. El directorio skills/ de un plugin es el lugar canónico para distribuir habilidades que forman parte de tu integración.

¿Puedo instalar plugins sin un mercado oficial?

Sí, cualquier repositorio Git con la estructura de plugin funciona. Solo tienes que apuntar Claude Code a la URL.

¿Hay conflictos entre habilidades y plugins?

Generalmente no. Las habilidades se activan por disparadores conversacionales; los plugins, vía comandos slash o hooks. Si dos habilidades coinciden con el mismo disparador, Claude elige la descripción más específica.

¿Debería escribir un plugin para la herramienta interna de mi equipo?

Solo si la va a usar más gente aparte de tu equipo, o si la herramienta requiere autenticación/servicios externos que se beneficien de una instalación estructurada. De lo contrario, una habilidad compartida en un repositorio Git es más ligera.

¿Dónde se guardan realmente las habilidades?

A nivel de usuario: ~/.claude/skills/{nombre}/SKILL.md. A nivel de proyecto: .claude/skills/{nombre}/SKILL.md. Claude Code carga ambos, y el proyecto tiene prioridad en caso de conflictos de nombres.

¿Cómo activo una habilidad manualmente?

Puedes usar el comando slash: /nombre-de-la-habilidad. O simplemente describe lo que quieres y Claude buscará la coincidencia con la descripción de la habilidad.

Qué construiría yo primero

Si eres nuevo en esto y te preguntas por dónde empezar: escribe tres habilidades antes de tocar los plugins. Elige tres flujos de trabajo que tu equipo haga repetidamente (revisión de código, notas de lanzamiento, creación de estructuras de tests) y captura los pasos en Markdown. Observa si Claude los utiliza de manera fiable. Ese ejercicio por sí solo te enseñará más sobre cuándo recurrir a un plugin que cualquier diagrama de arquitectura.

Los plugins vienen después, cuando choques con una pared: "necesito hooks para obligar a X" o "necesito que Claude hable con nuestra API interna". Hasta entonces, las habilidades ofrecen un ciclo de aprendizaje mucho más rápido.

Jim Liu dirige OpenAIToolsHub, donde reseña herramientas de desarrollo de IA como Claude Code, Cursor y Copilot. Ha estado construyendo configuraciones multi-agente de Claude Code para automatización de SEO desde principios de 2026 y mantiene una colección de habilidades de Claude Code que cubre flujos de trabajo comunes.

Perspectiva LATAM y España

Para los desarrolladores en España y Latinoamérica, el acceso a Claude Code y la API de Anthropic ha mejorado significativamente, aunque persisten retos logísticos de facturación. En países con restricciones cambiarias como Argentina, el pago en dólares mediante tarjetas internacionales sigue siendo el principal obstáculo, mientras que en España el servicio opera bajo el marco de la GDPR europea. Aunque no existen motores de IA locales que compitan directamente con Claude en integración de terminal, las startups de la región —desde fintechs en Ciudad de México hasta scale-ups en Madrid— están aprovechando las Skills para estandarizar flujos de trabajo y automatizar la migración de sistemas heredados. Un caso de uso frecuente es la creación de habilidades personalizadas para validar normativas fiscales locales o generar documentación técnica bilingüe, permitiendo que equipos pequeños optimicen su ciclo de desarrollo sin la sobrecarga de herramientas con interfaces visuales más pesadas.