Comment écrire des règles Cline et vérifier leur chargement

Commencez par deux règles vérifiables

Placez un contrat de tâche et une règle de vérification et de livraison dans le répertoire .clinerules/ du dépôt. Activez les deux, démarrez une nouvelle tâche et examinez le plan, le diff et les résultats des tests. Ajoutez des conditions de chemin après avoir vérifié cette configuration dans votre client.

Ce guide fournit des fichiers complets et une procédure de validation. Nous avons consulté la documentation officielle et un instantané public du code le 23 octobre 2026. Nous n'avons pas exécuté Cline sur un dépôt ni mesuré l'effet de ces instructions sur le comportement du modèle.

Les règles ajoutent des instructions au contexte du modèle. Elles ne créent aucune limite de permissions ni aucun bac à sable de sécurité. Configurez séparément les approbations et l'accès au dépôt. La documentation Auto Approve décrit ces contrôles.

Choisissez l'emplacement adapté au client

Le guide de configuration décrit les règles de projet dans .cline/rules/ et dans l'ancien format .clinerules/. Il mentionne aussi AGENTS.md à la racine et le fichier global ~/.agents/AGENTS.md. Les exemples utilisent uniquement .clinerules/. Ne dupliquez pas les mêmes instructions dans les deux répertoires.

Le chargeur actuel accepte aussi l'ancien fichier .clinerules, sans extension. Un fichier et un répertoire ne peuvent pas occuper ce même chemin. Avant une conversion, conservez le texte existant, puis placez-le dans un fichier Markdown du nouveau répertoire. Gardez les règles directement dans ce répertoire. Le chargeur recherche les fichiers .md, .markdown et .txt, sans parcourir les dossiers de règles imbriqués.

Pour vos préférences personnelles, le résolveur de chemins partagé recherche ~/.cline/rules, ~/Cline/Rules et l'emplacement Cline Rules dans Documents. Sous Windows, il peut aussi consulter les dossiers Documents redirigés par OneDrive. Utilisez l'emplacement affiché par votre client.

La documentation des règles indique que les règles du projet prévalent sur les règles globales en cas de conflit. Supprimez tout de même les contradictions. Les préfixes numériques organisent les fichiers. Ils n'établissent pas une hiérarchie de permissions et ne prouvent pas quelle instruction contradictoire le modèle suivra.

Vérifiez chaque client séparément :

• Dans l'éditeur, ouvrez Rules avec l'icône de balance et vérifiez l'interrupteur de chaque fichier.
• Le CLI partage les répertoires documentés, mais dispose de sa propre configuration et de ses contrôles d'approbation. Examinez cline config. La présentation du CLI indique actuellement que l'approbation automatique globale est activée par défaut. Vérifiez ce réglage avant l'essai.
• Cloud Agents ne charge actuellement ni règles, ni skills, ni serveurs MCP, ni connecteurs. Versionner une règle ne l'active pas dans une session cloud.

Créez un contrat de tâche et une règle de livraison

Ouvrez la racine du dépôt dans l'éditeur. Si .clinerules n'existe pas, créez ce répertoire. Enregistrez chaque bloc dans le fichier indiqué. Les exemples supposent un projet JavaScript ou TypeScript avec package.json. Adaptez les chemins autorisés, le gestionnaire de paquets et les vérifications au dépôt réel.

Enregistrez .clinerules/01-task-contract.md :

# Contrat de tâche

Avant de proposer une modification :
- Lisez README.md et package.json. Identifiez le gestionnaire de paquets avec le fichier de verrouillage.
- Examinez les fichiers cibles et les tests voisins. Ne lisez ni fichiers .env ni identifiants secrets.
- Précisez le comportement demandé, les fichiers à modifier et les vérifications pertinentes.
- Si la demande ne définit pas le périmètre, proposez-en un avant toute modification.

Pendant l'implémentation :
- Modifiez uniquement les fichiers nécessaires à la tâche convenue. Préservez les autres modifications de l'utilisateur.
- Expliquez la nécessité d'un changement de dépendance ou de verrouillage avant de le faire.
- Si une modification nécessaire dépasse le périmètre convenu, arrêtez-vous et expliquez pourquoi.

