Tu app tiene componentes React en src/components y handlers de API en src/server. Le pides a Cursor que cambie un formulario y el agente aplica una regla general de backend a la UI, o inventa una pauta visual al editar autenticación. La solución práctica no es un prompt gigante que se repite en cada chat: son dos reglas de proyecto cortas, versionadas y asociadas a archivos distintos.

La documentación actual de Cursor sitúa las Project Rules en .cursor/rules como archivos .mdc. Pueden aplicarse siempre, por rutas, manualmente o según relevancia. Para una app mixta, las reglas por patrón reducen el contexto irrelevante: la de interfaz aparece cuando un componente entra en el contexto del agente; la de API, cuando entra un handler. No sustituyen permisos de archivos ni pruebas de ejecución: son instrucciones para el modelo.

Dos archivos concretos para adaptar

Crea .cursor/rules/frontend.mdc con esta estructura. Cambia la ruta si tu proyecto no usa src/components:

---
description: UI conventions for React components
globs: "src/components/**/*.tsx"
alwaysApply: false
---
- Before editing, inspect one existing component in this folder.
- Keep loading, empty, and error states visible to users.
- Run the project's typecheck after changing components.

Ahora crea .cursor/rules/backend.mdc para handlers en src/server:

---
description: API conventions for server handlers
globs: "src/server/**/*.ts"
alwaysApply: false
---
- Validate input at the request boundary before calling a service.
- Keep secrets out of logs and responses.
- Add or update a test for a changed handler.

En ambos casos alwaysApply: false evita inyectar la regla en toda conversación. El campo globs restringe por archivos que aparecen en el contexto. Cursor documenta que ** recorre directorios y que un archivo .md dentro de .cursor/rules se ignora como regla de proyecto: usa .mdc. Los ejemplos son deliberadamente breves y verificables; «escribe código limpio» no le dice al agente qué archivo mirar ni qué prueba ejecutar.

Comprueba que la regla correcta entra en juego

1. Abre un componente real bajo src/components, inclúyelo en la conversación y mira las reglas activas en Cursor. Debería aparecer la regla frontend. Pide una modificación pequeña, por ejemplo añadir un estado vacío a un listado.
2. Abre un handler bajo src/server. Comprueba que la regla backend esté activa y pide validar un campo de entrada en una rama de prueba.
3. Revisa el diff y ejecuta el typecheck y los tests que realmente existan en el repositorio. Si el agente dice que corrió una prueba, exige salida o ejecuta el comando tú mismo.
4. Si las dos reglas aparecen al mismo tiempo porque ambos tipos de archivo están en contexto, decide qué instrucción corresponde a cada archivo. No esperes que el patrón resuelva por sí solo conflictos entre reglas.

Validé localmente que los dos ejemplos .mdc tienen frontmatter YAML legible, con descripción, patrón y alwaysApply: false. No ejecuté Cursor en la cuenta de Joseph ni medí una mejora de calidad del código. La comprobación real de activación se hace en el editor con tus rutas. Si tu estructura usa app/api o packages/ui, copia los ejemplos solo después de actualizar los globs; de lo contrario, una regla puede quedar guardada y nunca aplicarse.

Haz también una prueba negativa: abre un archivo que no coincida, como README.md, en una conversación nueva. Las dos reglas específicas no deberían aparecer solo por estar guardadas en el repositorio. Si aparecen, revisa si las marcaste como «Always Apply» o si otra regla global repite sus instrucciones. Si no aparecen al abrir un componente, comprueba nombre .mdc, ubicación, patrón y si el archivo está incluido en el contexto. Guarda ese pequeño protocolo en la revisión del PR que añade las reglas.

Cuándo usar AGENTS.md y cuándo separar reglas

Cursor también admite AGENTS.md en la raíz para instrucciones generales del proyecto. Úsalo para hechos que todo agente necesita: cómo ejecutar tests, dónde está la arquitectura o qué no debe publicarse sin revisar. Reserva reglas .mdc para pautas de una zona del código. Evita copiar la misma instrucción en los dos lugares; las contradicciones cuestan tiempo y hacen difícil saber qué siguió el agente. Versiona los archivos junto al código y revísalos cuando cambie la estructura de carpetas.

Este patrón responde a un problema de calidad y contexto. Para permisos, secretos y revisión de comandos, consulta nuestra guía de tres barreras para Cursor Agent. Una regla que dice «no publiques secretos» no impide que una herramienta con acceso los lea; la separación aquí hace que las instrucciones pertinentes acompañen al archivo pertinente y que puedas comprobarlo antes de aceptar el diff.