Claude Skills vs Copilot Instructions: comparación

GitHub Copilot tiene más usuarios que cualquier otra herramienta de código con IA, así que su formato de personalización es probablemente la pieza de configuración de IA más desplegada que existe. Millones de repos llevan ahora un .github/copilot-instructions.md. Las skills de Claude llegaron después, se propagaron rápido, y resuelven un problema parecido de una forma distinta. Si usas ambas herramientas, o estás decidiendo cuál merece el esfuerzo de configuración de tu equipo, las diferencias importan más de lo que sugiere el marketing.

Llevamos SkillProof, donde instalamos skills de Claude en máquinas limpias y las probamos contra trabajo real antes de listarlas, así que nuestro sesgo está del lado de las skills y lo decimos por adelantado. También hemos visto cientos de archivos de instrucciones en ambos formatos triunfar y fallar, y los modos de fallo resultan ser casi idénticos. Esta comparación intenta ser justa con los dos.

Resumen

Las instrucciones personalizadas de Copilot son contexto siempre activo para código. Las skills de Claude son experiencia bajo demanda para cualquier tarea. Las instrucciones ganan en distribución de equipo e integración con el IDE; las skills ganan en lógica de activación, recursos incluidos, y todo lo que no sea código.

	Skills de Claude	Instrucciones personalizadas de Copilot
Mecanismo	SKILL.md con un campo de descripción; Claude carga el cuerpo cuando una tarea coincide	.github/copilot-instructions.md aplicado en todo el repo, más archivos *.instructions.md acotados por globs applyTo
Activación	Semántica: el modelo compara tu petición con la descripción	Siempre activa (archivo de repo) o coincidencia de ruta de archivo (globs)
Alcance	Cualquier tarea que maneje Claude: código, documentos, email, análisis	Código y superficies de Copilot: chat, revisión de código, agente de codificación
Portabilidad	Un formato en Claude Code, claude.ai, escritorio, API	Atada a Copilot; el soporte parcial varía según IDE y superficie
Recursos incluidos	Scripts, plantillas, archivos de referencia, cargados de forma perezosa	Solo texto markdown
Comportamiento de tokens	~100 tokens inactivos por skill; el cuerpo completo se carga al activarse	El archivo aplicable completo se adjunta en cada petición
Ecosistema	Miles de skills comunitarias, en su mayoría sin probar	Sobre todo archivos privados por repo; surgen listas "awesome", también sin probar

Si solo recuerdas una línea: las instrucciones describen tu base de código, las skills describen una capacidad. Son trabajos distintos, y la mayoría de equipos acaban queriendo ambos. Para asentar las bases del lado de las skills, nuestra guía completa de skills de Claude cubre el formato a fondo. Ambos formatos cambian cómo se comporta un modelo; conectar un modelo a datos externos es un eje diferente, cubierto en skills de Claude vs servidores MCP.

Qué son en realidad las instrucciones personalizadas de Copilot

El núcleo del sistema es un archivo: .github/copilot-instructions.md, registrado en el repositorio. Copilot Chat lo lee automáticamente y lo antepone a las peticiones en ese repo, en VS Code, Visual Studio, IDEs de JetBrains y github.com. El agente de codificación lo lee cuando trabaja en issues; la revisión de código de Copilot lo lee cuando revisa pull requests. Un archivo markdown, y cada superficie de Copilot que toca el repo se comporta en consecuencia.

En 2025 GitHub extendió el formato con archivos de instrucciones acotados: .github/instructions/*.instructions.md, cada uno con frontmatter que apunta a rutas de archivo.

---
applyTo: "src/api/**/*.ts"
---

All API route handlers return the ApiResponse<T> envelope.
Never throw inside a handler; return err() with a typed error code.

El glob hace lo que dice. Edita un archivo bajo src/api/, y estas instrucciones viajan con la petición. Edita un README, y no lo hacen. También hay instrucciones personales, configurables en tus ajustes de Copilot en github.com, e instrucciones de organización, que los administradores de Business y Enterprise pueden empujar a todos los miembros.

Las fortalezas aquí merecen una lectura justa, porque son reales.

Las instrucciones son nativas del repo. El archivo vive donde vive el código, y los cambios pasan por revisión de pull request como cualquier otra cosa. Cuando alguien actualiza la convención de manejo de errores, el diff es visible y todo el equipo lo recibe al hacer pull. Nada en el ecosistema de Claude distribuye configuración de equipo de forma tan limpia excepto las skills a nivel de proyecto en .claude/skills/, que toman prestado el mismo truco.

