Las skills de Claude Code y los ficheros de instrucciones de sus competidores hacen cosas distintas: unas se ejecutan, los otros se leen. Una skill puede lanzar comandos antes de que Claude vea nada, correr aislada en un subagente y recibir argumentos. Un .cursorrules es un documento que siempre está ahí, ocupando contexto, sin poder hacer nada por su cuenta.
Todo el sistema se apoya en el estándar abierto Agent Skills.
Qué es una skill
Una skill es un directorio con un fichero SKILL.md: el frontmatter YAML controla cuándo se activa y las instrucciones en Markdown dicen qué hacer. Vive en .claude/skills/ si es del proyecto o en ~/.claude/skills/ si es personal, y se invoca de tres formas:
/nombre-de-la-skill, escribiéndola directamente.- Sola, cuando Claude lee el campo
descriptiony decide que encaja con la conversación. - Por palabra clave, cuando detecta un término que la skill declara.
Las skills sustituyeron a los comandos personalizados. Un .claude/skills/deploy/SKILL.md hace todo lo que hacía .claude/commands/deploy.md y, además, admite ficheros de apoyo en su propio directorio, frontmatter para controlar la invocación y carga automática.
La primera skill
La estructura es sencilla:
mi-skill/
├── SKILL.md # Instrucciones principales (obligatorio)
├── template.md # Plantilla que Claude rellena
├── examples/
│ └── ejemplo.md
└── scripts/
└── validate.shUna skill mínima:
---
name: summarize-changes
description: Resume los cambios sin confirmar y señala riesgos.
allowed-tools: Bash(git *)
---
!`git diff HEAD`
Resume los cambios anteriores en dos o tres viñetas, luego enumera
los riesgos: manejo de errores que falta, valores fijados a mano,
pruebas que hay que actualizar.Del frontmatter, los campos más usados: disable-model-invocation, para que sólo la lance una persona —lo razonable en un despliegue—; user-invocable: false, para esconderla del menú y dejarla como conocimiento de fondo; paths, para que se active según qué ficheros se estén tocando; y hooks, para engancharla a eventos del ciclo de vida.
Lo que la hace otra cosa
Contexto que se genera al vuelo. La sintaxis !`comando` ejecuta un comando de shell antes de que el contenido de la skill llegue a Claude, y mete la salida en el texto. Para varias líneas se usan bloques ```!. Así una skill trae datos vivos —el diff de git, los comentarios de un PR, el estado de un build— sin depender de ninguna herramienta externa.
Aislamiento en subagente. Con context: fork, la skill corre en un subagente separado de la conversación principal: eso evita que su trabajo ensucie el contexto de la sesión y permite lanzar varias a la vez. El campo agent elige el tipo: Explore, Plan, general-purpose o uno propio.
Argumentos. Las skills aceptan argumentos por posición y por nombre: $0, $ARGUMENTS, $ARGUMENTS[1] y $nombre para los parámetros que declaren. También hay metavariables —${CLAUDE_SESSION_ID}, ${CLAUDE_EFFORT}, ${CLAUDE_SKILL_DIR}— con las que la skill sabe algo de su propio entorno.
Permisos por adelantado. allowed-tools y disallowed-tools aprueban o vetan herramientas para esa invocación concreta, lo que evita la cadena de confirmaciones. Una skill de revisión de PR puede aprobar Bash(gh *) de antemano sin abrir la mano en todo lo demás.
Frente a Cursor Rules y Copilot Instructions
El .cursorrules de Cursor está siempre cargado y es un solo bloque: no admite argumentos, no ejecuta nada y no se aísla. El .github/copilot-instructions.md de Copilot es igual: otro documento que se lee y no se ejecuta.
Las skills son unidades que se ejecutan cuando hacen falta en lugar de contexto permanente, lo que devuelve presupuesto de tokens a la conversación. El presupuesto de las propias description acota cuántas descripciones se cargan a la vez: cuando se llena, las skills menos usadas dejan de cargarse. Y como Agent Skills es un estándar abierto, una skill puede acabar funcionando en otras herramientas que lo adopten, algo que una extensión de Cursor o de Copilot no puede.
Qué se construye con esto
Una skill de visualización del código empaqueta un script de Python junto a su SKILL.md, lo localiza con ${CLAUDE_SKILL_DIR}, aprueba Bash(python3 *) de antemano y devuelve un árbol HTML navegable del proyecto sin pasos manuales.
Una de revisión de PR usa context: fork para trabajar aparte, inyecta el diff con !`gh pr diff` y aprueba Bash(gh *): la revisión entera sale en una invocación.
Más allá de eso: despliegues, transformaciones de ficheros en lote, listas de comprobación de seguridad, revisión de escritura técnica. Claude Code trae de serie /code-review, /simplify, /debug y /batch, y todas están hechas con el mismo sistema que tiene cualquier usuario.
Plugins y comunidad
Varias skills pueden empaquetarse en un plugin junto con hooks, servidores MCP y agentes: un directorio con su manifiesto plugin.json. Anthropic mantiene un repositorio oficial con cientos aportadas por la comunidad. El plugin skill-creator trae lo que hace falta para evaluarlas: casos de prueba, ejecuciones aisladas, aprobado o suspenso, y comparación a ciegas entre dos versiones de la misma skill.
En un equipo, las skills del proyecto viajan en el control de versiones y llegan a todo el mundo sin instalar nada. En una empresa, el reparto por toda la organización se hace por configuración gestionada.
Lo que enseñó el apagón de Fable 5
Cuando el gobierno de Estados Unidos ordenó apagar Claude Fable 5 en junio de 2026, las skills que dependían de su razonamiento —revisión compleja, investigación de vulnerabilidades, análisis en varios pasos— dejaron de servir de un día para otro. El estándar hace portable la skill; no hace portable el modelo, y esa dependencia resultó ser la frágil.
Aguantaron mejor las skills escritas sin dar por supuesto un modelo concreto y con el manejo de errores previsto. El episodio empujó el interés por patrones de respaldo que se degradan a algo útil cuando el modelo de frontera no está disponible, en vez de quedarse a medias.
Inyección de contexto, aislamiento, argumentos y permisos por adelantado, todo sobre un estándar abierto: una categoría de extensión distinta a la de los ficheros de instrucciones. Para un equipo dispuesto a mantener su propia biblioteca, lo que se obtiene es un asistente que se ajusta a cómo trabaja ese equipo y no al revés.