Prompts para GitHub Copilot: comentarios, contexto y chat

Un desarrollador escribe // calcula el total encima de una función vacía. Copilot propone diez líneas que suman los precios, sin el IVA, sin el descuento de fidelidad, con números decimales donde el proyecto usa céntimos enteros. El código compila y es incorrecto, porque el comentario era la única información que se había dado.

A GitHub Copilot se le guía de tres maneras: lo que escribes en el archivo, lo que le pides en el chat y las reglas que fijas para todo el repositorio. Cada una tiene sus reflejos.

Las sugerencias en línea: el comentario es tu prompt

Cuando Copilot completa tu código mientras escribes, se basa en lo que rodea al cursor: el nombre de la función, los archivos abiertos, los comentarios. Un nombre explícito y un comentario que describa el comportamiento valen más que un largo preámbulo.

Compara estos dos comienzos de función.

// calcula el total
function total(articulos) {

// Total de una cesta en céntimos (enteros).
// Aplica el descuento de fidelidad del 5 % si cliente.fiel es verdadero,
// y después suma el IVA del 20 %. Redondeo al céntimo inferior.
// Cesta vacía: devuelve 0.
function totalCesta(articulos, cliente) {

El segundo indica la unidad, el orden de las operaciones, el redondeo y el caso límite. Copilot ya no tiene que adivinar. Si no estás seguro de la regla de negocio, no le pidas al código que la adivine por ti: escríbela primero.

También ayudan dos hábitos. Mantén abiertos los archivos que muestran cómo hace las cosas el proyecto (un módulo vecino, una prueba existente), porque sirven de ejemplos. Y revisa cada sugerencia antes de aceptarla, sobre todo las más largas: aceptar de golpe diez líneas que no has leído es escribir un código que nadie entiende.

El chat: elige lo que ve

En el chat, la calidad de la respuesta depende de lo que Copilot tenga delante. Según tu editor, puede ver el archivo abierto, el código que hayas seleccionado y los archivos que añadas explícitamente al contexto (en Visual Studio Code, por ejemplo, nombrándolos con #). Mira lo que ofrece tu interfaz, porque las opciones cambian de un editor a otro.

El reflejo útil es seleccionar el código afectado antes de hacer tu pregunta. Un ejemplo de petición para corregir un error:

La función seleccionada devuelve 0 para una cesta de dos artículos cuando el cliente es fiel. Sin descuento da el total correcto.

Busca la causa, explícala en dos frases y propón después la corrección más pequeña posible. No reescribas el resto de la función ni cambies su firma.

«La más pequeña posible» protege tu historial de commits. Sin este límite, la herramienta reorganiza de buen grado todo el archivo, y la revisión de código se convierte en una pesadilla.

Para las tareas habituales, existen comandos como /explain, /fix o /tests en el chat de varios editores. Evitan escribir de nuevo la misma petición, pero complétalos con una frase de restricciones. Por ejemplo, después de /tests:

Escribe las pruebas de la función seleccionada con el framework que ya se usa en la carpeta tests/. Cubre la cesta vacía, el cliente fiel, un precio a cero y un redondeo que cae entre dos céntimos. Una prueba por caso, con un nombre que describa el caso.

Ejecuta después las pruebas. Una prueba escrita por Copilot puede pasar porque verifica lo que el código hace, y no lo que debería hacer. Revisa los valores esperados uno por uno.

Las reglas del proyecto: un archivo de instrucciones

¿Estás harto de repetir «usamos céntimos enteros» y «ninguna dependencia nueva sin comentarlo»? GitHub permite depositar en el repositorio un archivo .github/copilot-instructions.md, escrito en Markdown y en lenguaje natural. Copilot lo lee para las peticiones relativas a ese repositorio. Su compatibilidad varía según el editor y la funcionalidad, así que consulta la documentación de GitHub para tu caso.

# Reglas del proyecto

- Los importes son enteros en céntimos. Nunca decimales para dinero.
- Pruebas con Vitest, en la carpeta tests/, un archivo por módulo.
- No añadas ninguna dependencia sin avisarme en la respuesta.
- Los mensajes de error destinados al usuario van en español, los nombres del código en inglés.

Mantén este archivo corto y verificable. Diez reglas precisas valen más que tres páginas de principios, y una regla que nunca relees acaba contradiciendo el código. El mismo razonamiento vale para las instrucciones de sistema y para las instrucciones de los agentes: escribe lo que un compañero nuevo debería saber el primer día.

Lo que Copilot no sabe

No conoce tus decisiones de arquitectura, tu historial de errores ni las reglas que están en la cabeza del equipo. También puede proponer una función de una biblioteca que no existe o una sintaxis de una versión antigua. Si una sugerencia usa una llamada que no reconoces, abre la documentación de la biblioteca antes de continuar.

Piensa también en el contenido de tu código: claves de acceso, contraseñas, datos de clientes. No los pongas en un comentario ni en el chat, y lee las condiciones de tu plan y las normas de tu empleador sobre el envío de código a un servicio externo. Las bases de la revisión y de la depuración con una IA están en nuestro artículo sobre prompts para desarrolladores.

Para probar hoy

Coge la próxima función que vayas a escribir. Antes de teclear la primera línea, escribe en un comentario su comportamiento completo: entradas, salidas, un caso límite. Mira lo que propone Copilot y corrige después el comentario, no el código, si la sugerencia se aleja de lo que querías.