La segmentación por glob es precisa de una manera que la activación semántica no lo es. applyTo: "**/*.test.ts" se activa exactamente en esos archivos, siempre, sin ambigüedad. Una skill de Claude se activa cuando el modelo decide que la descripción coincide, lo cual es flexible y ocasionalmente equivocado. Para reglas que se corresponden con rutas de archivo, lo determinista gana a lo ingenioso.

Y el alcance es amplio. El mismo archivo gobierna el chat en vivo en el editor y las superficies asíncronas donde nadie está al mando: revisión de código y el agente de codificación. Esa integración de revisión en particular no tiene un equivalente directo en skills.

Lo que hacen las skills que las instrucciones no pueden

La diferencia estructural es la activación. Un archivo de instrucciones de Copilot está siempre en el prompt (o se adjunta por coincidencia de ruta). Una skill se queda en disco a un coste de unos 100 tokens de metadatos hasta que una tarea realmente coincide con su descripción, y entonces se carga el cuerpo completo. Esto es divulgación progresiva, y cambia lo que te puedes permitir escribir.

Un archivo de instrucciones tiene que mantenerse corto porque cada línea grava cada petición; la propia guía de GitHub dice que lo mantengas breve, y los archivos inflados se diluyen hasta que el modelo empieza a ignorar la parte central. El cuerpo de una skill puede llegar a miles de palabras, más archivos de referencia que se cargan solo cuando hace falta, porque nada de eso cuesta hasta el momento en que es relevante. Nuestra skill probada de Desarrollo Guiado por Pruebas lleva toda una disciplina rojo-verde-refactorización que sería absurdo inyectar en cada petición; como skill, se activa cuando construyes una función y se queda callada cuando preguntas qué hace una expresión regular.

Las skills también incluyen cosas que no son prosa. Una carpeta de skill puede llevar scripts ejecutables, plantillas de documentos, checklists y ejemplos resueltos; la skill DOCX incluye código que de verdad manipula el XML de Word. Las instrucciones de Copilot son texto markdown, y punto. Puedes describir un procedimiento; no puedes enviar la herramienta que lo ejecuta.

Luego está el límite que más importa para quienes no programan: las instrucciones de Copilot terminan donde termina el código. Configuran un asistente de codificación. Las skills de Claude configuran a Claude, que la gente usa para contratos, hojas de cálculo, emails en frío, notas de reuniones y análisis de datos. Una skill como Code Review Checklist se solapa con territorio de Copilot, pero la mitad de nuestro catálogo no tiene equivalente en Copilot ni siquiera en teoría. Si tu uso de IA se extiende más allá del IDE, los archivos de instrucciones nunca iban a cubrirlo.

Una nota de formato: las skills son portables en cada superficie de Claude. La misma carpeta funciona en Claude Code, se sube a claude.ai, y se adjunta a peticiones de API. Las instrucciones de Copilot son portables entre superficies de Copilot, lo cual es más estrecho, aunque la lenta convergencia de la industria hacia AGENTS.md (que Copilot también lee ahora) está empezando a difuminar los bordes.

Lo que hacen las instrucciones que las skills no pueden

La justicia va en ambos sentidos, y hay tres trabajos donde las instrucciones de Copilot son sencillamente la mejor herramienta.

El contexto de revisión de PR es el grande. La revisión de código de Copilot corre en la infraestructura de GitHub contra tus pull requests, y lee tu archivo de instrucciones cuando lo hace. Escribe "marca cualquier endpoint nuevo que carezca de límite de tasa" y el revisor lo aplica en cada PR, de cada colaborador, hayan configurado algo localmente o no. Claude no tiene un equivalente alojado que recoja tus skills automáticamente en cada pull request; tendrías que conectarlo tú mismo mediante CI.

La política a nivel de organización es la segunda. Un administrador de Copilot Enterprise puede fijar instrucciones que alcanzan a cada desarrollador de la organización sin que ninguno instale nada. Las skills de Claude se instalan por máquina o por repo. Para un equipo de plataforma que intenta imponer "nunca sugieras el cliente de auth obsoleto" en 400 ingenieros, empujar desde arriba gana a esperar que todos clonen los dotfiles correctos.

Tercero, el comportamiento nativo del IDE. Las instrucciones dan forma a Copilot dentro del editor donde la gente ya vive, sin ninguna herramienta separada que adoptar. La pregunta de activación nunca surge porque no hay activación: el contexto simplemente está ahí, en cada petición. Para hechos siempre verdaderos sobre una base de código, lo siempre activo es el comportamiento correcto, que es la misma razón por la que Claude Code tiene CLAUDE.md junto a las skills. Hicimos el argumento paralelo en skills de Claude vs reglas de Cursor: toda herramienta acaba necesitando tanto una capa siempre cargada como una capa bajo demanda, y las herramientas difieren sobre todo en qué capa han construido bien.

