El prompt más corto no es el más eficiente. Es el que más tiempo me hace perder después, revisando un cambio que técnicamente responde a lo que pedí pero no encaja con el resto del proyecto porque dejé que Cursor adivinara demasiado.
Con el tiempo he llegado a una estructura que uso casi siempre, y que reduce mucho ese tipo de desajuste.
El qué, antes que nada, pero acotado
Empiezo siempre con la tarea concreta, no con contexto de fondo. "Añade validación al formulario de registro para que el email no pueda estar vacío" es mejor prompt inicial que un párrafo explicando primero toda la arquitectura del proyecto. El contexto viene después, solo si hace falta, no por delante ocupando espacio antes de que el modelo sepa qué le estás pidiendo.
Qué NO debe tocar, no solo qué sí
Esta es la parte que más gente se salta y la que más evita cambios no deseados. Si hay archivos, funciones o comportamientos que deben quedar exactamente igual, lo digo explícitamente: "no cambies la firma de esta función, otros módulos dependen de ella tal cual está". Sin esa frase, un cambio "razonable" desde el punto de vista aislado del prompt puede romper algo que no se mencionó porque no hacía falta mencionarlo, hasta que dejó de ser así.
El patrón que ya existe en el proyecto, no una descripción genérica
Si ya tengo una función o componente que resuelve algo parecido, referencio ese archivo concreto en vez de describir el patrón en abstracto: "sigue el mismo patrón que usa el archivo X para manejar errores de red". Esto reduce muchísimo la varianza del resultado, porque Cursor no tiene que inferir cuál de las mil formas válidas de hacer algo es la que uso yo en este proyecto en concreto.
El criterio de terminado, explícito
"Termina cuando los tests existentes sigan pasando y hayas añadido al menos un test para el caso nuevo" es un criterio verificable. "Que quede bien" no lo es. Cuanto más verificable el criterio de terminado, menos tengo que negociar después sobre si el resultado está completo o no.
Lo que dejo fuera a propósito
No incluyo contexto que no es relevante para esa tarea concreta, aunque lo tenga a mano. Meter todo el historial de decisiones del proyecto en cada prompt no ayuda, diluye lo importante entre ruido que no aplica a este cambio. El contexto correcto no es "todo lo que sé del proyecto", es lo mínimo necesario para que esta tarea concreta salga bien.
Un prompt tipo, resumido
Tarea concreta primero. Qué no debe cambiar, si aplica. Referencia a un patrón ya existente en el repo, si lo hay. Criterio de terminado verificable. En ese orden, y sin rellenar con contexto que no cambia el resultado.
La recomendación
Un prompt más largo no es un prompt mejor. Es un prompt mejor cuando cada frase de más elimina una ambigüedad concreta que, de haberla dejado, te habría costado revisar y corregir después. Si una frase no elimina ninguna ambigüedad real, sobra, por muy completa que parezca la instrucción.
Relacionado: Cómo escribir un prompt de sistema que no se rompe