Enregistrez .clinerules/02-checks-and-delivery.md :

# Vérifications et livraison

Avant la livraison :
- Recherchez les commandes de vérification dans package.json et le README du projet.
- Pour un changement de comportement, ajoutez ou adaptez un test ciblé si le projet dispose de tests.
- Exécutez le test pertinent et les contrôles de types ou de lint configurés pour le code modifié.
- Si une vérification nécessaire manque ou ne peut pas être exécutée, signalez cette limite.

Pendant la livraison :
- Examinez le diff final pour détecter les modifications hors sujet et les erreurs d'espacement.
- À la livraison, listez les fichiers modifiés, les commandes exactes, leurs résultats et les problèmes restants.
- N'annoncez jamais une vérification réussie sans avoir observé son résultat positif.

Les règles demandent à Cline de trouver les commandes existantes. Elles ne supposent pas la présence de lint, typecheck ou test dans chaque projet. Un projet npm pourrait utiliser les commandes suivantes. Les deux dernières exigent les scripts correspondants et un outil de test qui accepte un chemin de fichier. Remplacez-les par les commandes réelles du dépôt.

git status --short
npm run
git diff --check
npm run typecheck
npm test -- src/utils/parse-label.test.ts

Gardez ces obligations inconditionnelles. Une règle de test chargée uniquement pour *.test.ts peut manquer une tâche qui modifie le code sans créer de test.

Confirmez le chargement avant de juger le comportement

Dans le panneau Rules, vérifiez que les deux fichiers apparaissent dans le projet et sont activés. Examinez ensuite les fichiers avec Git. L'implémentation actuelle de l'extension enregistre les interrupteurs dans les métadonnées YAML disabled. Désactiver une règle peut donc modifier un fichier versionné. Examinez le diff avant de transmettre un choix temporaire à l'équipe.

Démarrez une nouvelle conversation en mode Plan avec une demande délimitée. Adaptez les chemins à une fonction et à un test existants :

Plan uniquement. Dans src/utils/parse-label.ts, faites rejeter par
parseLabel les entrées vides ou composées seulement d'espaces,
sans changer le comportement des entrées valides.
Le périmètre est ce fichier et src/utils/parse-label.test.ts.
Avant de modifier, identifiez le code existant et la commande de test.

Vérifiez que la réponse identifie les deux fichiers autorisés, l'implémentation existante et les vérifications pertinentes. Une déclaration telle que "j'ai chargé les règles" ne suffit pas. Comparez le plan avec les fichiers examinés. Si le plan convient, passez à Act avec les approbations prévues et laissez Cline tenter la modification.

Acceptez le résultat après examen du diff et des résultats observés. Le changement doit rejeter les entrées indiquées, préserver le comportement valide et respecter le périmètre. Les checkpoints utilisent un dépôt Git auxiliaire distinct. Ils aident à restaurer le travail local, mais ne remplacent ni vos commits, ni la revue de branche, ni les sauvegardes.

Ajoutez une règle conditionnelle et testez les deux cas

Le guide des règles définit paths comme un tableau de motifs glob relatifs au projet. Une seule correspondance peut activer la règle. Les onglets de l'éditeur, les chemins du message et les fichiers de la tâche peuvent fournir le contexte. Une correspondance ne réactive pas un interrupteur désactivé.

Enregistrez ce fichier facultatif dans .clinerules/20-typescript.md :

---
paths:
  - "src/**/*.ts"
  - "src/**/*.tsx"
---

# Modifications TypeScript

Pour une tâche qui modifie un fichier .ts ou .tsx sous src :
- Incluez TS-RULE-ACTIVE une fois dans le plan initial pendant la validation des règles.
- Examinez les types voisins avant d'introduire un nouveau type public.
- Préservez les signatures exportées sauf si la tâche exige une modification d'API.
- Expliquez tout nouvel any ou commentaire de suppression d'erreur TypeScript.