Convertir entre los dos formatos

Los formatos están lo bastante cerca como para que migrar sea sobre todo reorganizar. Aquí va un bloque con forma real de un copilot-instructions.md:

## Error handling

- All service functions return Result<T, AppError>, never throw.
- Map external errors to AppError codes in the adapter layer only.
- Log with the request ID from context; never log raw error objects
  from third-party SDKs, they can contain tokens.
- New AppError codes go in errors/codes.ts with a doc comment.

Como skill, el mismo conocimiento gana una condición de activación y espacio para crecer:

---
name: error-handling-conventions
description: Applies our Result-based error handling conventions when
  writing or reviewing service code, adding error paths, or creating
  new AppError codes. Use when the user works on error handling,
  exceptions, or failure cases in the services layer.
---

# Error handling conventions

When writing or modifying service-layer code:

1. Service functions return Result<T, AppError>. Never throw from
   a service function. If you find existing code that throws,
   flag it, do not silently rewrite it.
2. Map external errors to AppError codes in the adapter layer only.
   If a service needs a new mapping, it belongs in the adapter.
3. Log with the request ID from context. Never log raw error
   objects from third-party SDKs; they can contain tokens.
4. New AppError codes go in errors/codes.ts with a doc comment
   explaining when the code fires.

For retry and timeout conventions, see [resilience.md](resilience.md).

Fíjate en lo que cambió. La descripción ahora lleva frases de activación, la parte que los autores más se equivocan; las descripciones vagas nunca se activan. El cuerpo ganó restricciones negativas ("márcalo, no lo reescribas en silencio") que un archivo siempre activo no puede permitirse en tokens. Y la última línea apunta a un archivo de referencia que se carga solo cuando surgen los reintentos.

La dirección inversa es un ejercicio de compresión. Toma el cuerpo de una skill, conserva las reglas que se aplican a cada petición en las rutas objetivo, recorta los procedimientos y los casos límite, y suelta el resultado en un archivo acotado:

---
applyTo: "src/services/**/*.ts"
---

Service functions return Result<T, AppError> and never throw.
Error mapping lives in the adapter layer. Log with the request ID;
never log raw third-party error objects.

Lo que pierdes yendo por este camino: la carga condicional y el material de referencia incluido. Lo que ganas: las reglas ahora también gobiernan la revisión de código de Copilot en cada PR que toque src/services/. Ninguno de los dos intercambios está mal. Son colocaciones distintas del mismo conocimiento.

Ejecutar Claude Code y Copilot en paralelo

Muchos equipos nunca eligen, y la división del trabajo que surge es lo bastante consistente como para describirla.

Copilot maneja la capa dentro del editor más la revisión de PR, configurada por archivos de instrucciones que describen la base de código. Claude Code maneja la capa de sesión: funciones multiarchivo, refactorizaciones, investigaciones de depuración, y el trabajo circundante como changelogs y documentos de migración, configurado por CLAUDE.md para hechos del repo y skills para capacidades. El solapamiento es más pequeño de lo que parece, porque las herramientas se sitúan en altitudes distintas. El autocompletado quiere reglas cortas siempre verdaderas; un agente ejecutando una tarea de 40 minutos quiere procedimientos.

La configuración práctica que vemos funcionar: mantener .github/copilot-instructions.md y CLAUDE.md como hermanos que dicen lo mismo en el dialecto de cada herramienta (algunos equipos generan ambos a partir de un archivo fuente), usar globs applyTo para reglas de código acotadas por ruta, y usar skills para todo lo procedimental. Una skill de Git Workflow que rige tu disciplina de ramas y commits no tiene una expresión útil como instrucción de Copilot, y una regla de "usamos pnpm, no npm" no tiene por qué ser una skill. Si estás construyendo el lado Claude de esto desde cero, nuestro ranking de mejores skills de código está ordenado por puntuación probada.

El límite tampoco es fijo. Los equipos que empiezan con Copilot para autocompletados tienden a cederle más trabajo agéntico a Claude Code con el tiempo, no porque las instrucciones fallen, sino porque una herramienta de sesión con skills rinde más en tareas largas. Lo contrario también pasa: equipos volcados en Claude Code mantienen Copilot de todos modos porque la integración de revisión de PR es así de conveniente. Trata la división como un valor por defecto, no como una doctrina.

