Règles Cursor : où les ranger, comment les déclencher, quoi ne pas y mettre

Un agent de code ne se souvient pas de vos conventions d'une conversation à l'autre. Les règles servent à cela : des consignes persistantes, injectées dans le contexte du modèle. La documentation de Cursor décrit où les placer et, ce qui est plus rare, quand s'en passer.

Quatre sources d'instructions

• Règles de projet : des fichiers .mdc rangés dans .cursor/rules, versionnés avec le code. Attention, la documentation précise que les fichiers .md simples placés dans ce dossier sont ignorés.
• Règles utilisateur : vos préférences personnelles, réglées dans le menu Customize, valables sur tous vos projets.
• Règles d'équipe : gérées depuis le tableau de bord, réservées aux formules Team et Enterprise.
• AGENTS.md : un fichier Markdown sans en-tête, à la racine du projet ou dans un sous-dossier. Cursor le présente comme l'option la plus simple.

En cas de conflit, l'ordre de priorité est : équipe, puis projet, puis utilisateur. Toutes les règles applicables sont fusionnées.

Quatre façons de déclencher une règle de projet

L'en-tête d'un fichier .mdc accepte trois champs : description, globs et alwaysApply. Ils déterminent le mode d'application :

Mode	Déclenchement
Toujours	à chaque session, si alwaysApply vaut true
Intelligent	l'agent décide d'après la description
Par fichiers	quand un fichier du contexte correspond aux motifs de globs
Manuel	seulement quand on mentionne la règle, par exemple @my-rule

Conséquence pratique : une règle en mode intelligent sans description ne se déclenchera pas. C'est la première vérification proposée par la documentation quand une règle semble ignorée.

Pour créer une règle, tapez /create-rule dans la conversation avec l'agent et décrivez ce que vous voulez, ou passez par Customize, puis Rules, puis Add Rule.

Les bonnes pratiques de l'éditeur

• garder chaque règle sous 500 lignes ;
• découper les grosses règles en règles plus petites et combinables ;
• donner des exemples concrets ou pointer vers des fichiers de référence ;
• renvoyer vers un fichier plutôt que d'en recopier le contenu ;
• n'ajouter une règle que lorsque l'agent refait la même erreur ;
• versionner les règles dans git.

Un détail technique compte ici. Quand une règle mentionne un fichier, son contenu n'est pas copié dans le contexte : l'agent va le lire avec ses outils s'il en a besoin. Ce qui doit être présent en permanence a donc sa place dans le corps de la règle.

Ce qu'il vaut mieux éviter

La documentation liste quatre travers :

• recopier un guide de style entier, alors qu'un linter fait ce travail ;
• documenter toutes les commandes, l'agent connaissant déjà les outils courants ;
• écrire des consignes pour des cas rares ;
• dupliquer le contenu du code au lieu de désigner un exemple de référence.

Les règles d'équipe

Un administrateur peut rendre une règle obligatoire : les membres ne peuvent alors plus la désactiver. Sans motif de fichiers, une règle d'équipe s'applique à toutes les conversations.

Les limites

Les règles n'agissent pas sur la complétion automatique Cursor Tab, précise la FAQ. La documentation ne dit pas dans quelle mesure l'agent respecte une règle : comme toute consigne donnée à un modèle, elle oriente sans garantir. Enfin, les règles .mdc demandent un en-tête à renseigner correctement, là où AGENTS.md est un fichier Markdown sans métadonnées.

Notre lecture

Si votre équipe utilise plusieurs agents de code, mettez le socle commun dans un AGENTS.md à la racine : commandes de test, structure du projet, interdits. Réservez les fichiers .mdc aux consignes qui ne concernent que certains dossiers, avec un motif globs. Et suivez le conseil le plus sobre de la page : partez d'un fichier presque vide, puis ajoutez une règle chaque fois que l'agent se trompe deux fois de la même manière.