GitHub Copilot Skills: Convierte la IA en un Experto de Tu Dominio
Aprende a crear, gestionar y potenciar GitHub Copilot Agent Skills con SKILL.md. Flujos ideales, ejemplos reales y cómo hacer que la IA entienda tu proyecto.
Imagina que tienes un colega nuevo en el equipo. Es brillante, escribe código rápido, nunca se cansa. Pero cada mañana llega sin memoria del día anterior. No sabe cómo se llaman sus convenciones. No sabe que el proyecto usa DDD. No recuerda que los tests van en /test/integration/ y no en la raíz. Cada conversación empieza desde cero.
Eso es Copilot sin contexto.
La herramienta existe. El modelo tiene capacidad. Pero sin estructura que lo guíe, terminas repitiendo las mismas instrucciones una y otra vez, en cada sesión, en cada tarea. Y lo que debería ser un multiplicador de productividad se convierte en un autocomplete caro con memoria de pez.
Los Agent Skills son la respuesta a ese problema. No son un truco. Son el mecanismo por el que le enseñas a Copilot exactamente qué hacer cuando enfrenta tareas específicas de tu dominio, y lo hace bien desde el primer prompt.
La IA sin contexto es solo un autocomplete caro
GitHub Copilot tiene cuatro mecanismos para personalizar su comportamiento, y confundirlos es uno de los errores más comunes que he visto en equipos que empiezan a integrar IA en su flujo de trabajo:
Custom Instructions (.github/copilot-instructions.md) definen estándares de código que se aplican siempre. Convenciones del proyecto, reglas de nomenclatura, preferencias de estilo. Son instrucciones permanentes, de bajo volumen, que el agente lee en cada solicitud. Úsalas para respuestas del tipo: “en este proyecto usamos Go 1.25, las interfaces van en paquete domain, y los errores se envuelven con fmt.Errorf”.
Prompt Files (.github/prompts/*.prompt.md) son tareas automatizadas que invocas manualmente. Scaffolding de un componente, preparar un pull request, generar un resumen de cambios. Son ligeros, para una sola tarea a la vez.
Custom Agents (.github/agents/*.agent.md) son personas especializadas: el revisor de seguridad, el arquitecto de datos, el experto en testing. Controlan herramientas disponibles, modelo, y comportamiento end-to-end.
Agent Skills son la pieza intermedia que más se subestima. Son carpetas de instrucciones, scripts y recursos que Copilot carga bajo demanda cuando la tarea es relevante. A diferencia de las custom instructions que siempre están activas, un skill solo consume contexto cuando el agente lo necesita. A diferencia de un prompt file, puede incluir archivos de soporte: templates, scripts, ejemplos de entrada/salida.
La pregunta clave es: ¿cuándo aplica cada uno?
| Necesidad | Mecanismo |
|---|---|
| Reglas permanentes del proyecto | Custom Instructions |
| Tarea puntual y repetible | Prompt File |
| Persona especializada | Custom Agent |
| Capacidad reutilizable con recursos | Agent Skill |
Cuando quieres que Copilot sepa cómo ejecutar y depurar tus integration tests, o cómo preparar una release siguiendo tu proceso específico, o cómo revisar código con los criterios exactos de tu equipo, ese es territorio de un skill.
Qué es un Agent Skill
Un skill es una carpeta con un archivo SKILL.md en su raíz. Puede también incluir scripts, templates y ejemplos. El sistema es un estándar abierto documentado en agentskills.io, lo que significa que los skills que creas en VS Code funcionan también en GitHub Copilot CLI y en el Copilot cloud agent.
La portabilidad importa. Si tu equipo usa Copilot desde el terminal para automatizaciones, y otro desarrollador lo usa desde VS Code para code review, el mismo skill funciona en ambos entornos sin modificación.
Los skills se guardan en dos lugares:
# Skills de proyecto (en el repositorio)
.github/skills/
.claude/skills/
.agents/skills/
# Skills personales (en tu perfil de usuario)
~/.copilot/skills/
~/.claude/skills/
~/.agents/skills/La distinción importa desde el primer día. Un skill de proyecto viaja con el código: cualquier desarrollador que clone el repo tiene acceso a él. Un skill personal es tuyo, aplica en todos tus proyectos, y nadie más en el equipo lo tiene por defecto.
Para un equipo, la convención clara es: los skills de flujo de trabajo del proyecto van en .github/skills/, los de preferencias personales van en ~/.copilot/skills/.
El modelo de carga progresiva
Aquí está el detalle que diferencia a los skills de un sistema de instrucciones simples: Copilot no carga todo el contenido de todos los skills en cada conversación. Los skills usan un modelo de tres niveles que mantiene el contexto eficiente incluso cuando tienes decenas instalados.
Nivel 1: Discovery. Copilot lee solo el name y description del frontmatter YAML de cada skill. Nada más. A partir de esa metadata decide si el skill es relevante para tu solicitud actual. Si preguntas “ayúdame a debuggear este GitHub Action que falla en CI”, Copilot matchea ese intent con la descripción de tu skill github-actions-debugging.
Nivel 2: Instructions. Si hay match, Copilot carga el cuerpo del SKILL.md — las instrucciones detalladas, el paso a paso, los criterios. Este es el contenido que guía el comportamiento del agente para esa tarea.
Nivel 3: Resources. Mientras el agente trabaja siguiendo las instrucciones, accede a los archivos adicionales del skill solo cuando los necesita: scripts de soporte, templates, ejemplos. Si no están referenciados en las instrucciones, no se cargan.
Este diseño tiene una consecuencia directa: puedes instalar 30 skills sin impactar el rendimiento de las tareas cotidianas. El costo de contexto es proporcional al trabajo que estás haciendo, no al número de skills instalados.
La descripción del frontmatter es el contrato de carga. Una descripción vaga produce matches inciertos. Una descripción precisa produce invocaciones exactas.
Crear tu primer skill desde cero
El proceso comienza con la estructura de carpetas. El nombre del directorio debe coincidir exactamente con el campo name del frontmatter. Si no coinciden, el skill falla en silencio — uno de los errores más frustrantes de depurar.
.github/skills/
└── api-integration-testing/
├── SKILL.md
├── test-template.http
└── examples/
├── auth-test.http
└── pagination-test.httpAhora el SKILL.md. El frontmatter tiene estos campos:
---
name: api-integration-testing
description: >
Skill para diseñar, ejecutar y depurar tests de integración para APIs REST.
Úsalo cuando necesites crear casos de prueba end-to-end, verificar contratos
de respuesta, o depurar fallos en tests existentes de integración.
argument-hint: "[endpoint o módulo a probar] [tipo de test: smoke | contract | load]"
user-invocable: true
disable-model-invocation: false
---El campo description es el más importante de los cinco. Debe describir dos cosas: qué hace el skill, y cuándo usarlo. El agente usa esto para decidir si el skill aplica a tu solicitud. Una descripción de una sola oración no es suficiente.
El campo argument-hint aparece como placeholder en el input de chat cuando invocas el skill como slash command. Guía al usuario sobre qué información adicional necesita proveer.
user-invocable: true (default) hace que el skill aparezca en el menú / de chat. disable-model-invocation: true hace que el skill solo se invoque manualmente y nunca por inferencia automática del modelo.
El cuerpo del SKILL.md son las instrucciones que Copilot seguirá. Escríbelas como si le estuvieras explicando el proceso a un desarrollador senior que no conoce tu proyecto específico:
# API Integration Testing
## Cuándo usar este skill
Cuando necesites crear tests de integración para endpoints REST, verificar
comportamiento de autenticación, o depurar un test existente que falla
intermitentemente en CI.
## Proceso de diseño de tests
Antes de escribir código, identifica:
1. El contrato esperado del endpoint (status codes, estructura de respuesta)
2. Los casos edge: payload vacío, auth inválida, rate limits
3. El orden de ejecución si hay dependencias entre tests
Para la estructura del test, usa el [template base](./test-template.http) incluido
en este skill.
## Depuración de fallos en CI
Cuando un test pasa localmente pero falla en CI:
1. Verifica variables de entorno — la mayoría de fallos ambientales son por configs
2. Revisa el orden de ejecución si hay estado compartido entre tests
3. Busca dependencias de tiempo: sleeps hardcodeados o timeouts insuficientes
## Ejemplos de referencia
Los [ejemplos de auth](./examples/auth-test.http) y [paginación](./examples/pagination-test.http)
demuestran los patrones más comunes del proyecto.El detalle que más marca la diferencia en el cuerpo: los pasos concretos. No “revisa las variables de entorno”. Sino “la mayoría de fallos ambientales en CI son por configs que no están en el secret manager del pipeline”. Esa especificidad es lo que convierte un skill en un colega con experiencia real.
Flujos donde un skill marca la diferencia
He visto tres categorías donde los skills producen el mayor retorno sobre el tiempo de configuración:
Testing y QA. Cada proyecto tiene sus propias convenciones de tests: qué directorio, qué runner, qué patrones de naming, qué fixtures. Un skill de testing puede incluir el template de test, los comandos exactos para ejecutar suite parcial o completa, y el proceso de depuración cuando algo falla. El agente sabe todo esto sin que lo repitas.
CI/CD y GitHub Actions. Debuggear un workflow que falla en CI requiere conocer la estructura específica de tu pipeline. Un skill de debugging de Actions puede incluir los comandos para ver logs, las razones más comunes de fallo en tu setup, y el proceso para reproducir el entorno localmente. Diferencia un skill así de una búsqueda de Stack Overflow en términos de velocidad.
Code review con criterios del equipo. Las reglas de review que tiene tu equipo rara vez están escritas de forma que Copilot las conozca por defecto. Un skill de code review puede incluir la checklist del equipo, los anti-patrones específicos de tu stack, y los criterios de aprobación que sí o sí deben cumplirse. El resultado es un review consistente que refleja realmente los estándares del equipo.
Para el caso de code review, un skill bien diseñado se vería así:
# Code Review Checklist
## Criterios no negociables
Rechaza cualquier PR que:
- Exponga credenciales o secrets en código fuente
- Tenga lógica de negocio en handlers HTTP (debe ir en use cases)
- No tenga tests para la ruta feliz del nuevo comportamiento
## Criterios de mejora (sugerencia, no bloqueo)
Sugiere cambios cuando:
- Una función tiene más de 40 líneas sin división de responsabilidad obvia
- Hay manejo de error duplicado que podría unificarse
- Un nombre de variable requiere más de 3 segundos para entenderLos controles de invocación
Los skills tienen dos mecanismos de invocación que conviene entender bien desde el inicio.
Invocación automática por el modelo. Por defecto, Copilot lee las descripciones de todos los skills instalados y decide cuáles cargar basándose en tu solicitud. No tienes que hacer nada. Si tu mensaje “corresponde” semánticamente a la descripción del skill, el agente lo carga en el contexto antes de responder.
Invocación manual como slash command. Escribe / en el input de chat y verás una lista de todos los skills disponibles como comandos. Puedes añadir contexto adicional después del nombre: /api-integration-testing para el endpoint de pagos en checkout es un prompt válido que invoca el skill y le pasa información específica.
La combinación de los campos de frontmatter controla el comportamiento:
user-invocable | disable-model-invocation | Resultado |
|---|---|---|
true (default) | false (default) | Aparece en / y el modelo lo carga automáticamente |
false | false | El modelo lo carga automáticamente, pero no aparece en / |
true | true | Solo aparece en /, el modelo nunca lo carga solo |
false | true | Deshabilitado efectivamente |
Para skills de conocimiento de fondo — convenciones de tu ORM, patrones de tu arquitectura — user-invocable: false es la configuración correcta. Para skills que requieren contexto específico del desarrollador — qué endpoint probar, qué PR revisar — disable-model-invocation: true tiene más sentido: así el agente no lo carga en tareas irrelevantes.
Gestionar y compartir skills
Los skills del proyecto viven en .github/skills/ y entran en el control de versiones con el código. Esto tiene una implicación que muchos equipos no consideran al principio: cuando alguien de DevOps mejora el skill de deployment, todos los desarrolladores obtienen la versión actualizada en su próximo git pull. Los skills evolucionan con el proyecto.
Los skills personales en ~/.copilot/skills/ son portables entre proyectos pero no se comparten. Útiles para flujos de trabajo personales — cómo prefieres hacer debugging, qué proceso sigues para una feature branch — que no son estándares del equipo pero te ahorran repetición.
Para equipos que quieren compartir skills sin incluirlos en el repositorio del proyecto, existe la ruta de extensiones de VS Code: una extensión puede contribuir skills usando el campo chatSkills en su package.json, apuntando a la carpeta con el SKILL.md.
La comunidad también ha construido una colección pública de skills en el repositorio github/awesome-copilot. Antes de crear un skill desde cero, vale la pena revisar si ya existe uno para tu caso de uso. El proceso para adoptarlo es simple: copia el directorio del skill a tu .github/skills/, revisa el SKILL.md para ajustarlo a tu proyecto, y ya tienes una capacidad reutilizable probada por la comunidad.
Lo que hace a un skill realmente útil
He visto skills que se usan en cada sesión y skills que se instalan y nunca se invocan. La diferencia no es el tema — es la calidad de la descripción y la especificidad de las instrucciones.
La descripción como contrato de carga. El modelo del nivel de discovery lee solo name y description. Si la descripción dice “skill para testing”, el agente no puede saber si aplica para unit tests, integration tests, tests de carga, o ninguno. Una descripción efectiva menciona el tipo de tarea, el contexto donde aplica, y las señales en la solicitud del usuario que deben activar el skill.
Una descripción débil:
description: "Skill para tests de integración"Una descripción efectiva:
description: >
Skill para crear, ejecutar y depurar tests de integración de APIs REST.
Se activa cuando el usuario menciona tests de integración, endpoint testing,
verificación de contratos HTTP, o depuración de tests que fallan en CI.
Incluye templates y ejemplos de tests de autenticación y paginación.Instrucciones con pasos concretos. El cuerpo del skill no es un README. Es un protocolo. Cada sección debería tener pasos numerados cuando el orden importa, criterios de decisión cuando hay opciones, y referencias a archivos de soporte cuando existen.
Archivos de soporte referenciados explícitamente. El modelo de carga progresiva solo accede a los archivos del skill directory que estén referenciados con links Markdown en el SKILL.md. Un template que no tiene link nunca se carga. Revisa que cada archivo de soporte que incluyes tenga su referencia correspondiente en el cuerpo.
Errores comunes que matan la utilidad del skill
El error que más he encontrado: el nombre del directorio no coincide con el campo name del frontmatter. El skill falla silenciosamente — no hay error, no hay warning. Simplemente no aparece y no se carga. Siempre verifica que el directorio my-skill/ tenga exactamente name: my-skill en el YAML.
El segundo error: duplicar en el skill lo que ya está en las custom instructions. Si tu proyecto tiene reglas de estilo en copilot-instructions.md, no las copies al skill de code review. El skill debe añadir comportamiento especializado, no repetir el contexto permanente. Duplicar eleva el costo de tokens sin agregar valor.
El tercer error: crear un skill demasiado genérico que compite con el conocimiento base del modelo. “Skill para escribir código limpio” no enseña nada que Copilot no sepa. Un skill agrega valor cuando captura conocimiento específico de tu proyecto, tu stack, o tu proceso. Cuanto más específico, más útil.
Un cuarto error que aparece en equipos grandes: skills sin mantener. Un skill que instruye sobre una versión antigua de tu API, o que referencia un script que ya no existe, produce comportamiento incorrecto. Los skills necesitan el mismo ciclo de mantenimiento que el código de pruebas: si el proyecto cambia, el skill cambia.
Un skill no es documentación. Es comportamiento empaquetado. La diferencia es que la documentación la lee un humano cuando la busca. Un skill la usa la IA cuando la necesita, sin que nadie se lo pida.
Artículos relacionados
Por relevancia
GitHub Copilot Agéntico: La Guía Definitiva para Controlarlo al Máximo
Domina GitHub Copilot en modo Agente, Plan y Ask. Aprende modelos, contexto, MCP, subagentes, instrucciones, ahorro de tokens y la configuración óptima para VS Code.
CLAUDE.md: Prepara tu Repositorio para IA y Reduce el Desperdicio de Tokens
Configura CLAUDE.md y archivos .claude/ para dar contexto preciso a agentes IA, reducir consumo de tokens y obtener respuestas más rápidas y precisas.
Automatizando tu vida con Go CLI: Guía profesional para crear herramientas de línea de comandos escalables
Una guía exhaustiva y paso a paso sobre cómo crear herramientas CLI escalables con Go 1.25.5: desde lo básico hasta proyectos empresariales complejos con flags, configuración, logging, y ejemplos prácticos para Windows y Linux.
CachyOS: Linux optimizado para desarrolladores modernos
CachyOS es una distribución Arch-based con kernel optimizado, scheduler BORE y herramientas listas para desarrollo. Aprende a configurarla y sacarle el máximo provecho.