Una advertencia de nuestras pruebas: la duplicación se desalinea. Cuando el archivo de Copilot dice que los servicios nunca lanzan excepciones y la skill dice que los servicios sí pueden lanzarlas en la capa de adaptador, tienes dos asistentes aplicando con confianza reglas distintas. Quien sea dueño de la convención debería ser dueño de ambos archivos en el mismo PR.

Tampoco nadie prueba los archivos de instrucciones

Aquí está la simetría incómoda. Construimos SkillProof porque alrededor de la mitad de las skills comunitarias de Claude que instalamos fallan al primer intento, un patrón que documentamos en por qué la mitad de las skills de Claude no funcionan. Los dos modos de fallo dominantes son instalaciones que no funcionan siguiendo las propias instrucciones del README y descripciones demasiado vagas para activarse alguna vez.

Las instrucciones de Copilot tienen la misma enfermedad con síntomas distintos. Las listas awesome-copilot y las colecciones de archivos de instrucciones que se propagan por GitHub son el mismo markdown sin probar: archivos copiados de un post de blog a .github/, nunca verificados contra el comportamiento real del modelo. Los modos de fallo se corresponden casi uno a uno. Una descripción vaga de skill significa que la skill nunca se activa; un archivo de instrucciones inflado significa que las reglas se diluyen hasta que el modelo las ignora. Un cuerpo de skill que repite el comportamiento por defecto del modelo no añade nada; un archivo de instrucciones lleno de "escribe código limpio y bien documentado" no añade nada. En ambos ecosistemas, la existencia del archivo se confunde con su función.

La diferencia es que el fallo de un archivo de instrucciones es más silencioso. Una skill que nunca se activa es al menos detectablemente inerte. Un archivo de instrucciones siempre está técnicamente "aplicado", así que los equipos asumen que funciona, y nadie hace la comparación con y sin que mostraría si cambia algo el resultado. Esa comparación es exactamente nuestro criterio de resultado para las skills, y es la prueba que te sugeriríamos también para tu archivo de Copilot: toma tres tareas reales, ejecútalas con el archivo de instrucciones presente y ausente, y compara los resultados. Si no puedes distinguir cuál es cuál, has estado pagando tokens por un placebo.

Preguntas frecuentes

¿Puede GitHub Copilot usar skills de Claude?

No. Las skills son un formato del lado de Claude que leen Claude Code, claude.ai y la API. Copilot no puede cargar un SKILL.md, aunque Copilot ofrezca modelos de Claude como backend; el modelo es intercambiable, la capa de configuración no. El conocimiento dentro de una skill normalmente se convierte en un archivo de instrucciones, menos la carga condicional y cualquier script incluido.

¿Funcionan las skills de Claude junto a instrucciones de repositorio como copilot-instructions.md?

Coexisten sin conflicto porque cada herramienta lee solo sus propios archivos. Claude Code ignora .github/copilot-instructions.md, y Copilot ignora .claude/skills/. El riesgo no es una colisión, es el desajuste: dos archivos que codifican la misma convención acabarán en desacuerdo a menos que se mantengan juntos.

¿Cuál es mejor para imponer estándares de código en equipo?

Para reglas que se corresponden con rutas de archivo y necesitan llegar a cada colaborador, las instrucciones de Copilot con globs applyTo, porque también se aplican a la revisión de código de Copilot en los PR. Para estándares procedimentales, como cómo ejecutar una migración, las skills, porque pueden guardar procedimientos largos y cargarlos solo cuando son relevantes. La mayoría de documentos de estándares contienen ambos tipos y conviene dividirlos así.

¿Son las instrucciones de Copilot más baratas en tokens que las skills?

Normalmente lo contrario. Un archivo de instrucciones aplicable se adjunta a cada petición, así que un archivo de 1.500 tokens cuesta 1.500 tokens por interacción sea o no relevante. Una skill cuesta unos 100 tokens inactiva y carga su cuerpo solo al coincidir. Lo siempre activo vale la pena cuando las reglas se aplican de verdad a cada petición, por eso los archivos de instrucciones cortos ganan a los largos.

¿Debería convertir mi copilot-instructions.md en skills si me paso a Claude Code?

Divídelo en vez de convertirlo. Los hechos siempre verdaderos sobre el repo, sus comandos de build y convenciones, van en CLAUDE.md, que es el análogo más cercano. Las secciones procedimentales, cualquier cosa que se lea como "al hacer X, sigue estos pasos", van en skills para que se carguen bajo demanda. Una conversión directa suele producir o bien un CLAUDE.md inflado o skills que se activan con todo.