Guía para formular prompts en Cursor AI

Cuando una IA puede inspeccionar un repositorio, un prompt mejor suele ser más acotado, no más amplio. Proporciona a Cursor los archivos, límites, restricciones y validación que importan, y pídele que analice el área relevante antes de editarla.

Las herramientas que conocen el repositorio pueden revelar contexto útil, pero también pueden hacer que un cambio parezca más seguro de lo que es. El objetivo es convertir el acceso al repositorio en evidencia, no en permiso para modificar todos los archivos relacionados.

La documentación actual de Cursor describe referencias de contexto para material del repositorio, como archivos, carpetas, cambios de git y errores del linter. Usa los controles de contexto disponibles en tu versión para señalar al asistente el conjunto de evidencia útil más pequeño.

Por ejemplo, en lugar de esto:

Corrige el panel lento.

escribe:

Investiga el retraso de carga del panel para usuarios con sesión iniciada.

Alcance: Empieza por la ruta del panel, su hook de carga de datos y la tarjeta
que muestra un esqueleto de carga durante demasiado tiempo. Usa como contexto el
proveedor de perfil actual y la instrumentación de rendimiento existente.

Resultado: Identifica si el retraso es tiempo de obtención, renderizado
innecesario o una transición de estado. Propón la mejora medible más pequeña.

Restricciones: Conserva el comportamiento de autorización, la interfaz
localizada y los comentarios de carga existentes. No añadas una caché ni una
nueva biblioteca de estado sin evidencia.

Antes de editar, resume la ruta de ejecución e indica qué medirías.

El prompt da al asistente una ruta de acceso al repositorio sin tratar todos los archivos del panel como modificables.

El contexto del repositorio es más valioso al inicio de una tarea. Pide a Cursor que:

1. siga el flujo de datos o de control relevante;
2. identifique el código que controla el comportamiento;
3. distinga los hechos confirmados de los supuestos;
4. enumere los archivos más pequeños que probablemente cambiarán;
5. explique qué prueba u observación demostrará la corrección.

Esto es especialmente importante cuando la solicitud afecta a un proveedor compartido, un componente global, autenticación, pagos o navegación. Esas áreas suelen tener sitios de llamada que un cambio local no puede ignorar sin riesgo.

“Actualiza la funcionalidad de notificaciones” sigue siendo amplio si abarca interfaz, persistencia, workers y configuración. Añade una restricción de archivo o límite:

Cambia únicamente el formulario de preferencias de notificaciones. El escritor
de cliente es la fuente de verdad de las actualizaciones de preferencias; no
añadas otro escritor ni modifiques el scheduler en esta tarea.

Inspecciona el formulario, el escritor de cliente tipado y sus pruebas directas.
Si el error informado requiere un cambio de backend, detente y explica la
evidencia en lugar de ampliar el alcance.

Esto no impide que el asistente encuentre un problema real que cruce límites. Hace que la ampliación sea explícita y revisable.

El contexto repetido del proyecto pertenece a las instrucciones o reglas del repositorio, no a cada prompt de chat. Usa una guía duradera del proyecto para invariantes como:

• límites de static-export o de despliegue;
• requisitos de configuración regional;
• comandos de prueba y estilo de código;
• reglas de propiedad para el estado compartido;
• rutas en las que se requiere una revisión especial.

Mantén el prompt de la tarea centrado en el problema específico y los criterios de aceptación. Si las instrucciones del proyecto y el prompt discrepan, resuelve el conflicto en la solicitud en lugar de esperar que el asistente adivine cuál importa.

Las solicitudes grandes son difíciles de validar porque un diff amplio oculta la causa y el efecto. Divide el trabajo en puntos de control:

Primero inspecciona y explica la ruta actual de envío del formulario. No edites
archivos.

Después del análisis, implementa únicamente la corrección del estado de
validación y añade su prueba enfocada. Aún no refactorices los componentes de
formularios vecinos.

Ejecuta la prueba pertinente y resume el diff. Si pasa, propone un seguimiento
independiente para la limpieza compartida.

Este patrón facilita revisar el trabajo del asistente y hace práctica la reversión si la hipótesis era incorrecta.

Un asistente de programación con IA no debe elegir “parece correcto” como regla de finalización:

Criterios de aceptación:
- el comportamiento existente sigue funcionando para un envío correcto;
- el estado no válido informado se vuelve alcanzable y visible;
- los comentarios del teclado y el lector de pantalla se mantienen intactos;
- la prueba enfocada pasa y un fallo habría detectado el error anterior.

Validación: ejecuta la suite de pruebas enfocada, la comprobación de tipos y
describe cualquier paso manual en el navegador que cubra un comportamiento que
la prueba no pueda observar.

Pídele que identifique una prueba faltante en lugar de inventar confianza a partir de un resultado de compilación correcto.

Tarea: [Objetivo de ingeniería en una oración.]

Contexto del repositorio: [Archivos, carpeta, diff, error o regla existente relevantes.]
Problema: [Comportamiento observado y a quién afecta.]
Alcance: [Archivos o límite que se debe inspeccionar primero.]
Resultado deseado: [Resultado observable para la persona usuaria o el sistema.]
Restricciones: [Comportamiento, compatibilidad, arquitectura y no objetivos.]
Criterios de aceptación: [Resultados obligatorios.]
Validación: [Pruebas enfocadas, comprobación de tipos, comprobación manual, medición.]

Analiza primero. Indica quién controla actualmente el comportamiento, cuestiona
cualquier supuesto débil y propone el cambio seguro más pequeño antes de editar.

Usa el marco de razonamiento más amplio de cómo escribir mejores prompts para IA y consulta ingeniería de prompts para desarrolladores para ver patrones por tipo de tarea. Para un cambio que sea principalmente estructural, usa estas plantillas de prompts para refactorizar código.

Si una tarea del repositorio implica scripts o salida de terminal, confirma el comportamiento real del comando antes de cambiarlo. Practica flujos de trabajo de línea de comandos en el navegador para convertir una salida supuesta en un caso de prueba observable.