¿Son las Claude Skills solo una alternativa a leer un libro o hay más?
Las Claude Skills no son magia, sino conocimiento ejecutable: la capa que dice a Claude cómo usar sus herramientas de forma fiable. Te explico las tres capas y cómo montarlas.
He tratado demasiado tiempo las skills como conjuros mágicos de un tema que, en realidad, no entiendo del todo. Empecé sin pensar de verdad en las skills ni abrazándolas. Sigo sin hacerlo, del todo, porque la mayor parte de lo que hago es línea de comandos, terminal, etc., etc.: ¡tengo el computer use bajo control! PERO tengo una debilidad terrible. El diseño. Nunca podría presumir de ser diseñador, y desde luego no voy a fingirlo.
Navegación rápida: Venga, ¿qué es una Claude Skill? | La brecha entre conocimiento y acción | Fase 1: mapear el centro de control .claude | Fase 2: las tres capas de revelación progresiva | Fase 3: desplegar el skill-creator | Usar el skill-creator
Así que uso una skill de diseño. Funciona (es la versión de segunda generación de la acusación de «eso está vibe coded». Ay, por ahora todo está tranquilo.
Imagen: cultofmac.com
Venga, ¿qué es una Claude Skill?
Las skills son conocimiento ejecutable. Cuando montas un servidor MCP, le das a Claude acceso a herramientas: la API de DataForSEO, mi base de datos local, lo que sea. Pero las herramientas por sí solas no garantizan resultados (todo lo contrario, porque representan una forma completamente distinta de ejecución del trabajo que aún no hemos clavado del todo). Las skills son esa capa que le dice a Claude cómo usar sus capacidades y herramientas de forma fiable, en secuencia, con salvaguardias que evitan los errores.
Hemos pasado la era de la ingeniería de prompts. El cambio ocurrió en silencio, en algún punto entre los lanzamientos de skills de octubre y ahora. Tu carpeta .claude se ha convertido en el cerebro operativo de tu equipo. Mientras tanto, las skills han evolucionado de simples disparadores al sustrato del comportamiento del agente que de verdad puedes lanzar cada semana o cada quince días.
El «espacio de trabajo moderno» ahora, en mi opinión, tiene tres capas: acceso a herramientas (MCP), lógica de ejecución (skills) y la configuración de orquestación que las ata. Dedico la mayor parte de este post a dejar ese montaje bien, con diferenciadores claros entre lo que hacen los MCP y lo que habilitan las skills.
La brecha entre conocimiento y acción
Leer un README es estático. Claude olvida. Le pides algo complejo y vuelve a tambalearse por la documentación de la API, comete el mismo error y acabas reescribiendo el prompt con más detalle solo para obtener el mismo resultado mañana.
Las skills tienden este puente al ser disparadores en lugar de documentación. Piénsalo como la analogía de la cocina de Anthropic: un MCP es la cocina profesional, fogones, cuchillos, ingredientes todo dispuesto. Una skill es la receta que asegura que de verdad cocinas algo comestible en vez de simplemente agitar los utensilios esperando la cena.
Para SEOs y marketers digitales, la diferencia es concreta. No solo quieres que Claude tenga acceso a un scraper web. Quieres que tenga la skill de auditoría SEO técnica, rastrear el sitio, marcar canonicals rotos, detectar páginas huérfanas, comprobar errores de hreflang, sin que tú enumeres los quince pasos cada vez. Eso es lo que hace una skill. Codifica el flujo de trabajo para que el modelo lo ejecute de forma consistente.
La carpeta .claude es donde vive esto. Tanto los Commands como las Skills disparan acciones, y ahora viven en la misma estructura de carpeta porque Anthropic los fusionó. Una carpeta, dos nombres para lo mismo. Uso skills cuando no sé qué estoy haciendo. Es la única parte de mi configuración que no entiendo del todo. Pero funciona, y eso basta para seguir construyendo.
Fase 1: mapear el centro de control .claude
La carpeta .claude/ a nivel de proyecto es el centro de control de cómo se comporta Claude cuando abre tu proyecto, y es la que importa para configuraciones de equipo.
La jerarquía se divide en dos partes: CLAUDE.md en la raíz (el manual de instrucciones) y .claude/rules/ dentro de la carpeta (la escala modular). CLAUDE.md es la fuente única de verdad de tu proyecto. Decisiones de arquitectura, comandos de build, patrones de nombrado, estilo de código. Vive en la raíz porque Claude mira ahí primero. La carpeta .claude/ contiene lo granular: archivos de reglas individuales, sobreescrituras por archivo, estado de sesión si usas Claude Code.
La guía de Avi Chawla Anatomy of the .claude/ Folder desgrana bien la anatomía, y se me quedó una regla: mantén CLAUDE.md por debajo de 200 líneas. A partir de ahí empieza a comerse demasiado contexto y la adherencia a las instrucciones cae. Lo probé en 250 líneas: Claude empezó a ignorar la mitad de abajo de mis instrucciones de configuración. Ahora mantengo el archivo principal ligero y divido las reglas detalladas en archivos separados dentro de .claude/rules/.
| Elemento | Propósito | Ubicación | Límite de longitud |
|---|---|---|---|
| CLAUDE.md | Instrucciones para todo el proyecto | Directorio raíz | Menos de 200 líneas |
| .claude/rules/ | Archivos de reglas modulares | Dentro de .claude/ | Sin límite estricto |
| Comandos de build | Cómo ejecutar/probar/desplegar | Sección superior de CLAUDE.md | Conciso |
| Patrones de nombrado | Convenciones de archivo/función | CLAUDE.md o rules/ | Basado en ejemplos |
El caso es que la carpeta .claude/ a nivel de proyecto se sube a git. Es para todo el equipo. Tus preferencias personales (claves de API, ajustes del editor, tu tono preferido para las respuestas) viven en ~/.claude/ en tu directorio personal. Esa no se sube. Dos carpetas, mismo nombre, trabajos distintos.
Fase 2: las tres capas de revelación progresiva
Claude decide si cargar una skill en función del campo description del frontmatter YAML, y esa descripción tiene un límite duro de 1024 caracteres. Esta es la capa uno. Siempre cargada, siempre en memoria, siempre la forma en que Claude decide «¿necesita esta conversación la skill postgres-query o no?».
Tienes 1024 caracteres para explicar qué hace la skill, cuándo usarla y qué la diferencia de otras skills del workspace. No es mucho. Pasé unos veinte minutos en una skill reciente solo intentando que la descripción cupiera en el límite sin perder las partes importantes sobre cuándo no usarla. La tentación es meter etiquetas XML para estructurar. No lo hagas. El XML en el frontmatter está bloqueado por razones de seguridad. Solo texto plano.
Si Claude decide que la skill es relevante (a partir de esa descripción), carga la capa dos: el cuerpo de SKILL.md. Aquí viven las instrucciones reales: cómo validar la entrada, en qué orden ejecutar los pasos, casos límite a vigilar. Solo se trae a contexto cuando hace falta, por eso funciona mejor que un prompt de sistema. Los prompts de sistema siempre están cargados. Las skills se cargan bajo demanda.
La capa tres son los archivos enlazados. Si SKILL.md referencia assets/config-template.json o references/api-spec.md, Claude solo los lee cuando la conversación llega a esa parte del flujo. No estás pagando coste de tokens por documentación que Claude aún no ha abierto.
| Capa | Cuándo se carga | Coste en tokens | Qué contiene |
|---|---|---|---|
| Frontmatter YAML | Siempre | ~50-150 tokens | Nombre de la skill, descripción, relevancia de disparo |
| Cuerpo de SKILL.md | Cuando es relevante | ~500-2000 tokens | Instrucciones, validación, orden de pasos |
| Archivos enlazados | Según se necesite | Variable | Ejemplos, plantillas, especificaciones, contexto |
El diferenciador es la carga condicional. Las skills te permiten mantener una biblioteca de experiencia especializada sin cargar todo de golpe en un único prompt de sistema. La skill que más uso es markdown-to-html: Claude la carga cuando estoy publicando y la ignora el resto del tiempo. Un prompt de sistema cargaría con ese peso en cada conversación.
Fase 3: desplegar el skill-creator para un montaje rápido
Imagen: keychron.com (incluida porque estoy buscando un teclado nuevo ahora mismo)
Usar el skill-creator para construir una skill que funcione
Te guiaré por el uso del skill-creator para construir una skill que funcione, porque creo en empezar siempre desde un sitio consistente, actualizado y basado en plantillas. Uso esto poco en comparación con mis plantillas de prompts agénticos, repositorios, MCP. Pero una skill se supone estática y repetible: una skill debería ser la consistencia fiable que la salida de IA puede perder si no prestas atención.
El caso es que, en realidad, entiendo los servidores MCP. ¡Yo los hago! Datos dentro, quizá escribimos esos datos en SQLite, Claude los procesa, datos fuera. Las skills siguen siendo algo opacas para mí. Funcionan, la skill de diseño de Claude ha ayudado muchísimo, pero ¿la lógica interna de cuándo Claude invoca una skill frente a cuándo la ignora? Sigue siendo un poco una caja negra desde donde estoy, simplemente se siente como una trampa de consistencia.
Así que las skills fueron un desarrollo interesante, pero tengo esta pequeña sensación. Si hubiera escrito «el» libro sobre un sistema de diseño que luego encontrara como una Claude skill, estaría muy disgustado.
Artículos relacionados
Guía para principiantes de los hooks de Claude
Los hooks de Claude Code son scripts que se ejecutan automáticamente en momentos clave de la sesión: formateo, bloqueo de comandos peligrosos y notificaciones. Esta guía explica cómo instalarlos.
Cómo configurar un proyecto de Claude Code (y qué va dónde)
Configura un proyecto de Claude Code con CLAUDE.md, la carpeta .claude/, reglas, skills, agentes y settings.json. Esta guía explica qué va en cada sitio y por qué.
¿Otro MCP de memoria? Esa no es la memoria que buscas
Metacog, un plugin de Claude Code basado en hooks frente a los memory MCP: propriocepción, nocicepción y seguimiento de refuerzo que arregla el problema del sube y baja del time-decay.