Règles

Une règle est une consigne que votre agent doit suivre à chaque fois : « lance toujours la suite de tests avant un push », « ne touche jamais directement à la base de production ». Les faits décrivent comment les choses sont ; les règles disent comment les choses doivent être faites. Quand une règle et une habitude mémorisée se contredisent, la règle l'emporte. Et aucune règle ne devient contraignante tant qu'une personne ne l'a pas approuvée.

La page Rules : chaque règle avec le moment où elle s'applique, sa portée et son auteur. Les règles proposées y attendent votre approbation.

Ajouter une règle

Il y a deux façons de faire.

Dites-le à votre agent. Dites par exemple « fais-en une règle : lance toujours les tests avant de pusher ». Quand vous le confirmez dans la conversation, l'agent l'enregistre comme règle active. Quand l'agent repère de lui-même quelque chose qui ressemble à une règle, il l'enregistre plutôt comme règle proposée, et une règle proposée n'a aucun effet tant que vous ne l'avez pas approuvée.

Utilisez le tableau de bord. Ouvrez Rules dans le tableau de bord et cliquez sur Add rule. Renseignez un Title (un nom court que vous reconnaîtrez dans une liste, comme tests-before-push), le texte de la règle dans Rule, When it applies (voir Conditions), une Delivery priority et un Scope. Une règle que vous ajoutez vous-même est active immédiatement.

Approuvez ou rejetez une proposition. Les règles proposées sont listées sur la même page. Ouvrez-en une et cliquez sur Approve ou Reject.

Avant d'ajouter une règle, vérifiez celles que vous avez déjà. Si une nouvelle règle recoupe une règle existante, modifiez celle-ci plutôt que d'en empiler une seconde, peut-être contradictoire. La détection des doublons vous y aide.

Comment les propositions vous sont soumises

Une proposition attend un moment où elle se serait réellement appliquée (vous êtes sur le point de faire ce dont elle parle, ou vous en parlez), puis votre agent vous pose la question en une ligne.

• Oui la rend contraignante.
• Non l'écarte et retient que vous avez refusé : la même suggestion ne revient pas reformulée.
• Ignorez-la ou répondez « pas maintenant », et elle se tait pendant 7 jours.

Votre agent pose au plus une de ces questions par session. Une proposition que vous écartez 3 fois cesse d'être posée et est conservée comme une observation sur votre façon de travailler.

Votre agent peut aussi proposer une meilleure formulation d'une règle existante, ou proposer de la retirer. La règle existante reste pleinement en vigueur tant que vous n'avez pas accepté le changement.

Portée

