Rédiger des règles

Une règle est une contrainte que l'assistant doit respecter à l'intérieur d'une portée. Les règles sont le contenu le plus contraignant de Pathrule : elles arrivent comme des exigences et non comme un simple contexte, et une règle porteuse d'une contrainte exécutable approuvée peut arrêter une modification correspondante avant qu'elle ne soit appliquée.

Cette page explique quand rédiger une règle, comment choisir sa portée et sa priorité, ce que recouvre l'application des règles, et quels pièges éviter.

Quand rédiger une règle

Optez pour une règle lorsqu'il existe une chose que l'assistant ne doit jamais faire, ou une chose qu'il doit toujours faire, dans une partie précise de la base de code.

• « N'utilisez jamais la clé service role dans du code exécuté par le navigateur. »
• « Tous les montants sont stockés en entiers, en centimes. N'utilisez jamais de flottants. »
• « Les migrations doivent s'exécuter avant la modification de code correspondante. Sans exception. »
• « Les fichiers JSX de apps/web utilisent uniquement des classes Tailwind. Pas de CSS modules, pas de styles inline. »

Si la réponse est « ça dépend de la situation, l'assistant doit y réfléchir », il s'agit d'une mémoire, pas d'une règle. Les règles servent aux choses non négociables.

Types de portée

Chaque règle possède un type de portée qui détermine à quels chemins ou fichiers elle s'applique.

• folder. S'applique à une sous-arborescence de répertoires. Idéal pour les règles propres à une zone : tout ce qui se trouve sous apps/api/auth, tout ce qui se trouve sous services/billing.
• file_type. S'applique aux fichiers correspondant à un glob comme *.tsx ou **/*.test.ts. Idéal pour les préoccupations transverses liées à un type de fichier plutôt qu'à un répertoire.
• project. S'applique partout dans l'espace de travail. À utiliser avec parcimonie : une règle de projet accompagne chaque prompt.

C'est la combinaison de la portée et du chemin du nœud auquel la règle est rattachée qui détermine ce que voit l'assistant. Une règle folder rattachée à /apps/web couvre tout ce qui se trouve sous apps/web.

Niveaux de priorité

La priorité détermine avec quelle insistance la règle se manifeste. Dans une portée correspondante, les règles de priorité plus élevée sont examinées en premier.

• high. Pour ce qui provoque des bugs, des régressions de sécurité ou des problèmes de conformité en cas de violation.
• medium. La valeur par défaut. À utiliser pour ce qui vaut « presque toujours, sans être critique ».
• low. Stylistique. Remonte lorsqu'il reste de la place et que le sujet est pertinent. À utiliser pour les préférences et les conventions.

La priorité haute est un budget. Si la moitié de vos règles sont en priorité haute, aucune ne l'est vraiment. Choisissez celles qui ne doivent réellement jamais être enfreintes.

Application : advisory et strict

L'application est un réglage distinct de la priorité. La priorité définit avec quelle force une règle remonte ; l'application décide de ce qui se passe en cas de violation.

• advisory. La règle sert de contexte. L'assistant la prend en compte et décide comment l'appliquer. Les règles que vous rédigez depuis le CLI ou VS Code, ainsi que celles rédigées par un assistant, sont en mode advisory.
• strict. Une règle devient stricte lorsqu'elle porte une contrainte exécutable approuvée par une personne : la forme interdite exacte, par exemple un import, un identifiant ou un emplacement. Le hook pré-outil peut alors bloquer une modification ou une écriture de fichier qui y correspond avant qu'elle ne soit appliquée, et renvoie la règle et sa correction comme motif. Un assistant peut joindre une proposition de contrainte lorsqu'il rédige ou met à jour une règle (pathrule_write_rule, pathrule_update_rule), mais une proposition est enregistrée comme telle et ne bloque rien tant qu'une personne ne l'a pas approuvée ; un assistant ne peut jamais approuver sa propre proposition. Voir Les règles comme garde-fous.

Réécrire une règle garde l'application cohérente. Une contrainte approuvée est liée à la phrase de la règle sur laquelle elle a été validée. Si vous réécrivez la règle et que cette phrase disparaît, la contrainte cesse d'elle-même d'être appliquée : une règle ne continue donc jamais à bloquer pour une raison qu'elle n'énonce plus. Modifier d'autres parties de la règle, ou ajouter un paragraphe, laisse active une contrainte non touchée.

