Règles

Les règles fournissent des instructions système à l’Agent. Elles regroupent des prompts, des scripts et bien plus, ce qui facilite la gestion et le partage des flux de travail au sein de votre équipe.

Cursor prend en charge quatre types de règles :

Fonctionnement des règles

Les grands modèles de langage ne conservent pas de mémoire entre les complétions. Les règles fournissent un contexte persistant et réutilisable au niveau du prompt.

Lorsqu'elles sont appliquées, le contenu des règles est inclus au début du contexte du modèle. L’IA bénéficie ainsi de directives cohérentes pour générer du code, interpréter les modifications ou faciliter les flux de travail.

Règles de projet

Les règles de projet sont stockées dans .cursor/rules sous forme de fichiers .mdc et sont versionnées. Elles s’appliquent selon des conventions de chemin, peuvent être invoquées manuellement ou incluses selon leur pertinence.

Utilisez les règles de projet pour :

• Documenter des connaissances spécifiques au domaine concernant votre base de code
• Automatiser des flux de travail ou des modèles propres au projet
• Standardiser les choix de style ou d’architecture

Structure d’un fichier de règle

Chaque règle est un fichier .mdc que vous pouvez nommer comme vous le souhaitez. Les règles de projet doivent utiliser l’extension .mdc. Un fichier .md classique placé dans .cursor/rules est ignoré par le système de règles, car il ne contient pas d’en-tête YAML permettant de définir description, globs et alwaysApply. Si vous préférez le markdown classique, utilisez plutôt AGENTS.md.

.cursor/rules/  react-patterns.mdc       # Reconnu comme règle de projet  api-guidelines.md        # Ignoré (extension incorrecte)  frontend/                # Organiser les règles dans des dossiers    components.mdc

Anatomie d'une règle

Chaque règle est un fichier markdown contenant des métadonnées dans l'en-tête YAML et du contenu. Définissez la façon dont les règles sont appliquées à l'aide du menu déroulant Type, qui modifie les propriétés description, globs et alwaysApply.

En interne, les trois champs de l'en-tête YAML interagissent pour déterminer quand une règle est incluse :

---alwaysApply: true---- Tous les fichiers sources doivent inclure l’en-tête de copyright de l’entreprise- En cas de doute sur les détails d’implémentation, lisez les fichiers  sources concernés avant de proposer des modifications- Ne modifiez jamais les fichiers générés dans les répertoires `dist/` ou `build/`

---globs: src/components/**/*.tsxalwaysApply: false---- Utilisez des exports nommés, pas des exports par défaut- Placez les styles dans un fichier CSS module à côté du composant- Limitez les composants à moins de 200 lignes. Extrayez les sous-composants dans le même  répertoire lorsqu’un fichier dépasse cette taille- Préférez la composition au passage de props en cascade. Passez des children ou des render props  plutôt que de faire transiter les données à travers plusieurs couches

---description: RPC service conventions and patterns for the backendalwaysApply: false---- Define each service in its own file under `src/services/`- Always validate inputs at the service boundary before passing data  to internal functions- Return structured error objects with a `code` and `message` field,  never throw raw strings- Add a `@service-template.ts` reference file when creating a new  service for the standard boilerplate

---alwaysApply: false---- Every database migration must have both `up` and `down` functions  so it can be fully reversed- Never alter a column type in-place. Add a new column, backfill,  then drop the old one in a separate migration- Reference the template for the expected file structure@migration-template.sql

Exemples de motifs glob

Utilisez globs pour limiter une règle à des fichiers ou répertoires spécifiques. Séparez plusieurs motifs par des virgules.

Créer une règle

Il existe deux façons de créer des règles :

• /create-rule dans le chat : saisissez /create-rule dans Agent et décrivez ce que vous souhaitez. Agent génère le fichier de règle avec l’en-tête YAML approprié et l’enregistre dans .cursor/rules.
• Depuis Personnaliser : ouvrez Personnaliser dans la barre latérale, accédez à Règles, puis cliquez sur Ajouter une règle. Un nouveau fichier de règle est alors créé dans .cursor/rules. Dans Personnaliser, vous pouvez consulter toutes les règles et leur statut.

Bonnes pratiques

Les bonnes règles sont ciblées, exploitables et bien définies.

• Limitez les règles à 500 lignes maximum
• Divisez les règles volumineuses en plusieurs règles composables
• Fournissez des exemples concrets ou indiquez les fichiers concernés
• Évitez les consignes vagues. Rédigez les règles comme une documentation interne claire
• Réutilisez les règles lorsque vous répétez des prompts dans le chat
• Faites référence aux fichiers plutôt que d'en copier le contenu — les règles restent ainsi concises et ne deviennent pas obsolètes à mesure que le code évolue

Ce qu’il faut éviter dans les règles

• Copier des guides de style entiers : utilisez plutôt un linter. Agent connaît déjà les conventions de style courantes.
• Documenter toutes les commandes possibles : Agent connaît les outils courants comme npm, git et pytest.
• Ajouter des instructions pour des cas limites qui s’appliquent rarement : gardez les règles axées sur les conventions que vous utilisez souvent.
• Dupliquer ce qui existe déjà dans votre base de code : renvoyez vers des exemples de référence plutôt que de copier du code.

Enregistrez vos règles dans git pour que toute votre équipe en bénéficie. Lorsque vous voyez Agent commettre une erreur, mettez à jour la règle. Vous pouvez même mentionner @cursor dans une issue ou une PR GitHub pour qu’Agent mette la règle à jour à votre place.

Format des fichiers de règles

Chaque règle est un fichier markdown contenant des métadonnées d’en-tête YAML et du contenu. Les métadonnées d’en-tête YAML contrôlent la manière dont la règle est appliquée. Le contenu constitue la règle elle-même.

