La skill rompió mi sesión principal. No fue un fallo suave — no fue una situación de "hmm, eso no se ve bien". Hablo de una ventana de contexto de 47.000 tokens consumida en ocho segundos porque una skill de investigación que había escrito intentó cargar todo el historial de issues de un repositorio de GitHub en la conversación. Claude dejó de responder a mitad de frase. La sesión quedó inservible.
Eso fue hace tres semanas. Estaba intentando construir una skill que recopilara inteligencia competitiva antes de escribir un artículo técnico. Idea simple: consultar GitHub, obtener issues recientes, resumir tendencias. La skill funcionaba — técnicamente. Pero funcionaba como una manguera de bomberos cuando intentas llenar una taza de café. Todos los datos llegaron y destruyeron todo a su alrededor.
Pasé la semana siguiente reconstruyendo esa skill usando tres funcionalidades que había estado ignorando: context forking, inyección dinámica de contexto y agentes en segundo plano. La misma skill ahora se ejecuta en su propia sesión aislada, preprocesa los datos mediante scripts de shell antes de que Claude los vea, y funciona de forma asíncrona mientras sigo programando en mi ventana principal. El costo de tokens bajó de 47.000 a unos 3.200. Misma calidad de resultado. Un universo completamente diferente de eficiencia.
Esa experiencia me enseñó algo que no había leído en ninguna documentación ni tutorial: la arquitectura básica de una skill — una carpeta con un archivo SKILL.md — es la línea de salida, no la meta. Las funcionalidades avanzadas que se construyen sobre esa base son las que transforman las skills de "atajo de prompt ingenioso" a "flujo de trabajo autónomo genuino". Y la mayoría de los desarrolladores que construyen skills ahora mismo no las han tocado.
Esto es todo lo que he aprendido sobre el lado avanzado de las skills de Claude Code — las partes que me llevaron de construir juguetes a construir sistemas.
Dónde Están las Skills Ahora (Y Por Qué lo Básico No Es Suficiente)
Si leíste mi análisis anterior sobre cómo funcionan las agent skills a nivel fundamental, conoces el concepto central: una skill es una carpeta que contiene un archivo SKILL.md con frontmatter YAML e instrucciones en markdown. Claude carga los metadatos, ve qué skills están disponibles y extrae el contenido completo solo cuando una skill es relevante para la tarea actual. Revelación progresiva. Eficiencia de contexto. Experiencia modular.
Esa arquitectura es genuinamente buena. Sigo usando skills básicas todos los días — mi formateador de mensajes de commit, mi checklist de revisión de código, mi script de verificación previa al despliegue. Son simples, funcionan y me ahorran de 10 a 15 minutos por uso.
Pero seguía chocando con paredes.
El fiasco de la skill de investigación fue el ejemplo dramático, pero los fallos más silenciosos fueron más instructivos. Una skill que necesitaba el estado actual del proyecto — qué archivos cambiaron, en qué rama estoy, qué dependencias están instaladas — pero solo podía acceder a instrucciones estáticas escritas al momento de crear la skill. Una skill que ejecutaba un flujo de trabajo complejo de múltiples pasos y contaminaba mi conversación principal con 30 mensajes de salida intermedia que no me importaban. Una skill que funcionaba brillantemente con Opus 4 pero empezaba a alucinar pasos después de cambiar a Sonnet 4.6.
Cada uno de estos fallos apuntaba a la misma brecha: las skills básicas son estáticas. Codifican conocimiento, pero no pueden adaptarse al contexto en vivo, aislar su trabajo ni demostrar que siguen funcionando correctamente a medida que los modelos evolucionan.
Anthropic claramente vio la misma brecha. El sistema de skills a marzo de 2026 incluye funcionalidades que abordan cada uno de esos problemas. El desafío es que estas funcionalidades están documentadas en diferentes páginas, explicadas en diferentes contextos y — siendo honestos — no siempre son obvias en su potencial hasta que has chocado con el muro específico que resuelven.
Voy a recorrer cada una en el orden en que desearía haberlas aprendido.
Tipos de Skills: Elige la Arquitectura Correcta Antes de Escribir una Línea
Antes de construir cualquier skill avanzada, necesitas responder una pregunta: ¿qué tipo de problema resuelve esta skill? Anthropic categoriza las skills en dos tipos, y elegir mal significa construir algo que es demasiado complicado o insuficiente.
Skills de Ampliación de Capacidades
Estas le dan a Claude habilidades que no tiene de serie. Mi skill de automatización de navegador con Airtop es una ampliación de capacidades pura — Claude no puede controlar un navegador en la nube de forma nativa, pero con la skill instalada, puede navegar sitios web, llenar formularios, extraer datos y gestionar sesiones autenticadas. La integración con Airtop compila instrucciones en lenguaje natural en código determinista que se ejecuta contra una instancia real de Chromium en la nube.
Otros ejemplos de ampliación de capacidades que uso a diario: una skill que ejecuta auditorías de Lighthouse y devuelve las puntuaciones a la conversación. Una skill que consulta mi base de datos de proyectos en Airtable. Una skill que genera y renderiza composiciones de Remotion.
El patrón es consistente — las skills de ampliación de capacidades incluyen scripts ejecutables (bash, Python, Node) que Claude invoca como herramientas. Las instrucciones en markdown le dicen a Claude cuándo y cómo usar la herramienta. El script hace el trabajo real.
Skills de Preferencias Codificadas
Estas no añaden nuevas capacidades. Codifican flujos de trabajo específicos, convenciones y patrones de toma de decisiones. Mi skill de revisión de código no le da a Claude herramientas nuevas — Claude ya puede leer código y sugerir mejoras. La skill codifica los estándares de revisión de mi equipo: verificar primero las consultas N+1, comprobar que todos los métodos públicos tienen docblocks, señalar cualquier SQL directo que no esté parametrizado, asegurar que las respuestas de error sigan nuestro contrato de API.
La distinción importa porque determina la complejidad. Las skills de ampliación de capacidades necesitan scripts, definiciones de herramientas, a veces configuraciones de servidor MCP. Las skills de preferencias codificadas son puro markdown — a menudo solo 50-200 líneas de instrucciones precisas. Si estás construyendo una skill de preferencias codificadas y te encuentras escribiendo scripts de shell, probablemente identificaste mal el tipo.
Cometí este error dos veces antes de que se me quedara grabado. Construí una skill elaborada con un script de Python para "analizar" los patrones de testing de mi base de código, cuando todo lo que realmente necesitaba era un archivo markdown diciéndole a Claude "al escribir tests para este proyecto, usa Pest en lugar de PHPUnit, simula servicios externos con Http::fake(), y siempre prueba primero el camino triste". La versión solo markdown fue más rápida de construir, más rápida de cargar y produjo mejores resultados porque Claude no alternaba entre seguir instrucciones y llamar herramientas.
Dicho esto — las skills más poderosas que he construido combinan ambos tipos. ¿La skill de investigación que finalmente arreglé? Ampliación de capacidades para la recopilación de datos (scripts de shell que consultan la API de GitHub), preferencias codificadas para el análisis (cómo ponderar diferentes señales, en qué formato generar la salida). Las skills híbridas son donde las cosas se ponen interesantes, y donde las funcionalidades avanzadas empiezan a justificar su complejidad.
Context Forking: Dale a las Skills Su Propio Espacio para Pensar
Esta es la funcionalidad que salvó mi skill de investigación. Y es la que creo que la mayoría de los desarrolladores deberían aprender primero.
Este es el problema que resuelve el context forking. Cuando una skill se ejecuta en tu sesión principal de Claude, cada token que genera — cada paso intermedio, cada dato que procesa, cada cadena de razonamiento que sigue — vive en tu ventana de contexto principal. Una skill que hace 15 pasos de trabajo antes de producir una respuesta final ha volcado 15 pasos de contexto que no pediste en tu conversación. Tu siguiente prompt ahora tiene que competir con todo ese ruido por la atención de Claude.
Medí esto en un proyecto real el mes pasado. Mi sesión principal estaba en aproximadamente 12.000 tokens cuando disparé una skill que analizaba mi package.json, verificaba dependencias desactualizadas, cruzaba referencias con vulnerabilidades conocidas y producía un plan de actualización priorizado. Para cuando la skill terminó, mi ventana de contexto contenía 38.000 tokens. La salida de la skill — la parte que realmente quería — eran unos 800 tokens. Los otros 25.200 tokens eran memoria de trabajo que nunca volvería a mirar. Y estarían ahí, consumiendo capacidad y degradando ligeramente el enfoque de Claude, durante el resto de la sesión.
El context forking elimina esto por completo. Añades una línea al frontmatter YAML de tu skill:
---
name: dependency-audit
description: Analyzes project dependencies for security issues and updates
context: fork
---
Esa directiva context: fork le dice a Claude Code que cree un subagente dedicado para esta skill. El subagente obtiene su propia ventana de contexto, su propio historial de conversación y el contenido completo de la skill inyectado al inicio. Hace todo su trabajo en aislamiento y luego devuelve solo el resultado final a tu sesión principal.
Misma skill de auditoría de dependencias, mismo proyecto. Costo en la sesión principal: unos 1.200 tokens (la solicitud y el resumen devuelto). El subagente consumió sus propios 26.000 tokens en su propia ventana, que se limpió después de que la skill terminó.
El modelo mental que me ayudó: piensa en el context forking como ejecutar una función en un hilo separado versus inline. La versión inline funciona, pero bloquea tu hilo principal y deja sus marcos de pila por ahí. La versión bifurcada se ejecuta de forma independiente y devuelve un resultado limpio.
Cuándo Bifurcar (Y Cuándo No)
Bifurco cualquier cosa que implique más de 3-4 pasos de procesamiento intermedio. Las skills cortas — formatear un mensaje de commit, generar un archivo de migración, verificar una configuración individual — funcionan bien en el contexto principal. La sobrecarga de crear un subagente no vale la pena para una skill que genera 500 tokens de memoria de trabajo.
Pero ¿cualquier cosa que haga investigación, análisis, procesamiento de múltiples archivos o razonamiento complejo? Bifúrcala. El ahorro de contexto se acumula a lo largo del día de trabajo. Antes solía reiniciar las sesiones de Claude cada 2-3 horas porque el contexto se saturaba demasiado. Con las skills bifurcadas manejando el trabajo pesado, regularmente hago sesiones completas de 8 horas sin degradación.
Algo que la documentación no enfatiza lo suficiente: las skills bifurcadas pueden especificar qué modelo de agente usar. Ejecuto mi sesión principal en Opus 4.6 por su razonamiento profundo, pero mis skills bifurcadas más simples — recopilación de datos, formateo, organización de archivos — se ejecutan en Sonnet 4.6 a una fracción del costo. Lo configuras en el frontmatter:
---
name: format-changelog
description: Generates a formatted changelog from git history
context: fork
model: sonnet
---
Una sola skill de investigación que antes me costaba $0.40 por ejecución en Opus ahora cuesta $0.06 porque el fork de recopilación de datos se ejecuta en Sonnet y solo el paso de análisis final usa Opus en mi sesión principal. A lo largo de un mes de uso diario, eso es dinero real.
Inyección Dinámica de Contexto: Skills Que Saben Lo Que Pasa Ahora Mismo
Las instrucciones estáticas fallan en el momento en que el estado de tu proyecto importa. Aprendí esto construyendo una skill de despliegue que necesitaba conocer la rama actual de git, el último hash de commit, qué variables de entorno estaban configuradas y si había migraciones pendientes. Podía codificar instrucciones sobre cómo verificar estas cosas, pero la skill gastaría tokens haciendo que Claude ejecutara comandos y procesara la salida que podría haber recopilado de antemano.
La inyección dinámica de contexto invierte el modelo. En lugar de que Claude descubra el estado del proyecto en tiempo de ejecución, un script de preprocesamiento recopila los datos antes de que la skill se cargue y los inyecta directamente en el contenido de la skill. Claude recibe la skill con datos en vivo ya incorporados. Sin paso de descubrimiento. Sin tokens desperdiciados.
La sintaxis usa marcadores !command en tu SKILL.md:
---
name: deploy-preflight
description: Runs deployment readiness checks for current branch
context: fork
---
## Current Project State
- **Branch:** !git rev-parse --abbrev-ref HEAD
- **Last commit:** !git log -1 --oneline
- **Uncommitted changes:** !git status --porcelain | wc -l
- **Pending migrations:** !php artisan migrate:status --pending 2>/dev/null || echo "N/A"
- **Node version:** !node --version
- **Environment:** !echo $APP_ENV
## Deployment Checklist
Based on the current state above, verify the following...
Cuando esta skill se activa, Claude Code ejecuta cada comando shell !command, captura la salida y reemplaza el marcador con el resultado real. Claude ve:
- **Branch:** feature/payment-gateway
- **Last commit:** a3f2c91 Add Stripe webhook handler
- **Uncommitted changes:** 3
- **Pending migrations:** 2 pending
No los comandos. Los resultados. Claude empieza a razonar sobre la preparación para el despliegue a partir del estado real del proyecto en lugar de gastar tokens descubriéndolo.
El ahorro de tokens es significativo — mi skill deploy-preflight bajó de unos 4.800 tokens (con Claude ejecutando comandos de descubrimiento) a 1.900 tokens (con estado preinyectado). Pero la mayor ganancia es la precisión. Cuando Claude descubre el estado por sí mismo, a veces interpreta mal la salida de un comando, omite una verificación si está "suficientemente seguro" o se distrae con una respuesta inesperada. Con datos preinyectados, cada dato está garantizado de estar presente y correctamente formateado.
Combinando Inyección con Forking
El verdadero golpe maestro es usar ambos juntos. Mi skill de investigación competitiva — la que inició todo este viaje — ahora se ve así:
---
name: competitive-research
description: Analyzes GitHub activity and trends for a given technology
context: fork
model: sonnet
---
## Research Context
Target technology: {{topic}}
Date range: !date -v-30d +%Y-%m-%d to !date +%Y-%m-%d
## Recent Activity
!gh api search/repositories --jq '.[0:5] | .[] | "\(.full_name) - \(.stargazers_count) stars - \(.description)"' -q "{{topic}} pushed:>$(date -v-30d +%Y-%m-%d)"
## Trending Issues
!gh api search/issues --jq '.[0:10] | .[] | "[\(.repository_url | split("/") | last)] \(.title)"' -q "{{topic}} is:issue created:>$(date -v-7d +%Y-%m-%d)"
Los comandos de shell preprocesan las consultas a la API de GitHub. El context: fork ejecuta todo en un subagente aislado en Sonnet. Mi sesión principal de Opus recibe un resumen limpio. Costo total de tokens en la sesión principal: unos 900 tokens. Trabajo total realizado: equivalente a lo que antes hacía explotar mi ventana de contexto de 47.000 tokens.
Eso no es una mejora incremental. Es una capacidad fundamentalmente diferente.
Agentes en Segundo Plano: Skills Que Trabajan Mientras Tú Trabajas
Algunas skills toman tiempo. Una auditoría de seguridad integral de una base de código. Una ejecución completa del suite de tests con análisis. Scraping y resumen de 20 páginas de documentación. Estos flujos de trabajo pueden ejecutarse durante 3-5 minutos — una eternidad cuando estás esperando a que tu terminal vuelva a ser utilizable.
Los agentes en segundo plano resuelven esto permitiendo que las skills se ejecuten de forma asíncrona. Disparas la skill, se genera un agente en segundo plano y tu sesión principal sigue respondiendo. Cuando el agente en segundo plano termina, presenta los resultados.
Uso esto a diario para mi skill de análisis de tests. Después de hacer push de una rama de feature, disparo la skill:
/skill test-analysis
La skill se bifurca en un agente en segundo plano, ejecuta el suite completo de tests, captura los fallos, analiza los reportes de cobertura y redacta un resumen. Mientras tanto, ya estoy trabajando en el siguiente feature en mi sesión principal. Tres minutos después, el agente en segundo plano regresa con:
Test Analysis Complete:
- 247 tests passed, 2 failed
- Failed: OrderCalculation::test_discount_stacking (assertion mismatch on line 89)
- Failed: PaymentGateway::test_timeout_retry (mock not returning expected response)
- Coverage: 78.3% (down 0.4% from main branch)
- Suggestion: The discount stacking failure looks like a rounding issue...
El flujo de trabajo es similar a cómo usarías Ctrl+B para enviar a segundo plano un subagente en ejecución — el agente sigue trabajando de forma independiente incluso después de que tu tarea principal continúa. El comando /tasks te da un panel de todo lo que se ejecuta en segundo plano, con IDs que puedes usar para verificar el estado, ver detalles o cancelar.
Lo que nadie te dice sobre los agentes en segundo plano: lo más valioso no es el ahorro de tiempo, sino el aislamiento de contexto. Antes de usar agentes en segundo plano, ejecutaba mi suite de tests en la sesión principal de Claude y recibía más de 200 líneas de salida de tests que tenía que filtrar mentalmente. El agente en segundo plano procesa todo ese ruido en su propio contexto y me devuelve solo la señal.
Si prefieres que alguien construya este tipo de sistema de skills multi-agente desde cero, acepto proyectos de automatización con Claude Code. Puedes ver lo que he construido en fiverr.com/s/EgxYmWD.
Instalación de Skills: El Ecosistema Es Más Grande de lo Que Crees
Debería retroceder y hablar sobre cómo obtener skills en tu sistema, porque la historia de instalación ha evolucionado rápidamente.
El Comando Plugin
El método principal es el sistema de plugins integrado de Claude Code:
/plugin install <skill-name>@<marketplace>
Para el repositorio oficial de skills de Anthropic:
/plugin install document-skills@anthropic-agent-skills
También puedes registrar marketplaces de terceros:
/plugin marketplace add alirezarezvani/claude-skills
Después de agregar un marketplace, cada skill en ese repositorio se vuelve instalable con un solo comando.
El Ecosistema skills.sh
El ecosistema de skills.sh ha explotado desde que escribí por primera vez sobre él. A marzo de 2026, hay más de 7.000 skills evaluadas en múltiples marketplaces, compatibles no solo con Claude Code sino también con Codex CLI, Gemini CLI, Cursor y Antigravity IDE. El formato universal SKILL.md significa que una skill que construyes para Claude funciona en todas estas herramientas.
El mejor método de descubrimiento que he encontrado: navegar SkillHub o el repositorio VoltAgent awesome-agent-skills, que selecciona skills de equipos oficiales de desarrollo y la comunidad. Filtra por categoría, revisa calificaciones e instala con un solo comando.
Instalación Manual
Para skills que construyes tú mismo — que es donde está el verdadero poder — tienes dos caminos:
Con alcance de proyecto: Coloca la carpeta de la skill en .claude/skills/ en tu repositorio. Cada miembro del equipo que clone el repo obtiene la skill automáticamente. Con control de versiones, compartida, consistente.
Personal: Colócala en ~/.claude/skills/ para skills que quieras disponibles en todos los proyectos. Mis skills de formateo, mis estándares generales de revisión de código, mi guía de estilo de escritura — estas viven en mi directorio personal porque no son específicas de un proyecto.
La estructura de carpetas es sencilla:
.claude/skills/
deploy-preflight/
SKILL.md # Frontmatter + instructions
scripts/
check-deps.sh # Optional executable scripts
templates/
deploy-log.md # Optional reference files
Claude ve el nombre y la descripción de la skill desde el frontmatter. El contenido completo se carga solo cuando se activa. Los scripts en la carpeta se convierten en herramientas que la skill puede invocar.
Construyendo Skills Manualmente: Los Patrones Que Realmente Funcionan
He construido unas 40 skills en los últimos cuatro meses. La mayoría de las primeras eran mediocres. Las que construyo ahora son dramáticamente mejores, y la diferencia se reduce a tres patrones que tuve que aprender a través del fracaso.
Patrón 1: Especificidad de Instrucciones Sobre Volumen de Instrucciones
Mis primeras skills tenían más de 500 líneas de instrucciones detalladas. "Si el usuario pregunta sobre X, haz Y. Si menciona Z, asegúrate de verificar W primero. En casos donde..." Exhaustivo. Y terrible.
El problema: las skills largas queman tokens de contexto incluso después del forking, y Claude empeora al seguir instrucciones a medida que el conjunto de instrucciones crece. Hay un punto óptimo — y en mis pruebas, está entre 80 y 200 líneas de markdown para la sección de instrucciones.
La solución fue escribir instrucciones como si informara a un ingeniero senior, no a uno junior. En lugar de detallar cada paso, describo el objetivo, las restricciones y el estándar de calidad. El razonamiento de Claude llena los vacíos.
Malo:
1. First, open the file
2. Then find all functions
3. For each function, check if it has a docblock
4. If it doesn't have a docblock, generate one
5. The docblock should include @param tags
6. The @param tags should list the type first, then the name
7. After the @param tags, add a @return tag
...
Bueno:
## Task
Add PHPDoc blocks to all public methods missing them.
## Standards
- Follow PSR-5 PHPDoc format
- Infer parameter types from type hints; fall back to mixed
- Include @throws if the method contains throw statements
- Keep descriptions to one sentence — if you need two, the method needs refactoring
La versión buena tiene 6 líneas en lugar de más de 30. Produce mejor resultado porque le da a Claude espacio para razonar sobre cada caso específico en lugar de seguir mecánicamente una checklist.
Patrón 2: Condiciones de Salida, No Solo Condiciones de Entrada
Cada frontmatter de skill tiene una descripción que le dice a Claude cuándo activarse. La mayoría de los constructores de skills se detienen ahí. Pero decirle a Claude cuándo la skill ha terminado es igualmente importante.
Sin condiciones de salida explícitas, las skills tienden a entregar de más. Mi skill de auditoría SEO solía seguir encontrando "una cosa más que verificar" hasta que había consumido 15.000 tokens de análisis para una sola página. Agregar condiciones de salida solucionó esto:
## Completion Criteria
- All five audit categories scored (Performance, Accessibility, SEO, Best Practices, Content)
- Critical issues listed (severity: high only)
- Three specific, actionable recommendations provided
- Total output: under 500 words
Stop when these criteria are met. Do not continue analyzing.
Patrón 3: Instrucciones de Recuperación de Errores
Las skills que llaman herramientas externas — APIs, comandos de shell, consultas a bases de datos — van a encontrar fallos. Si no le dices a Claude cómo manejar los fallos, se detiene de forma incómoda o empieza a improvisar, lo cual suele ser peor.
Cada skill de ampliación de capacidades que construyo ahora incluye una sección de modos de fallo:
## When Things Go Wrong
**API returns 401:** The token has expired. Tell the user to run `gh auth refresh` and retry.
**API returns 404:** The repository doesn't exist or is private. Ask the user to verify the repo name.
**Command timeout (>30s):** The network request is hanging. Suggest checking VPN status or retrying with `--timeout 60`.
**Empty results:** This is valid — not every query has results. Report "no data found" rather than guessing.
Never fabricate data if a command fails. Report the failure and suggest a fix.
Este único patrón eliminó aproximadamente el 80% del comportamiento impredecible que estaba viendo en mis skills.
Testing y Evaluación de Skills: La Parte Que Todos Se Saltan
Voy a ser directo con esto: si estás construyendo skills sin probarlas, estás construyendo skills que se romperán sin aviso.
Me salté el testing en mis primeras 20 skills. Luego Claude tuvo una actualización de modelo, y 6 de ellas empezaron a producir peores resultados. No rotas — peores. Degradación sutil. Mi skill de revisión de código dejó de detectar consultas N+1. Mi skill de despliegue empezó a saltarse la verificación de migraciones. No lo noté durante una semana porque las skills todavía se ejecutaban — simplemente se ejecutaban mal.
Por eso Anthropic construyó el Skill Creator.
El Skill Creator: Una Skill Que Construye y Prueba Otras Skills
El Skill Creator es una meta-skill — una skill que automatiza el desarrollo, testing y evaluación de otras skills. Instálala como plugin y obtienes acceso a dos flujos de trabajo principales:
Modo eval: Define prompts de prueba, describe las salidas esperadas, y el Skill Creator ejecuta tu skill contra cada prompt y califica los resultados. Evalúa en cinco dimensiones: completitud del frontmatter, calidad de la descripción, claridad de las instrucciones, profundidad de la explicación y tasa de aprobación del eval.
eval: Execute skill on test prompts → Grade outputs → Report scores
Modo improve: Todo lo del modo eval, más comparaciones A/B a ciegas, análisis automatizado y refinamiento iterativo. El Skill Creator ejecuta dos instancias de Claude — una con tu skill, una sin ella — les da el mismo prompt y compara las salidas. Si la versión con skill no supera significativamente la versión básica, sabes que la skill no está agregando valor.
improve: Execute → Grade → Blind A/B compare → Analyze → Iterate
Cómo Pruebo Mis Skills Ahora
Cada skill que construyo pasa por este pipeline antes de considerarla terminada:
Paso 1: Definir 3-5 prompts de prueba. Estos deben cubrir el camino feliz de la skill, un caso límite y al menos un caso adversario (un prompt que está cerca del dominio de la skill pero no debería activarla).
Paso 2: Ejecutar modo eval. Verificar que todos los prompts de prueba produzcan las salidas esperadas. Si alguno falla, revisar las instrucciones de la skill.
Paso 3: Ejecutar el test A/B. Este es el paso que cambió mi perspectiva sobre la construcción de skills. Tenía una skill que pensaba era brillante — una skill de revisión de código con estándares detallados. El test A/B mostró que Claude sin skill producía revisiones igualmente buenas en 3 de 5 casos de prueba. Mi skill "brillante" solo agregaba valor en casos límite relacionados con consultas a bases de datos y manejo de errores de API. La reescribí para enfocarse exclusivamente en esas áreas, reduje la longitud de las instrucciones en un 60%, y las puntuaciones del A/B se invirtieron a 5 de 5.
Paso 4: Volver a probar después de actualizaciones del modelo. Mantengo mis prompts de prueba en una subcarpeta tests/ dentro del directorio de cada skill. Después de cualquier actualización del modelo de Claude, vuelvo a ejecutar los evals. Esto toma unos 10 minutos para toda mi biblioteca de skills y ha detectado degradación tres veces en los últimos dos meses.
El sistema de evaluación ejecuta cada test en paralelo, en contextos aislados, para que las skills no puedan interferir entre sí durante el testing. Ese aislamiento importa — una vez tuve un test de skill que pasó cuando se ejecutó individualmente pero falló cuando se ejecutó junto con otras skills debido a una colisión de nombres en el frontmatter.
Esta disciplina de testing se siente como sobrecarga hasta la primera vez que te salva. Después se siente como la única forma responsable de construir skills.
Integración Real: Automatización de Navegador en la Nube con Airtop
La teoría es útil. Déjame mostrarte cómo se ve una skill completamente avanzada en producción.
La skill de la que estoy más orgulloso ahora mismo es mi skill de automatización de navegador con Airtop. Airtop proporciona un navegador real en la nube — no un scraper headless, no un DOM simulado, una instancia real de Chromium ejecutándose en la nube que puede manejar sitios con mucho JavaScript, sesiones autenticadas y contenido dinámico.
La razón por la que esto importa: la mitad de las automatizaciones que quiero que Claude ejecute involucran sitios web que no tienen APIs. Páginas de precios de competidores. Portales de proveedores. Bases de datos gubernamentales de cumplimiento normativo. Bolsas de trabajo. CRMs. No hay API que consultar — la única interfaz es un navegador.
La skill de Airtop resuelve esto combinando todas las funcionalidades avanzadas:
---
name: airtop-research
description: Automates web research using a real cloud browser via Airtop
context: fork
model: sonnet
---
Se bifurca en su propio contexto (porque la automatización del navegador genera salida intermedia verbosa). Usa inyección dinámica para cargar mis credenciales de API de Airtop y las URLs objetivo. Ejecuta Sonnet para los pasos de interacción con el navegador (rentable para navegación mecánica) y devuelve resultados estructurados a mi sesión principal de Opus para el análisis.
Un flujo de trabajo que ejecuté ayer: monitorear precios de la competencia en cinco herramientas SaaS. Describí lo que necesitaba en lenguaje natural, la skill lo compiló en código de automatización determinista, lanzó sesiones del navegador en la nube contra cada sitio, extrajo tablas de precios y devolvió una comparación estructurada. Tiempo total: unos 90 segundos. Equivalente manual: 20-30 minutos de alternar pestañas y copiar y pegar.
La automatización compilada es la parte que más me sorprendió. Airtop no solo reproduce mis instrucciones — genera código real a partir de ellas, que se ejecuta de forma determinista en ejecuciones posteriores. La primera ejecución es dirigida por el agente y exploratoria. Cada ejecución posterior es rápida y fiable. Es un patrón que no he visto en otras herramientas de automatización de navegador, y marca la diferencia entre "demo impresionante" y "flujo de trabajo de producción".
La Fusión de Skills y Comandos Personalizados
Un cambio arquitectónico que vale la pena mencionar: las skills y los slash commands personalizados en Claude Code están convergiendo. Las versiones anteriores los trataban como sistemas separados — los comandos eran atajos rápidos, las skills eran módulos de conocimiento más profundos. A partir de Claude Code 2.1, la línea se ha difuminado.
Una skill ahora puede registrarse como slash command a través del frontmatter:
---
name: security-audit
description: Full OWASP-aligned security review of the current project
command: /audit
context: fork
---
Escribir /audit en Claude Code activa la skill completa con todas sus funcionalidades avanzadas — forking, inyección dinámica, ejecución en segundo plano. No necesitas mantener configuraciones de comandos separadas.
Esta convergencia importa porque reduce la carga cognitiva de gestionar tu kit de herramientas. Antes mantenía un mapa mental de "cuáles cosas son skills y cuáles son comandos". Ahora todo es una skill, algunas de las cuales tienen atajos de comando. Un sistema. Una ubicación. Un framework de testing.
El post claude-skills-guide-decoded que escribí antes cubre en profundidad el formato fundamental de SKILL.md. Lo que ha cambiado desde entonces es que el formato ahora soporta significativamente más opciones de frontmatter — context, model, command, restricciones de herramientas y hooks de ciclo de vida — convirtiendo un simple archivo markdown en una configuración completa de agente.
Lo Que Me Equivoqué (Y Lo Que Haría Diferente)
Quiero cerrar con los errores, porque son más útiles que los éxitos.
Error 1: Exceso de forking. Después de descubrir el context forking, lo apliqué a todo. ¿Una skill de formateo de 3 líneas que generaba 200 tokens de salida? Bifurcada. La sobrecarga de crear un subagente excedía el costo de contexto de simplemente ejecutarla inline. Bifurca skills que generan más de 2.000 tokens de memoria de trabajo. Deja que las skills simples se ejecuten en tu sesión principal.
Error 2: Inyección dinámica sin caché. Algunas de mis llamadas !command consultaban APIs en cada activación de la skill. Si disparas una skill 10 veces en una hora, son 10 llamadas idénticas a la API. Ahora uso comandos de shell que primero verifican un resultado en caché y solo consultan en vivo si el caché está obsoleto. Patrón simple, obvio en retrospectiva, pero agoté mis límites de tasa de API antes de descubrirlo.
Error 3: Construir skills para cosas que Claude ya hace bien. El framework de A/B testing me enseñó esto: si Claude sin skill maneja la tarea con más del 80% de calidad sin una skill, la skill no vale la pena mantenerla. Las skills deben apuntar a las brechas — las convenciones específicas del proyecto, las integraciones con herramientas externas, el conocimiento de dominio que Claude no tiene. Construir una skill para "escribir buen código Python" es esfuerzo desperdiciado. Construir una skill para "escribir código Python que siga el patrón de decoradores de nuestro equipo para endpoints de FastAPI con logging estructurado" es una mejora real.
Error 4: Ignorar la historia del testing hasta que fue demasiado tarde. Seis skills rotas después de una actualización del modelo. Eso fue lo que se necesitó. Construye el suite de eval junto con la skill, no después.
La evaluación honesta de dónde están las skills ahora mismo: el sistema funciona. Las funcionalidades avanzadas — forking, inyección, agentes en segundo plano, evals automatizados — transforman las skills de "plantillas de prompts ingeniosas" en automatización de flujos de trabajo genuina. Las herramientas todavía están lo suficientemente temprano como para que encuentres bordes ásperos (los mensajes de error de las skills bifurcadas podrían ser mucho más descriptivos, y la configuración del A/B testing requiere más configuración manual de lo que debería). Pero la arquitectura es sólida, y el ecosistema se mueve a un ritmo que no veía desde los primeros días de npm.
Siete mil skills solo en SkillsMP, y el formato funciona en Claude Code, Codex CLI, Gemini CLI y Cursor. Esto ya no es una funcionalidad específica de Claude. Es un estándar de la industria formándose en tiempo real.
La pregunta no es si invertir en aprender las funcionalidades avanzadas de skills. Es si puedes permitirte seguir construyendo agentes sin ellas.
Preguntas Frecuentes
¿Qué es el context forking en las skills de Claude Code?
El context forking crea un subagente dedicado con su propia ventana de contexto para ejecutar una skill en aislamiento. Añade context: fork al frontmatter de tu SKILL.md para evitar que skills pesadas contaminen tu conversación principal. Para el recorrido completo, consulta la sección de Context Forking más arriba.
¿Cómo instalo skills de Claude Code desde el marketplace?
Ejecuta /plugin install <skill-name>@<marketplace> en Claude Code, o agrega un marketplace de terceros con /plugin marketplace add <repo>. Las skills se instalan en .claude/skills/ para uso con alcance de proyecto o en ~/.claude/skills/ para uso personal.
¿Qué es la inyección dinámica de contexto en Claude Code?
La inyección dinámica de contexto usa la sintaxis !command en SKILL.md para ejecutar comandos de shell antes de que la skill se cargue. La salida del comando reemplaza el marcador, de modo que Claude recibe datos del proyecto en vivo — rama de git, variables de entorno, respuestas de API — sin gastar tokens en descubrimiento.
¿Cómo pruebo skills de Claude Code con el Skill Creator?
Instala el plugin Skill Creator, define prompts de prueba con salidas esperadas y ejecuta el modo eval. Para una validación más profunda, usa el modo improve, que ejecuta tests A/B a ciegas comparando la salida de Claude con y sin la skill activa. Consulta la sección de Testing y Evaluación más arriba.
¿Pueden las skills de Claude Code ejecutarse en segundo plano?
Sí. Las skills con context: fork pueden crear agentes en segundo plano que trabajan de forma asíncrona mientras tu sesión principal sigue respondiendo. Usa /tasks para monitorear las skills en segundo plano, verificar su estado o cancelarlas.
Trabajemos Juntos
¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudarte.
- Fiverr (proyectos personalizados e integraciones): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y marca): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
