Écrire des règles pour l'agent

Vous ouvrez cette page parce que vous répétez la même consigne à chaque conversation — la convention de nommage du projet, le framework de test à utiliser, l’interdiction de toucher un dossier. Une règle est un fichier qui porte cette consigne à votre place.

La règle qui s’applique à tout le dépôt

Créez un fichier AGENTS.md à la racine du dépôt :

# Conventions du projet

- Les tests utilisent Vitest, jamais Jest.
- Aucun accès réseau dans un test.
- Les messages d'erreur sont en français.

Ce fichier est chargé sans condition : son contenu est joint à chaque requête, quel que soit le fichier ouvert. Un front-matter y est sans effet sur ce point — le chargement force l’application systématique.

Dans lemni, la commande /init fait analyser le dépôt et écrire ce fichier, ce qui donne un point de départ plus rapide qu’une page blanche. Elle produit aussi une règle appelable, .lemniscate/rules/review.md :

/init

Un seul fichier d’agent est retenu. Sur un espace de travail à plusieurs dossiers, c’est celui du premier dossier qui en porte un.

Ce qui est réellement lu, et ce qui est annoncé

Le code annonce trois noms de fichier d’agent — AGENTS.md, AGENT.md et CLAUDE.md. Dans l’IDE, seul AGENTS.md est lu : la boucle de recherche s’interrompt après le premier nom, qu’il existe ou non, et les deux autres ne sont jamais essayés. Sous lemni, qui a son propre code de lecture, les trois noms fonctionnent, ainsi que CODEX.md.

Un CLAUDE.md posé à la racine se comporte donc de façon différente selon l’endroit d’où vous travaillez. Le comportement à retenir : nommez le fichier AGENTS.md, c’est le seul nom qui vaut partout. Si vous partez d’un dépôt qui porte déjà un CLAUDE.md, renommez-le, ou faites-en un lien.

Effet de bord à connaître : enregistrer un CLAUDE.md dans l’IDE déclenche un rechargement de la configuration, alors que son contenu ne sera pas chargé. Le rechargement n’est donc pas la preuve que la règle est prise en compte.

La règle qui ne vaut que pour certains fichiers

Une règle ciblée vit dans .lemniscate/rules/, en .md, avec un front-matter qui dit à quoi elle s’applique. Les sous-dossiers sont parcourus.

---
name: Composants React
description: Conventions des composants de l'interface
globs:
  - "gui/src/components/**/*.tsx"
---

- Un composant par fichier, exporté nommément.
- Aucun appel réseau dans un composant : passer par un hook.

Les mêmes fichiers sont cherchés dans ~/.lemniscate/rules/, ce qui permet de poser des règles personnelles valables sur tous vos dépôts sans les committer.

Champs reconnus dans le front-matter :

Champ	Effet
name	le nom affiché ; à défaut, les deux derniers segments du chemin
description	une phrase, à destination du modèle
globs	les fichiers concernés — une chaîne ou une liste
regex	une expression régulière sur le contenu
alwaysApply	force l’application, ou l’empêche
invokable	fait de la règle une commande à appeler, non une règle permanente

Un front-matter dont le YAML est invalide est ignoré sans erreur : le fichier entier devient le corps de la règle, et les globs que vous croyiez avoir posés n’existent pas. Une règle qui s’applique partout alors qu’elle visait un dossier se diagnostique là.

Les deux combinaisons qui surprennent

Sans globs, sans regex et sans alwaysApply, la règle s’applique toujours. Un fichier déposé dans .lemniscate/rules/ sans front-matter est donc une règle globale, pas une règle inerte.

alwaysApply: false sans globs ni regex donne une règle qui ne s’applique jamais. Il n’y a plus rien pour la déclencher. C’est la façon la plus discrète de désactiver une règle en croyant l’assouplir.

La règle attachée à un dossier

Un fichier nommé exactement rules.md, dans n’importe quel dossier du dépôt, s’applique aux fichiers de ce dossier et de ses sous-dossiers. Il n’y a rien à déclarer : l’emplacement fait le ciblage.

core/llm/rules.md

Des globs posés dans un tel fichier sont interprétés relativement à son dossier, pas à la racine du dépôt. Et parce que le ciblage est toujours présent, une règle colocalisée ne devient jamais globale.

Écrire la règle dans le fichier de configuration

Le bloc rules de config.yaml accepte une consigne en clair, ou un objet :

name: Local Config
version: 1.0.0
rules:
  - Répondre en français.
  - name: Pas de secrets
    rule: Ne jamais écrire de clé d'API dans un fichier suivi par git.
    globs: "**/*.ts"

Sous la forme objet, name et rule sont tous deux obligatoires.

Le champ regex ne fonctionne pas ici. Il est accepté par le schéma, puis perdu à la conversion : une règle du bloc rules déclenchée par regex ne se déclenchera jamais, sans le moindre message. Dans un fichier Markdown de .lemniscate/rules/, ce même champ fonctionne. Utilisez cette seconde forme dès que vous avez besoin de regex.

Vérifier qu’une règle est prise en compte

Dans l’IDE, l’enregistrement d’un fichier de règles recharge la configuration : la règle est active à la requête suivante, sans redémarrage. lemni lit les règles au démarrage de la session.

Le contrôle le moins ambigu reste de poser dans la règle une consigne dont l’effet est visible dans la réponse — une formule imposée, un refus attendu — et de la demander. Une règle qui ne change rien à la réponse n’est pas chargée.