Le blocage dépend du client. Le CLI Pathrule installe des hooks d'outil pour Claude Code, Codex, Cursor et GitHub Copilot, et un blocage s'applique là où le hook pré-outil du client respecte la décision. Windsurf n'a pas de hooks et Remote MCP n'en installe aucun : les règles y arrivent donc uniquement comme contexte. La simple transmission n'applique rien.

Structure

Une règle a un nom et un corps. Gardez le corps court et à l'impératif.

Name: No service role key in browser code

Body:
- Never import SUPABASE_SERVICE_ROLE_KEY in any file under apps/web.
- Use the anon key plus row level security.
- If you need server only access, do it from apps/api or a server action.

Depuis le terminal, la même règle tient en une commande. Sans --body, le CLI ouvre votre éditeur pour saisir le corps.

pathrule rule add --path /apps/web --name "No service role key in browser code" --priority high --scope folder

Dans VS Code, utilisez New Rule… ; un assistant, lui, rédige les règles avec pathrule_write_rule.

La forme qui fonctionne le mieux en pratique : une contrainte par règle, avec un corps court sous forme de liste. Les règles rédigées en longue prose sont survolées, par les humains comme par les assistants.

Réutiliser plutôt que dupliquer

Une règle vit à un seul chemin et couvre tout ce qui se trouve en dessous : une seule règle suffit donc pour toute une sous-arborescence. Si la même contrainte s'applique à deux dossiers éloignés, placez-la à leur chemin commun le plus proche, ou utilisez une portée file_type avec un glob, plutôt que de copier le texte dans deux règles. Une seule règle, c'est une seule modification le jour où la contrainte change.

Pathrule vous y aide : une nouvelle règle dont le nom correspond à une règle existante de l'espace de travail est refusée par défaut, et l'écriture vous indique quelle règle existe déjà. Vous pouvez passer outre délibérément (allow_duplicate via MCP) après avoir vérifié la règle existante. Pour changer une règle d'emplacement, déplacez-la vers un autre chemin (Move… dans VS Code, ou pathrule_update_rule avec move_to_path).

Versions et modifications simultanées

Comme les mémoires, les règles portent un token de version. Si deux membres de l'équipe modifient la même règle en même temps, le conflit est signalé proprement au lieu que l'un écrase l'autre. Dans VS Code, le conflit propose les mêmes choix que pour une mémoire : Reload, Copy My Version & Reload ou Keep Mine (Overwrite).

Comment les règles parviennent à l'assistant

• Les règles d'une portée correspondante sont priorisées selon leur niveau de priorité et leur pertinence pour la tâche. Les plus pertinentes arrivent en entier ; les autres sont simplement nommées, pour que l'assistant sache qu'elles existent et puisse en lire une en entier avec pathrule_read_rule.
• Une règle stricte arrive toujours en entier là où elle s'applique, car un nom seul ne peut pas expliquer un blocage.
• Les règles sont aussi compilées dans les fichiers d'instructions que lisent vos clients (par exemple CLAUDE.md pour Claude Code et AGENTS.md pour Codex), si bien qu'un client sans hook de prompt démarre tout de même avec elles.

C'est son mode d'application (advisory ou strict), et non sa priorité, qui détermine si une règle peut bloquer une modification au lieu de simplement informer l'assistant.

Pièges à éviter

• La priorité haute partout. Choisissez les règles qui comptent vraiment. Les autres doivent être en medium.
• Des règles qui ressemblent à des mémoires. « Nous avons tendance à préférer X » est une mémoire. « Ne faites jamais Y » est une règle.
• Des règles qui se chevauchent. Deux règles de priorité haute à la formulation contradictoire valent moins qu'une seule règle claire.
• La portée projet par défaut. La plupart des règles ont leur place sous un dossier. Ne remontez une règle en project que si elle s'applique réellement partout.

Rédaction en local et dans le Cloud

Les exemples add en terminal de cette page concernent un espace de travail Cloud. En mode local, créez et modifiez les entrées dans Local Console, VS Code ou via le MCP local ; les commandes de connaissances du CLI permettent de les lister, de les lire et de les rechercher.

Pour aller plus loin

• Rédiger des mémoires pour les faits et les décisions qui ne sont pas des contraintes.
• Rédiger des skills pour les procédures réutilisables que l'assistant peut invoquer.
• Fonctionnement des hooks pour comprendre comment le runtime décide quelles règles faire remonter.