Règles de Google Antigravity : configurer des consignes globales et de projet

Que sont les règles Antigravity ?

Les règles de Google Antigravity sont des consignes persistantes, des conventions de code ou des contraintes d’architecture que l’agent trouve dans des fichiers et applique aux tâches concernées. Un message de chat vise une conversation. Une règle est enregistrée comme contexte et peut influencer les conversations suivantes dans sa portée. Elle convient aux décisions récurrentes, comme les tests, les fichiers générés ou les conventions de base de données du projet.

Une configuration utile des règles de Google Antigravity précise les tâches concernées, le comportement attendu et les limites à respecter. Soyez précis et concis. Une règle n’autorise pas automatiquement toutes les commandes ou opérations externes ; continuez d’examiner les changements, l’accès réseau, les secrets et les actions destructrices selon votre processus habituel.

• Message Une demande ponctuelle pour la conversation en cours.
• Règle Une consigne persistante découverte dans un fichier et une portée pris en charge.
• Skill Un ensemble réutilisable de procédures et de ressources pour une tâche ; consultez le guide Antigravity Skills dédié.

Choisir une portée globale, de projet ou de dossier

Choisissez la portée la plus étroite qui couvre les personnes et les projets concernés. Une règle globale suit votre profil utilisateur entre espaces de travail ; réservez-la donc aux préférences personnelles sûres partout. Une règle d’espace de travail reste avec le dépôt et peut être revue par l’équipe avec le code. Une règle de dossier est utile lorsqu’une partie d’un grand projet suit des conventions qui ne doivent pas s’appliquer aux autres dossiers.

Les règles de Google Antigravity sont cumulatives : Antigravity rassemble les consignes découvertes au lieu de traiter chaque nouveau fichier comme un remplacement. En cas de désaccord, les règles de dossier les plus précises ont priorité. Évitez les contradictions entre les consignes globales et celles du dépôt ; documentez explicitement toute exception locale. Le tableau présente les emplacements actuellement décrits pour l’application Antigravity.

Créer une règle dans l’application Antigravity

Dans l’application Antigravity, ouvrez le panneau Customizations depuis le menu de l’application ou les paramètres du projet, sélectionnez l’onglet Rules, puis choisissez + Global ou + Workspace selon la portée souhaitée. L’application crée une règle basée sur un fichier que vous pouvez relire et modifier. Dans les interfaces IDE ou CLI, suivez les emplacements documentés et consultez les instructions propres à chaque surface, car les commandes peuvent différer.

Pour une règle de dépôt, partez d’une décision récurrente plutôt que d’un manifeste général. Indiquez les fichiers ou tâches concernés, le comportement attendu et une façon de le vérifier. Une consigne vérifiable, comme « exécuter les tests unitaires ciblés après une modification du parseur », est plus utile que « rester prudent ». Gardez les faits propres au projet dans la règle du dépôt afin que les autres contributeurs puissent les examiner et les mettre à jour avec le code.

1. Choisir la portéeDécidez si la consigne relève de votre profil, de l’espace de travail ou d’un sous-dossier.
2. Ouvrir RulesDans l’application, ouvrez Customizations puis Rules et créez une entrée Global ou Workspace.
3. Décrire un comportementPrécisez l’objectif, les tâches concernées, l’action attendue et un contrôle utile.
4. Relire le fichierConfirmez le chemin enregistré et relisez le texte final avant de vous y fier.

Configurer le frontmatter et les modes d’activation

Les fichiers autonomes AGENTS.md et GEMINI.md n’utilisent pas de frontmatter. Leur contenu Markdown reste actif dans la portée du dossier. Chaque fichier Markdown modulaire dans un dossier rules/ doit commencer par un frontmatter YAML contenant un trigger valide. Ce trigger définit le chargement de la règle ; choisissez-le selon la prévisibilité et la fréquence des tâches concernées.

Utilisez always_on pour une courte consigne qui doit être présente à chaque tour dans sa portée. Choisissez model_decision pour un guide plus long que l’agent doit ouvrir lorsque sa description correspond à la tâche. Le mode glob dépend des motifs de fichiers et exige le champ globs. Le mode manual ne charge la règle qu’après une mention explicite avec @. La documentation actuelle décrit ces quatre valeurs de trigger.

---
trigger: glob
globs: "*.ts, *.tsx"
description: "Appliquer ces conventions lors de la modification de fichiers TypeScript."
---

# Modifications TypeScript

- Typez les fonctions exportées.
- Lancez le test TypeScript ciblé après la modification.
- Ne modifiez pas les fichiers générés à la main.

Vérifier qu’une règle s’applique

Un fichier enregistré ne prouve pas que la consigne prévue a été chargée. Testez la règle avec une demande à faible risque qui correspond clairement à sa portée. Pour une règle glob, utilisez un fichier qui correspond au motif et un fichier proche qui n’y correspond pas. Pour une règle manual, mentionnez-la explicitement une fois et comparez le résultat avec une tâche sans mention. Gardez la tâche assez petite pour observer l’influence de la règle.

Lors de la revue, cherchez le comportement précis décrit dans la règle plutôt qu’une impression générale de prudence. Examinez les fichiers modifiés et les commandes. Si le comportement attendu est absent, vérifiez le chemin, la racine de l’espace de travail, l’orthographe du frontmatter, le trigger, le motif glob et l’éventuelle présence d’une règle plus précise. Changez un seul facteur à la fois, puis répétez le même test pour voir si la correction a produit un effet.

1. Choisir une tâche claireUtilisez une action limitée qui devrait être influencée et évitez les changements risqués.
2. Vérifier la frontièrePour une règle de fichier, comparez un fichier correspondant avec un fichier non correspondant.
3. Examiner les preuvesComparez la réponse, les commandes, les fichiers modifiés et les tests avec la règle.
4. Recommencer après modificationChangez un détail de portée ou de trigger et relancez la même vérification.

Dépanner et entretenir les règles

Si les règles de Google Antigravity semblent ignorées, vérifiez d’abord que le fichier se trouve dans l’espace de travail actif et dans un emplacement pris en charge. Contrôlez ensuite le nom exact, l’orthographe .agents, les délimiteurs YAML et l’indentation. Une règle modulaire sans trigger valide risque de ne pas se charger comme prévu. Pour glob, testez un chemin censé correspondre et vérifiez les guillemets du motif. Une règle manual exige une mention explicite avec @ ; elle n’est pas conçue pour se déclencher automatiquement.

Les règles ont aussi des limites de contexte. La documentation indique une limite de 24 Ko par fichier après expansion des inclusions et un budget commun de 20 000 jetons pour les règles globales actives et les règles always_on. Si le budget total est dépassé, les fichiers les plus volumineux peuvent être remplacés par de simples pointeurs vers leur chemin et description. Gardez always_on court, déplacez les références détaillées dans une règle model_decision et expliquez dans description quand l’agent doit l’ouvrir.