Configurar reglas de cursor para que la IA deje de alterar el estilo de su base de código
La configuración .cursor/rules que uso en un repositorio de equipo: un archivo global, un archivo por directorio y las tres reglas que eliminaron el 90% de mis confirmaciones de corrección de estilo.
En mi primer mes con Cursor, todas las ediciones del agente funcionaron y todavía me sentía mal: pestañas donde mi repositorio usa espacios, exportaciones predeterminadas en una base de código de aquellas con nombre, pruebas escritas en un estilo que nuestro CI rechaza. La solución no fue mejor. Eran archivos de reglas, configurados correctamente.
El cursor lee las reglas de .cursor/rules en su repositorio. Comience con un archivo de reglas a nivel de proyecto que cubra los elementos no negociables: administrador de paquetes, orden de importación, convenciones de nomenclatura y los dos o tres patrones que utiliza su código base que difieren de los valores predeterminados comunes. Manténgalo por debajo de unas 50 líneas: un archivo de reglas que nadie mantiene se convierte en ruido que el modelo aprende a ignorar.
La característica subestimada son las reglas por directorio. Nuestro directorio de componentes tiene una regla: solo componentes de función, accesorios escritos en línea, sin exportación predeterminada. Nuestro directorio de servidores obtiene otro: no hay importaciones del lado del cliente, cada controlador valida la entrada. Esta división hizo más por la calidad de salida que cualquier cosa que escribí en el archivo global, porque el modelo solo ve las reglas que se aplican a los archivos que toca.
Tres reglas ganaron su lugar por pura repetición. Primero: "Después de editar, ejecute el comando lint existente y corrija todos los errores que introdujo". Segundo: "Haga coincidir el estilo de importación del archivo que está editando, no el estilo que prefiera". Tercero: "Si un cambio requiere una nueva dependencia, deténgase y pregunte en lugar de instalar". Este último vino después de que encontré cinco paquetes nuevos en una diferencia que necesitaba uno.
Lo que dejé de hacer: repetir instrucciones de estilo en cada mensaje de chat. Con las reglas implementadas, mis indicaciones describen la intención (qué construir, qué evitar) y el archivo de reglas maneja el estilo de la casa. El mensaje se hizo más corto y el resultado se volvió más consistente, que es todo el juego.
Un hábito de mantenimiento: cuando el agente comete repetidamente el mismo error, agregue una regla en lugar de regañarlo en el chat. Las correcciones del chat mueren con la conversación; archivos de reglas compuestos. Mi archivo de reglas ha crecido aproximadamente dos líneas por semana y cada línea tiene una corrección de error detrás.
Preguntas frecuentes:
P: ¿Los archivos de reglas ralentizan el cursor?
R: No notablemente. Se inyectan en contexto junto con su mensaje. El costo real es un archivo de reglas inflado que diluye la atención, por lo que limito el mío y elimino las reglas que el código base ha superado.
P: ¿Deben comprometerse las reglas con el repositorio?
R: Sí, si desea que todo el equipo se beneficie, trátelos como una configuración de linter. Mantenga las preferencias personales en las reglas a nivel de usuario en lugar del archivo del proyecto.
P: ¿En qué se diferencian las reglas de simplemente escribir un buen mensaje del sistema?
R: Las reglas se aplican automáticamente a cada solicitud dentro de su alcance, sobreviven entre sesiones y se versionan con el código. Un aviso del sistema en tu cabeza no beneficia a nadie más que a ti y se evapora cada vez que inicias un nuevo chat.