El pasado mes de marzo, con la SQLCon 2026 de Atlanta, vimos varias novedades alrededor de GitHub Copilot para quienes trabajamos con SQL Server. Microsoft aprovechó el evento para reforzar dos frentes que, desde fuera, parecen muy parecidos: SSMS 22, ya con Copilot en disponibilidad general, y la extensión MSSQL de VS Code, que sigue creciendo con diseñador de esquemas, agent mode y otras superficies más cercanas al flujo de desarrollo. La mayoría de titulares se quedaron en la parte fácil, esa de “Copilot llega a todas partes”. Lo interesante empieza cuando uno rasca un poco y descubre que no, que no está llegando igual a todas partes, ni con la misma idea detrás.
En este artículo quiero centrarme en dos mecanismos concretos, porque ahí está la diferencia de verdad: las instrucciones personalizadas y las skills. Son dos formas distintas de decirle a Copilot cómo queremos que piense, qué contexto debe respetar y hasta dónde puede dejar de improvisar. Que ya sabemos que improvisar es una habilidad preciosa en jazz, pero en bases de datos suele costar bastante más.
Antes de entrar en el detalle, conviene empezar por lo que debería ser la base de cualquier uso serio de Copilot con SQL Server: las instrucciones.
Instrucciones personalizadas: donde de verdad empieza el contexto
Cuando hablo de instrucciones personalizadas no me refiero a un prompt largo y dramático que uno pega en el chat cada lunes. Me refiero a contexto persistente, reutilizable y con cierta autoridad. En VS Code, la documentación de Copilot lo plantea como un mecanismo para definir reglas comunes en archivos Markdown y hacer que se apliquen automáticamente a las peticiones de chat del workspace o del repositorio. En SSMS existe también ese modelo clásico de instrucciones de usuario y de repositorio, con copilot-instructions.md a nivel personal y .github/copilot-instructions.md a nivel de repositorio. Hasta aquí, ambos mundos hablan un idioma bastante parecido.
Un ejemplo simple de ese tipo de fichero sería algo así:
# Copilot Instructions
Genera T-SQL compatible con SQL Server.
Evita SELECT * salvo que se pida de forma explícita.
Usa esquema explícito en tablas y vistas.
Cuando propongas cambios de esquema, incluye siempre clave primaria.
Si hay varias opciones válidas, explica cuál eliges y por qué.Este tipo de instrucciones funciona muy bien para marcar estilo, guardarraíles y convenciones. En otras palabras, sirve para decirle a Copilot cómo queremos que se comporte. Y eso ya ayuda bastante, sobre todo en equipos donde todavía hay quien cree que una tabla llamada Tbl_Clientes2_Final transmite serenidad arquitectónica. En VS Code, además, estas instrucciones pueden generarse con /init o /create-instructions, se aplican automáticamente al chat y tienen una prioridad definida entre nivel personal, repositorio y organización.
Instrucciones personalizadas adaptadas a SQL Server
Ahora bien, SSMS añade una capa bastante más interesante, y aquí es donde esto deja de ser genérico. Además de las instrucciones de usuario y repositorio, SSMS incorpora database instructions, que viven dentro de la propia base de datos como metadatos basados en propiedades extendidas y que aplican para todo el que consulte la base de datos con SSMS. Microsoft documenta dos nombres concretos: CONSTITUTION.md, para reglas globales de la base, y AGENTS.md, para contexto específico de objetos. No estamos hablando ya de “me gusta que indentes así”. Estamos hablando de “esta base funciona así, estas reglas de negocio no son negociables y esta tabla significa esto, aunque por su nombre nadie lo diría”.
CONSTITUTION.md es, en la práctica, una constitución de base de datos. Sirve para fijar normas generales y semánticas que deben aplicarse a cualquier interacción de Copilot con esa base. Un ejemplo razonable podría ser este:
Ese fichero no mejora el estilo. Mejora el entendimiento. Y esa diferencia es crucial. Cuando Copilot genera T-SQL sin contexto semántico, lo único que hace es adivinar con bastante seguridad en sí mismo. Cuando trabaja con una constitución pegada a la base, al menos tiene una oportunidad real de no inventarse la lógica del negocio sobre la marcha. Que parece una exigencia modesta, pero viendo algunas demos de IA últimamente casi suena revolucionaria.
AGENTS.md, por su parte, baja un nivel más y se aplica a objetos concretos. Ahí es donde tiene sentido documentar lo que jamás se deduce mirando nombres de columnas. Por ejemplo:
Este ejemplo es simple, pero deja ver lo importante: en SSMS el contexto puede residir dentro del dato y no solo alrededor del dato. Para mí, esa es la mejor idea que ha aparecido en esta historia. No porque sea vistosa, sino precisamente porque no lo es. Es una solución pensada por alguien que ha entendido que en SQL Server el problema rara vez es escribir una consulta; el problema es saber qué consulta tiene sentido escribir.
Una vez aclarado esto, toca la segunda pieza del artículo. Porque si las instrucciones sirven para fijar normas, las skills juegan una partida distinta.
Skills: capacidad reutilizable, no autoridad semántica
Las skills, tal como las documenta VS Code, no son instrucciones generales, sino capacidades especializadas. Hay que decir que las Skills no son exclusivas de Copilot, son un estandar de la industria presente en la mayoría de IAs generativas comerciales (Claude, OpenAI, Gemini o Github Copilot, por ejemplo). Sin embargo, a fecha de redaccion de este artículo, en SSMS no las tenemos disponibles.
Sobre su uso, la propia documentación de Agent Skills las contrapone a las custom instructions de forma bastante clara: las instrucciones sirven para definir estándares y guías; las skills sirven para enseñar flujos, incluir scripts, ejemplos y recursos, y cargarse bajo demanda cuando el agente las considera relevantes. También son portables entre VS Code, Copilot CLI y otros entornos compatibles, mientras que las custom instructions son más específicas del ecosistema de VS Code y GitHub.
Dicho sin envoltorio comercial, una instrucción le dice a Copilot “compórtate así”; una skill le dice “cuando toque esto, trabaja de esta manera”. Es una diferencia importante, porque mucha gente intenta usar las skills como si fueran una constitución universal y luego se lleva la sorpresa correspondiente. No están pensadas para eso. Están pensadas para encapsular un procedimiento. La herramienta es buena. El malentendido también.
Un ejemplo sencillo de skill para SQL podría ser este:
—
name: sql-governance-check
description: Check the instructions repository before proposing SQL changes
—
Antes de proponer cambios de esquema o T-SQL:
lee `.github/copilot-instructions.md` si existe;
lee `AGENTS.md` del directorio actual o de la raíz;
resume las reglas aplicables;
no propongas SELECT *;
si una tabla nueva no tiene PK, indícalo y corrígelo.Esto tiene bastante sentido en VS Code. Puede servir para reforzar disciplina antes de tocar esquema, para revisar convenciones o para encadenar pequeñas validaciones. Incluso puede ser muy útil en un equipo de desarrollo que trabaja con SQL y .NET en el mismo workspace. Pero conviene no pedirle a una skill lo que no promete. Una skill no reemplaza una constitución de base de datos, porque no vive en la base ni tiene ese nivel de anclaje semántico. Puede ayudar a leer instrucciones, empujar un flujo y mejorar bastante el resultado. Lo que no hace es convertir el contexto del repositorio en contexto nativo del dato.
Además, la propia documentación es bastante explícita con el alcance: las custom instructions se aplican siempre o por patrón; las skills se cargan para tareas específicas y bajo demanda. Esa diferencia basta para entender por qué una skill no es el sitio correcto para definir autoridad continua. Sirve para procedimiento. No sirve como sustituto serio de una política persistente. Y eso, en entornos con varias bases, varios dominios y objetos sensibles, importa bastante más de lo que algunos quieren admitir.
Llegados aquí, la pregunta lógica sale sola. Si las instrucciones personalizadas son tan útiles y las skills aportan tanto en VS Code, ¿por qué no tenemos exactamente lo mismo en ambos sitios?
¿Por qué no están en ambos sitios?
Como acabamos de ver en SSMS tenemos las database instructions y en VS Code las Skills pero no al revés. ¿Por qué?
La respuesta corta es que SSMS y VS Code no están diseñados para obedecer al mismo centro de gravedad y por tanto llevan caminos de desarrollo distintos. SSMS parte de la conexión activa, del esquema y de la base de datos como lugar natural del contexto. La documentación de Copilot en SSMS insiste precisamente en esa idea, entiende la conexión, el esquema y el trabajo que estamos haciendo sobre la base. Por eso tiene sentido que Microsoft haya añadido database instructions y que las haya apoyado en metadatos dentro de SQL Server. Si el centro es la base, el contexto tiene que poder vivir ahí.
VS Code, en cambio, está pensado para algo más amplio. La documentación de la extensión MSSQL lo describe como una experiencia para desarrolladores modernos, arquitectos, ingenieros de base de datos y escenarios donde SQL convive con ORM, APIs, generación de código, query builder, schema designer y agent mode. Incluso el diseñador de esquemas con Copilot abre una sesión de chat “scoped to the current schema context”, con cambios reflejados en diagrama, T-SQL y diff. Todo eso encaja muy bien con un entorno cuyo centro no es la base aislada, sino el proyecto completo.
Y aquí aparece la diferencia que, a mi juicio, merece un palito para las cabezas pensantes de Redmon. Si un desarrollador usa VS Code para todo, desde SQL hasta .NET, puede centralizar reglas del equipo en el repositorio y montar skills para reforzar flujos. Muy bien. Pero no puede apoyarse en un mecanismo nativo equivalente al de SSMS para adaptar contexto por base de datos o por tabla desde dentro del propio SQL Server. Tiene que definirlo todo en el mismo sitio o trocearlo artificialmente por carpetas, workspaces y archivos. Funciona, sí. Pero obliga a administrar el conocimiento desde fuera de donde ese conocimiento realmente vive. Y eso, en bases de datos con semánticas distintas, no es una limitación teórica. Es una limitación bastante práctica.
En otras palabras, SSMS ha resuelto mejor la pregunta “¿dónde debería vivir el contexto de una base de datos?”. VS Code ha resuelto mejor la pregunta “¿cómo integro Copilot en un flujo de desarrollo más amplio?”. Las dos respuestas tienen sentido. Lo que no tiene sentido es fingir que son intercambiables. Porque no lo son. Y cuando uno intenta usarlas como si lo fueran, acaba pidiéndole a una skill que haga de constitución o a un fichero de repositorio que actúe como conocimiento de tabla.
Ya con esto, la conclusión debería ser simple. Y como el tema da para pedir más de lo que hay hoy, la cierro con una pequeña lista de deseos.
Conclusión: lo que me gustaría ver a continuación
Mi sensación a día de hoy es bastante clara. Las instrucciones personalizadas de base de datos son el mecanismo correcto para fijar normas persistentes. Las skills son el mecanismo correcto para empaquetar capacidades y flujos reutilizables. El problema no está en ninguna de las dos ideas. El problema está en que cada producto ha desarrollado solo la mitad que más le convenía. SSMS ha entendido muy bien el valor del contexto dentro de la base, pero no ofrece el ecosistema de capacidades componibles que sí vemos en VS Code. VS Code, por su parte, tiene una historia mucho más rica en skills, agentes y superficies de desarrollo, pero sigue sin bajar el contexto al nivel de la base y del objeto con la naturalidad que sí ofrece SSMS.
Mi primera petición sería bastante obvia: que VS Code pudiera consumir de forma nativa una constitución y agentes definidos dentro de SQL Server, no solo desde el repositorio. La segunda, que el diseñador de esquemas respetara desde el primer minuto ese contexto y no solo el esquema cargado. La tercera, que SSMS heredara una idea de skills más seria para procedimientos repetibles y no se quedara únicamente en la parte de instrucciones. Y la cuarta, quizá la más importante, que Microsoft dejara de presentar todo esto como si fuera el mismo Copilot en dos ventanas distintas, porque no lo es y ya va siendo hora de dejar de tratar a los usuarios técnicos como si no supieran distinguir entre contexto, estilo y gobierno.
Mientras eso llega, yo lo resumiría así: si quiero que Copilot respete mejor el dato, hoy miro a SSMS; si quiero que Copilot me acompañe mejor en el proyecto, hoy miro a VS Code. Y entre una cosa y otra, lo que seguimos necesitando es exactamente lo mismo que antes de la IA: contexto bueno, reglas claras y menos fe ciega en herramientas que todavía confunden velocidad con criterio.
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
