15 prompts en español compatibles con GitHub Copilot
Con Copilot Chat el resultado depende del contexto que le pases. "Arréglalo" devuelve parches; un prompt con criterios devuelve trabajo de senior.
GitHub Copilot cambió cómo se escribe código, pero el autocompletado es solo la mitad de la historia: con Copilot Chat, la calidad de lo que obtienes depende de cómo se lo pides. Un "arréglalo" devuelve parches; un prompt estructurado con contexto, restricciones y criterios devuelve soluciones de ingeniero senior.
Aquí encuentras prompts técnicos en español para GitHub Copilot: revisión de código con estándares profesionales, diseño de arquitectura y esquemas de base de datos, generación de tests, debugging sistemático y preparación de entrevistas técnicas. Están escritos por desarrolladores y probados en proyectos reales, con placeholders para tu stack concreto.
La mayoría funcionan igual de bien en Claude, ChatGPT o DeepSeek si programas con otro copiloto — el buen prompting técnico es transferible. El Kit del desarrollador reúne los mejores en un solo pack con descuento.
Empieza por los prompts gratis, aprende a escribir los tuyos con la guía de prompt engineering en español o, si ya creas buenos prompts para GitHub Copilot, véndelos aquí y quédate el 85%.
Copilot Chat permite referenciar archivos concretos del proyecto. Dale los dos o tres que importan para la tarea. Con demasiado contexto se diluye y responde con generalidades; con demasiado poco, se inventa cómo es tu código.
Una revisión sin criterios devuelve comentarios de estilo. Dile qué te preocupa: condiciones de carrera, gestión de errores, casos límite, rendimiento en listas grandes, seguridad de la entrada. La lista de criterios es el prompt.
Si solo pides la corrección, obtienes un diff que aceptas sin entender. Pedir que explique qué fallaba y qué alternativa descartó convierte cada respuesta en revisión y no en autocompletado de lujo — y te permite detectar cuándo se ha equivocado.
Pedirle primero los casos de prueba, incluyendo los límite, y solo después la implementación, da mejor código y te deja con una red de seguridad. Además es la forma más rápida de descubrir que no había entendido el requisito.
Revisa {ARCHIVO O FUNCIÓN} como lo haría un ingeniero senior de mi
equipo antes de aprobar el pull request.
Revisa específicamente:
· Casos límite no contemplados (entrada vacía, nula, colecciones enormes)
· Gestión de errores: qué pasa si {DEPENDENCIA EXTERNA} falla o tarda
· Condiciones de carrera o estado compartido
· Seguridad de los datos que entran desde fuera
Para cada hallazgo dame: qué falla, en qué caso concreto se rompe, y la
corrección propuesta con una frase de por qué.
Ordena por gravedad real. Si algo es cuestión de estilo y no de
corrección, dilo aparte al final o no lo menciones.La última instrucción es la que hace la revisión utilizable. Sin ella, los fallos de verdad aparecen mezclados con quince sugerencias de nombres de variable, y en esa lista todo pesa lo mismo — que es como no revisar.
Tiene un nivel gratuito con límite mensual de completados y mensajes de chat, además de acceso gratuito para estudiantes, docentes y mantenedores de proyectos de código abierto verificados. Los planes de pago quitan esos límites.
En Visual Studio Code, Visual Studio, los IDEs de JetBrains, Neovim y también desde la web de GitHub. Los prompts de esta página son de Chat, así que funcionan en cualquiera de ellos: no dependen del editor.
En los planes de empresa el código no se usa para entrenar modelos, y en los individuales existe un ajuste para desactivarlo. Si trabajas con código de cliente bajo acuerdo de confidencialidad, revisa la configuración de tu organización antes de empezar.
Sí, entiende las instrucciones en español sin problema y te responde en español si se lo pides. Los identificadores, los mensajes de error y la terminología técnica seguirán en inglés, que es justo lo que quieres en un proyecto real.