---description: "This rule provides standards for frontend components and API validation"alwaysApply: false---...rest of the rule content

Si alwaysApply est défini sur true, la règle sera appliquée à chaque session de chat. Sinon, sa description sera présentée au Cursor Agent, qui déterminera si elle doit être appliquée.

Exemples

<SettingsSubSection  label="Your feature name"  description="Your feature description"  value={    vsContext.reactiveStorageService.applicationUserPersistentStorage      .myNewProperty ?? false  }  onChange={(newVal) => {    vsContext.reactiveStorageService.setApplicationUserPersistentStorage(      "myNewProperty",      newVal,    );  }}/>

const flagIsEnabled =  vsContext.reactiveStorageService.applicationUserPersistentStorage    .myNewProperty;

Des exemples sont disponibles auprès de fournisseurs et de frameworks. Des règles proposées par la communauté sont disponibles dans des collections participatives et des référentiels en ligne.

Règles d’équipe

Les forfaits Team et Enterprise permettent de créer et d’imposer des règles à l’échelle de toute l’organisation depuis le tableau de bord Cursor. Les administrateurs peuvent définir si chaque règle est obligatoire pour les membres de l’équipe.

Les règles d’équipe fonctionnent avec les autres types de règles et prévalent sur celles-ci afin de garantir le respect des normes de l’organisation dans tous les projets. Elles permettent d’appliquer des normes, pratiques et flux de travail de programmation cohérents à toute votre équipe, sans nécessiter d’installation ou de configuration individuelle.

Gestion des règles d’équipe

Les administrateurs d’équipe peuvent créer et gérer des règles directement depuis le tableau de bord de Cursor :

Une fois créées, les règles d’équipe s’appliquent automatiquement à tous les membres de l’équipe et sont visibles dans le tableau de bord :

Activation et application

• Activer cette règle immédiatement : Lorsqu’elle est cochée, la règle est active dès sa création. Lorsqu’elle est décochée, la règle est enregistrée comme brouillon et ne s’applique pas tant que vous ne l’activez pas ultérieurement.
• Imposer cette règle : Lorsqu’elle est activée, la règle est obligatoire pour tous les membres de l’équipe et ne peut pas être désactivée dans Personnaliser. Lorsqu’elle n’est pas imposée, les membres de l’équipe peuvent désactiver la règle dans la section Règles d’équipe de Personnaliser.

Format et application des règles d’équipe

• Contenu : les règles d’équipe sont du texte libre. Elles n’utilisent pas la structure de dossiers des règles de projet.
• Motifs glob : les règles d’équipe prennent en charge les motifs glob pour s’appliquer à des fichiers spécifiques. Lorsqu’un motif glob est défini (p. ex., **/*.py), la règle s’applique uniquement lorsque des fichiers correspondants sont présents dans le contexte. Les règles sans motif glob s’appliquent à chaque conversation.
• Champ d’application : lorsqu’une règle d’équipe est activée (et non désactivée par l’utilisateur, sauf si elle est imposée), elle est incluse dans le contexte du modèle pour l’Agent (Chat) dans tous les dépôts et projets de l’équipe.
• Priorité : les règles sont appliquées dans cet ordre : règles d’équipe → règles de projet → règles utilisateur. Toutes les règles applicables sont fusionnées ; en cas de conflit, les sources antérieures prévalent.

Importer des règles

Vous pouvez importer des règles depuis des sources externes afin de réutiliser des configurations existantes ou d'importer des règles depuis d'autres outils.

Règles distantes (via GitHub)

Importez des règles directement depuis n’importe quel dépôt GitHub auquel vous avez accès, qu’il soit public ou privé.

1. Ouvrez Personnaliser dans la barre latérale
2. Accédez à Règles et cliquez sur Ajouter une règle
3. Sélectionnez Règle distante (Github)
4. Collez l’URL du dépôt GitHub contenant les règles. Cursor analysera tous les fichiers .mdc du dépôt.
5. Cursor récupérera et synchronisera les règles dans votre projet

Les règles seront placées dans .cursor/rules/imported/<repoName>. Elles conserveront également leurs chemins relatifs : dir/rule.mdc sera donc importé sous .cursor/rule/imported/<repoName>/dir/rule.mdc.

AGENTS.md

AGENTS.md est un simple fichier markdown qui permet de définir des instructions pour les agents. Placez-le à la racine de votre projet comme alternative à .cursor/rules pour les cas d’utilisation simples.

Contrairement aux règles de projet, AGENTS.md est un fichier markdown brut, sans métadonnées ni configurations complexes. Il est idéal pour les projets qui nécessitent des instructions simples et lisibles, sans la complexité des règles structurées.

Cursor prend en charge AGENTS.md à la racine du projet et dans les sous-répertoires.

# Instructions du projet## Style de code- Utilisez TypeScript pour tous les nouveaux fichiers- Privilégiez les composants fonctionnels dans React- Utilisez snake_case pour les colonnes de la base de données## Architecture- Suivez le modèle repository- Conservez la logique métier dans les couches de service

Améliorations

project/  AGENTS.md              # Instructions globales  frontend/    AGENTS.md            # Instructions spécifiques au frontend    components/      AGENTS.md          # Instructions spécifiques aux composants  backend/    AGENTS.md            # Instructions spécifiques au backend

Règles utilisateur

Les règles utilisateur sont des préférences globales définies dans Personnaliser → Règles qui s’appliquent à tous les projets. Elles sont utilisées par Agent (Chat) et sont idéales pour définir un style de communication ou des conventions de programmation privilégiés :

Répondez de manière concise. Évitez les répétitions inutiles et les formulations superflues.

FAQ