Buenas prácticas para formular prompts en GitHub Copilot

GitHub Copilot ofrece ayuda de programación más útil cuando la descripción de la tarea explica el problema, el alcance, las restricciones y la prueba de éxito. Un prompt corto puede funcionar para completar código local. Un cambio en el repositorio necesita la misma claridad que una incidencia bien redactada.

La superficie del producto importa: la documentación actual de GitHub describe instrucciones para todo el repositorio, instrucciones específicas por ruta, instrucciones para agentes y archivos de prompts reutilizables, aunque la compatibilidad varía según la funcionalidad y el IDE. Usa las herramientas disponibles en tu entorno, pero mantén explícita la solicitud subyacente.

Da a la finalización de código un contrato local

Para una función pequeña, el nombre, los tipos y las pruebas que la rodean suelen bastar. Añade el comportamiento que es fácil resolver de forma sutilmente incorrecta:

Implementa un analizador para la cabecera retry-after.

Devuelve milisegundos para segundos o una fecha HTTP válida. Devuelve null para
un valor ausente, negativo o no válido. No lances una excepción desde una ruta
de error de respuesta. Añade pruebas guiadas por tablas para segundos, una fecha
futura, una fecha pasada y una entrada con formato incorrecto.

El contrato guía la finalización sin requerir una larga explicación de la arquitectura.

Describe el trabajo de pruebas como comportamiento

Evita:

Escribe pruebas para el hook de preferencias.

Usa:

Añade pruebas para el hook de preferencias usando las convenciones de pruebas
existentes.

Verifica que el estado de carga inicial no redirige, una lectura correcta expone
las preferencias guardadas, una actualización escribe el objeto de preferencias
completo de forma atómica y una actualización fallida conserva el valor visible
anterior.

Usa comportamiento público en vez de recuentos de llamadas a funciones internas.
Incluye la regresión que fallaría con el error informado.

El asistente ahora tiene un contrato orientado a la persona usuaria, incluido un caso negativo importante.

Da a los prompts de refactorización reglas para conservar el comportamiento

Las sugerencias de código pueden crear una abstracción local ordenada y perder un detalle público. Incluye la conservación en la solicitud:

Extrae la presentación de estado repetida de estas dos tarjetas.

Conserva los props actuales, las etiquetas visibles, los nombres de eventos de
analítica, el foco del teclado y el diseño móvil. Limita los cambios a esta
funcionalidad y sus pruebas directas.

Antes de editar, enumera el comportamiento repetido y las diferencias que deben
mantenerse separadas. No conviertas esto en un componente compartido del sistema
de diseño a menos que el componente existente no pueda representar el resultado.

Si no puedes nombrar el comportamiento que se debe conservar, pide primero a Copilot que explique el contrato actual y los sitios de llamada.

Depura con síntomas y evidencia

Síntoma: La página de búsqueda muestra resultados obsoletos después de que una
persona cambia los filtros.

Esperado: La selección de filtro más reciente controla los resultados mostrados.
Observado: Una solicitud anterior más lenta puede sobrescribir una respuesta más
reciente.

Código relevante: La interfaz de filtros, el hook de solicitudes y el renderizador
de resultados. Cambio reciente: se añadieron reintentos de solicitudes.

Primero describe el ciclo de vida de la solicitud y las hipótesis en competencia.
Indica qué registros o tiempo de prueba demostrarían cada una. Después propone la
corrección más pequeña y cobertura de regresión. No reemplaces la capa de datos
sin evidencia.

Esto evita que una respuesta genérica de “corrige la condición de carrera” se amplíe hasta una migración innecesaria de la gestión de estado.

Usa instrucciones del repositorio para el contexto estable

Las reglas estables deben vivir con el proyecto, cuando sea compatible:

cómo ejecutar pruebas y formateo;
restricciones de despliegue;
configuraciones regionales o plataformas compatibles;
APIs públicas que deben seguir siendo compatibles;
rutas en las que importan las revisiones de seguridad o accesibilidad.

La documentación de GitHub describe instrucciones personalizadas a nivel de repositorio y archivos de instrucciones más específicos. Mantén esas instrucciones breves, precisas y acotadas a convenciones duraderas. Incluye los detalles de la incidencia actual —síntomas, resultado y criterios de aceptación— en el propio prompt.

Solicita documentación basada en el código

Actualiza la guía de solución de problemas de despliegue después de la nueva
comprobación del entorno.

Verifica cada comando y variable de entorno frente al repositorio. Explica la
señal de éxito, la señal de fallo habitual y la siguiente acción segura. Mantén
los secretos fuera de los ejemplos. Añade enlaces al runbook operativo existente
en lugar de duplicarlo.

La frase “verifica frente al repositorio” importa. Le indica a Copilot que una documentación precisa es una tarea de lectura de código, no de generación de texto.

Termina cada prompt importante con criterios de aceptación

Usa una línea de meta que otra persona pueda revisar:

Terminado significa:
- el comportamiento informado por la persona usuaria cambia como se describe;
- el comportamiento protegido sigue sin cambios;
- las pruebas enfocadas demuestran las rutas nueva y anterior;
- la comprobación de tipos y el comando de lint pertinente pasan;
- el diff no contiene limpieza no relacionada.

Para la estructura general de un prompt, lee cómo escribir mejores prompts para IA. Para patrones específicos de cada tarea, continúa con ingeniería de prompts para desarrolladores y evita después los modos de fallo de errores de los asistentes de programación con IA y cómo evitarlos.

Cuando una tarea de programación incluye scripts, salida de comandos o una reproducción en la terminal, valídala en lugar de describirla de memoria. Practica el flujo de trabajo de línea de comandos en tu navegador antes de convertirlo en un prompt o una prueba.