En septiembre escribí sobre las agent skills que Apple incluyó en Xcode 27. Desde entonces las uso a diario, y además dediqué una sesión entera a revisar qué más existe en el ecosistema: repositorios de la comunidad, skills de otros fabricantes, servidores MCP. Leí cada una, revisé sus scripts y me quedé con un conjunto pequeño.
De ese trabajo sale esta serie de tres partes:
- Parte 0 (esta): qué son las agent skills y por qué importan.
- Parte 1 (mañana): el set esencial, lo que tengo instalado de forma global y por qué.
- Parte 2 (pasado mañana): las skills especializadas, qué instalar según el tipo de app.
Si ya usas skills a diario, puedes saltar directo a la parte 1. Si el término te suena pero nunca has instalado una, empieza aquí.
El problema que resuelven
Un modelo de lenguaje aprende lo que existe hasta su fecha de corte. El SDK de Apple cambia cada junio. Esa distancia se nota todo el tiempo: el agente propone un ObservableObject cuando tu proyecto ya usa @Observable, escribe tests con XCTest cuando tú migraste a Swift Testing, o no sabe que en iOS 27 @State pasó a ser una macro y por qué de repente aparecen errores de compilación que antes no existían.
Hasta hace poco había dos formas de corregir eso:
- Explicarlo en cada conversación. Funciona, pero lo repites una y otra vez.
- Escribirlo en un archivo de reglas (
CLAUDE.md, las reglas de Cursor o equivalentes). Funciona mejor, pero ese archivo se carga completo en cada sesión, la necesites o no. Si metes ahí todo lo que sabes de SwiftUI, Swift Testing, concurrencia y StoreKit, terminas pagando miles de tokens de contexto para corregir un typo.
Una agent skill es la tercera vía: conocimiento empaquetado que el agente solo carga cuando lo necesita.
Qué es una skill, en concreto
Una skill es una carpeta. Dentro hay, como mínimo, un archivo SKILL.md. Este es el inicio real de una de las skills de Apple:
---
name: modernize-tests
description: "Modernize test suites to use modern Swift Testing features or migrate from XCTest."
---
# Modernize Tests
Test modernization refers to two potential actions: migrating from XCTest
to Swift Testing, and updating existing Swift Testing tests to use
recommended patterns.
...Tiene dos partes:
- El encabezado (frontmatter): un nombre y una descripción de una o dos líneas.
- El cuerpo: las instrucciones completas, con ejemplos, casos límite y lo que no hay que hacer. Puede ocupar cientos de líneas.
Opcionalmente, la carpeta incluye archivos de referencia adicionales o scripts que el agente puede ejecutar. Por ejemplo, la skill de Apple que audita la configuración de seguridad de un proyecto de Xcode trae un script que filtra la salida de los build settings.
Cómo la usa el agente sin gastar contexto
Aquí está la idea que hace que todo funcione:
- Al empezar una sesión, el agente lee solo las descripciones de todas las skills instaladas. Cada una cuesta entre 40 y 230 tokens, aproximadamente.
- Cuando le pides algo, el agente compara tu petición con esas descripciones.
- Si alguna encaja, carga el cuerpo completo de esa skill y sigue sus instrucciones.
En mi configuración tengo nueve skills globales y, entre todas, su costo fijo es de unos 670 tokens por sesión. A cambio, cuando migro un test o arreglo un data race, el agente trabaja con instrucciones de cientos de líneas que de otra forma tendría que haberle explicado yo.
Algunas skills dejan explícito cuándo deben activarse. La skill device-interaction de Apple, que verifica la app en el simulador, empieza así:
TRIGGER when: user asks to verify/test/check if the app works on device,
after implementing a UI-affecting feature that needs device verification...
DO NOT TRIGGER when: user asks about unit tests only, build-only requests
without device testing...Esa precisión es la diferencia entre una skill útil y una que se activa cuando no toca.
Skills frente a reglas
Las dos cosas conviven, y conviene saber qué va en cada lado:
Archivo de reglas (CLAUDE.md y similares) | Agent skill | |
|---|---|---|
| Cuándo se carga | Siempre, completo | La descripción siempre; el cuerpo solo si aplica |
| Para qué sirve | Convenciones de tu proyecto: ramas, estructura, qué no tocar | Conocimiento de un tema: SwiftUI, Swift Testing, StoreKit |
| Quién lo escribe | Tú | Tú, la comunidad o el fabricante |
| Dónde vive | En el repo | Global (todas tus sesiones) o dentro de un proyecto |
Mi regla práctica: si algo es cierto solo en este proyecto, va en el archivo de reglas. Si es cierto en cualquier proyecto que use esa tecnología, es material para una skill.
Dónde funcionan hoy
El formato nació en Claude Code, que busca skills en dos lugares:
~/.claude/skills/: skills globales, disponibles en todas tus sesiones.<tu-repo>/.claude/skills/: skills de un proyecto, que solo cuestan contexto cuando trabajas en ese repo.
Como el formato es solo una carpeta con Markdown, otros agentes lo adoptaron. Como conté en el post de septiembre, Codex y Cursor leen skills desde ~/.agents/skills/, y Xcode 27 exporta las suyas a la carpeta que tú elijas. La serie está escrita desde mi flujo, que es Claude Code, pero lo que cuento sobre qué skills valen la pena aplica igual si usas otro agente que las soporte.
Por qué importa que Apple publique las suyas
Hasta este año, las skills para desarrollo Apple venían de la comunidad. Hay trabajo excelente ahí, y en la parte 1 hablo de varias. Pero con Xcode 27 pasó algo distinto: Apple publicó diez skills oficiales, escritas por el equipo que diseña las APIs. Las exportas así:
xcrun agent skills export ~/ruta/donde/quierasEso cambia tres cosas:
La fuente. Cuando una skill de la comunidad te dice cómo estructurar el data flow en SwiftUI, es la opinión informada de alguien con experiencia. Cuando lo dice la skill de Apple, es la forma en que Apple espera que uses su framework. La idea es que el agente se apoye en esa fuente en lugar de lo que recuerda de su entrenamiento.
La velocidad. Las skills de Apple salen con cada versión de Xcode. swiftui-whats-new-27 existe porque iOS 27 trajo cambios que ningún modelo podía conocer de antemano. En lugar de esperar a que el modelo se entrene de nuevo, el conocimiento llega con la herramienta.
La legitimidad. Que Apple adopte el formato le dice al resto del ecosistema que las agent skills ya son parte del flujo normal de trabajo.
Lo que una skill no hace
Para poner las expectativas en su lugar:
- No le da al agente capacidades nuevas. Le da contexto. Una skill de StoreKit no hace que el agente pueda comprar algo; hace que escriba mejor código de StoreKit.
- No reemplaza la documentación. La complementa. Para entender a fondo una API, la documentación de Apple sigue siendo la referencia.
- No garantiza que el código sea correcto. Reduce los errores de “eso ya no se hace así”, pero el código se revisa y se prueba igual que siempre.
- No es gratis instalar todo. Cada skill global suma su descripción a todas tus sesiones, y dos skills que cubren el mismo tema compiten entre sí. Más skills no significa mejor resultado.
Antes de instalar cualquier skill
Una skill puede incluir scripts que el agente ejecuta en tu máquina. Por eso trato cada skill de terceros como trataría una dependencia nueva:
- Leo el
SKILL.mdcompleto y cualquier script que traiga. - Copio solo la carpeta de la skill, no el repositorio entero ni sus plugins asociados.
- Fijo la versión (el commit que revisé) y anoto de dónde vino.
Las de Apple vienen dentro de Xcode, así que el riesgo es distinto, pero el criterio de “instalar solo lo que uso” aplica igual. De las diez, tengo tres instaladas de forma global, otras cuatro las instalo por proyecto cuando las necesito y tres no las uso porque no encajan con lo que desarrollo.
Cuáles son, por qué esas y cómo instalarlas, es justo lo que cubre la parte 1.