Une règle est soit globale (elle s'applique dans tous les profils), soit limitée au profil courant, soit partagée par une liste de profils que vous choisissez.

Conditions : quand une règle s'applique

Le texte de la règle dit quoi faire. Ses conditions disent quand elle s'applique. Laissez le « quand » hors du texte de la règle et placez-le dans les conditions.

Sans condition, la règle s'applique toujours, à chaque prompt et à chaque appel d'outil.

Il existe deux types de condition :

• Une vérification est un test que Neuronz.ai effectue lui-même : l'outil sur le point de s'exécuter est Bash, le fichier en cours d'écriture se termine par .py, la branche est main. La réponse est un simple oui ou non, sans aucune appréciation.
• Une appréciation est une phrase que seul votre agent, au sein de la conversation, peut trancher : « la commande touche à la production », « l'utilisateur demande une refonte du code ».

Dans le tableau de bord, ce sont les boutons Add check et Add judgement. Avec deux conditions ou plus, vous choisissez si la règle s'applique quand toutes sont remplies (all) ou quand l'une d'elles l'est (any).

Une vérification porte sur l'un de ces éléments :

Vérification	Ce qu'elle examine
Tool name	l'outil que l'agent s'apprête à appeler : Bash, Write, mcp__slack__post_message
File path	le fichier que touche cet appel
Tool input	les arguments de l'appel : la ligne de commande, le texte sur le point d'être publié
Working directory	le dépôt dans lequel travaille la session
Git branch	la branche git courante
Prompt text	ce que vous venez de demander
Model	le modèle d'IA qu'utilise votre agent (voir Règles pour un seul modèle)

La comparaison se fait avec matches (un motif avec *, comme **/*.py ou mcp__slack__*), contains ou is. Toutes les comparaisons ignorent la casse. Toute vérification peut être inversée pour signifier ne pas. Vous pouvez donner plusieurs valeurs à une vérification ; elle est alors remplie dès que l'une d'elles correspond.

Quelques limites :

• Un motif peut contenir au plus trois * (** compte pour un). Un motif qui en contient davantage est refusé à l'enregistrement de la règle. Utilisez plutôt contains, qui n'a pas de limite.
• Un motif n'examine que les 300 premiers caractères d'un texte long, comme un long prompt. Pour trouver un mot n'importe où dans un long message, utilisez contains.
• File path nécessite un outil qui désigne un fichier, comme une modification. Une commande shell n'en désigne pas : une règle avec une vérification File path ne s'applique donc pas aux appels Bash. Pour couvrir les commandes shell, vérifiez plutôt Tool input.
• Dans un worktree git lié, Working directory est le dossier du dépôt principal, tandis que File path et Git branch suivent le worktree dans lequel vous vous trouvez. Écrivez un motif File path en fonction du dossier que vous visez réellement.

Ce qui peut être vérifié, et quand

Une règle peut parvenir à votre agent à deux moments : à chaque prompt, et juste avant un appel d'outil. Toutes les vérifications n'ont pas de sens aux deux moments.

Vérification	Avant un appel d'outil	À un prompt
Tool name, File path, Tool input	vérifiée	rien à vérifier ; la règle est laissée de côté
Prompt text	rien à vérifier ; la règle est laissée de côté	vérifiée
Working directory, Git branch	vérifiée	vérifiée
Model	vérifiée	vérifiée

Si votre harnais d'agent (harness), c'est-à-dire l'agent de code que vous utilisez (Claude Code, l'application de bureau Claude, Oh-My-Pi), ne transmet pas le dossier de travail ou la branche, cette vérification est confiée à votre agent, qui connaît son propre dossier et sa propre branche. Si votre harnais ne transmet pas le modèle, une règle avec une vérification Model ne s'applique pas, et la question n'est pas posée à votre agent.

Après les vérifications, chaque règle se retrouve dans l'un de ces trois états :

• Toutes les conditions sont remplies : la règle s'applique.
• Une vérification a renvoyé faux : la règle est laissée de côté sans bruit et n'occupe aucune place dans le contexte de votre agent.
• Quelque chose reste indécis (généralement une appréciation) : votre agent reçoit le nom de la règle avec les conditions qu'il lui reste à trancher, et lit la règle si elles sont remplies.

Pour qu'une règle reste silencieuse là où elle n'a pas sa place, donnez-lui donc une vérification qui y est fausse. Par exemple, une règle avec Tool name is Bashet « la commande touche à la production » est laissée de côté à chaque lecture de fichier, avant même que l'appréciation soit soumise à votre agent.

Règles pour un seul modèle

Une vérification Model limite une règle au modèle d'IA qu'utilise votre agent, par exemple « seul le modèle le plus puissant peut lancer une migration ». Elle compare avec le nom du modèle exactement tel que votre harnais le transmet, en minuscules. Les harnais ne l'écrivent pas tous de la même façon :

Harnais	Façon de nommer le modèle	Exemple
Claude Code	le nom du modèle seul	claude-opus-5
Oh-My-Pi	fournisseur/modèle	anthropic/claude-fable-5-1

Ainsi, claude-* correspond à tous les modèles Claude sur Claude Code, et */claude-* à tous ceux d'Oh-My-Pi. Le tableau de bord propose des valeurs parmi les modèles qu'il a déjà vus dans ce profil. Le modèle est vérifié à chaque requête : si vous changez de modèle en cours de session, la règle commence ou cesse de s'appliquer avec ce changement.

Règles épinglées

Réglez Delivery priority sur Pinned pour une règle qui ne doit jamais être manquée. Une règle épinglée ignore ses appréciations et s'applique dès que ses vérifications sont remplies ; une règle épinglée sans vérification s'applique partout. Elle respecte tout de même ses vérifications : une règle épinglée avec Tool name is Bash ne s'applique qu'aux appels Bash, et une règle avec une vérification Model ne s'applique que lorsque ce modèle est en cours d'utilisation. Les règles épinglées sont listées en premier. Épinglez avec parcimonie.

Comment une règle parvient à votre agent

Votre agent reçoit les noms des règles qui s'appliquent, ainsi que l'appel read_rules exact qui récupère leur texte complet. Le texte lui-même n'est jamais envoyé d'office. C'est pourquoi le titre compte : c'est ce que voit votre agent et ce par quoi il récupère la règle.

À chaque prompt

Chaque prompt est accompagné d'un court bloc qui liste par titre les règles applicables et fournit l'appel read_rules pour les récupérer. Il rappelle aussi à votre agent que seules les règles approuvées sont contraignantes, et qu'une règle dont une condition reste indécise doit être vérifiée avant d'être appliquée.

Les règles que votre agent a déjà récupérées pendant la session sont listées à part de celles qu'il doit encore lire, avec la consigne de continuer à les suivre et de les récupérer de nouveau si leur texte n'est plus sous ses yeux. Neuronz.ai ne peut enregistrer que ce qu'il a envoyé, pas ce que votre agent a encore en tête, et rien de tout cela n'oblige un modèle à obéir : cela garantit seulement que le texte complet est toujours à un appel de distance.

Votre agent est invité à relire une règle quand :

• Vous la modifiez. Changer son texte, son titre, ses conditions ou son épinglage la replace dans la liste « à lire » au prompt suivant.
• La session est compactée. Claude Code et Oh-My-Pi signalent tous deux la fin d'une compaction. Après une compaction, le prompt suivant demande à votre agent de relire toutes les règles applicables.
• La session est nouvelle, ou change de profil. Ce qui a été récupéré est suivi par session et par profil.

Juste avant un appel d'outil

Dans Claude Code (y compris l'onglet Code de l'application de bureau Claude), les règles qui s'appliquent à l'appel d'outil sur le point de s'exécuter sont nommées à ce moment-là, avec l'appel read_rules, et votre agent est invité à les lire avant de poursuivre. Les règles épinglées sont nommées à chaque appel correspondant ; les autres le sont la première fois qu'elles correspondent dans une session, puis de temps à autre. S'il y en a trop pour toutes les lister, le message le signale au lieu de raccourcir la liste en silence.

Ce n'est pas disponible sur Oh-My-Pi, ni dans les conversations et les tâches Cowork de l'application Claude ou de claude.ai. Dans ces cas, les règles arrivent par le bloc envoyé à chaque prompt. Voir les fonctions par harnais (en anglais).

Exemple

Vous ajoutez une règle « ne jamais pusher sur main », avec Tool name is Bashet « la commande est un git push vers main ». Plus tard, quand votre agent s'apprête à utiliser le shell dans Claude Code, Neuronz.ai tranche lui-même la première condition et transmet à votre agent le nom de la règle et la seconde condition, juste avant l'étape. À chaque lecture de fichier entre-temps, la première condition est fausse et la règle n'est jamais envoyée.

Détecter une règle que vous avez déjà

Quand une nouvelle règle dit presque la même chose qu'une règle active que vous avez déjà, Neuronz.ai refuse de l'enregistrer et nomme la règle existante. Cette vérification est activée par défaut. Elle ne se déclenche que lorsque les deux règles sont des paraphrases presque mot pour mot, pas lorsqu'elles partagent seulement du vocabulaire, et elle indique à quel point elles étaient proches.

Votre agent vous soumet la question. C'est vous qui décidez : modifier la règle existante, ou confirmer que la nouvelle est vraiment différente, auquel cas votre agent l'enregistre malgré tout. La modification d'une règle existante n'est jamais remise en cause, et aucune règle que vous avez déjà approuvée n'est modifiée.

Outils MCP

Votre agent lit et écrit les règles avec read_rules, propose_rule, create_rule, update_rule et delete_rule, et enregistre votre réponse à une proposition avec resolve_rule_ask. Voir Outils MCP.

Voir aussi

• Briefing de début de session : la liste de règles avec laquelle une session s'ouvre.
• Mémoire persistante : les faits, qui ne priment jamais sur une règle.