Vérifiez les conditions de chemin dans le client installé. Le moteur de rendu actuel du SDK sélectionne les règles activées sans évaluer paths dans cette fonction. Cette lecture du code ne prouve pas un comportement conditionnel identique entre l'éditeur, Desktop et le CLI. Conservez les contraintes nécessaires dans les fichiers inconditionnels avant de valider votre client.

1. Créez une nouvelle tâche dans l'éditeur et mentionnez un fichier réel correspondant, hors d'un bloc de code collé. Cherchez la notification conditionnelle documentée et le marqueur temporaire TS-RULE-ACTIVE.
2. Créez une autre tâche sur un fichier Markdown hors de src. Fermez d'abord les onglets TypeScript correspondants. Vérifiez que la règle ne s'active pas.
3. Désactivez la règle facultative et répétez la tâche correspondante. Vérifiez qu'elle reste inactive. Rétablissez ensuite l'état souhaité.
4. Après validation, retirez la demande de marqueur et gardez les conventions utiles.

Le marqueur vérifie la transmission des instructions, pas la qualité du code. Évaluez le respect des règles avec le diff et les vérifications réelles. Le modèle peut ignorer ou mal interpréter une règle chargée.

Diagnostiquez les règles absentes ou inattendues

Vérifiez ces causes dans l'ordre avant d'agrandir votre collection :

1. Confirmez le client et la racine du projet. Une session cloud ne charge pas ces fichiers. Un sous-dossier ouvert comme projet peut changer les règles racine découvertes.
2. Confirmez le chemin et l'interrupteur. Utilisez un Markdown non vide directement dans .clinerules/ ou .cline/rules/. Recherchez disabled: true et les copies contradictoires dans les règles globales ou AGENTS.md.
3. Vérifiez les délimiteurs et l'indentation YAML. Utilisez le tableau de chaînes entre guillemets de l'exemple. La documentation décrit le YAML invalide comme fail-open, mais l'analyseur actuel du SDK lève une erreur. Corrigez la syntaxe sans dépendre d'un comportement de repli.
4. Vérifiez le contexte et les motifs. src/*.ts ne couvre pas les sous-dossiers. Créez une nouvelle tâche, précisez le chemin relatif et fermez les onglets correspondants sans rapport. Selon la documentation, paths: [] ne correspond à rien. N'utilisez pas ce tableau vide pour une règle permanente.
5. Distinguez chargement et respect. Si une règle visible se charge mais que le patch la viole, raccourcissez l'instruction, résolvez les conflits et répétez la validation. Notez la version du client avant de conclure à un défaut général de Cline.

Gardez un relevé par essai :

Relevé	Informations à conserver
Environnement	Client et version, commit du dépôt, fournisseur et modèle exact
État des règles	Fichiers, commit ou diff des règles, interrupteurs, chemin correspondant
Preuve de chargement	Panneau Rules, notification conditionnelle si disponible, résultat du marqueur
Preuve de tâche	Message, périmètre proposé, diff final, modifications hors sujet
Validation	Commandes exactes et résultats, corrections manuelles, échecs restants

Entretenez les règles comme des fichiers de projet revus

Versionnez les règles partagées avec le code concerné. Attribuez un relecteur aux changements de règles et ajoutez la petite tâche de validation à la description. Si un script, un répertoire ou une convention change, adaptez la règle dans la même pull request. Gardez les préférences personnelles au niveau global et excluez les identifiants secrets de toutes les règles partagées.

Une collection "awesome .clinerules" peut fournir des idées, mais examinez chaque instruction avant l'import. Retirez les références à des fichiers absents, les commandes incompatibles, les demandes générales d'approbation automatique et les contradictions. Un petit ensemble d'instructions vérifiées facilite la revue.

Si vous migrez d'anciennes règles Roo, l'avis officiel annonce la fermeture de l'extension, de Cloud et de Router le 15 mai 2026. Réécrivez l'intention pour Cline et refaites la validation. Renommer un ancien fichier de règles Roo ne transfère ni restrictions de mode, ni permissions, ni services hébergés. Notre guide de migration de Roo vers Cline décrit cette transition. Consultez Kilo Code face à Cline pour choisir un client maintenu.