Google Antigravity Regeln: globale und projektbezogene Anweisungen einrichten

Was sind Antigravity Regeln?

Google Antigravity Regeln sind dauerhafte Anweisungen, Codestandards oder Architekturvorgaben, die der Agent aus Dateien erkennt und bei passenden Aufgaben berücksichtigt. Ein Chat-Prompt gilt normalerweise nur für ein Gespräch. Eine Regel wird als Kontext gespeichert und kann spätere Gespräche in dem Bereich beeinflussen, in dem Antigravity sie findet. Sie eignet sich für Entscheidungen, die du sonst regelmäßig wiederholst, etwa welche Tests laufen sollen, wie generierte Dateien behandelt werden oder welche Datenbankkonventionen ein Projekt verwendet.

Eine gute Konfiguration der Google Antigravity Regeln beantwortet drei Fragen: Für welche Aufgaben gilt die Anweisung, was soll der Agent tun und welche Grenze muss er einhalten? Formuliere sie konkret genug zum Umsetzen und kurz genug zum Prüfen. Regeln erteilen keine pauschale Erlaubnis für beliebige Befehle oder externe Aktionen. Kontrolliere vorgeschlagene Änderungen, Shell-Befehle, Netzwerkzugriffe, Geheimnisse und destruktive Vorgänge weiterhin nach deinem üblichen Verfahren.

• Prompt Eine einmalige Bitte für das aktuelle Gespräch.
• Regel Eine dauerhafte Anweisung, die aus einer unterstützten Datei und ihrem Geltungsbereich geladen wird.
• Skill Ein wiederverwendbares Paket mit Abläufen und Ressourcen für eine Aufgabe; weitere Schritte stehen im separaten Antigravity Skills-Leitfaden.

Globalen, Workspace- oder Verzeichnisbereich wählen

Wähle den kleinsten Bereich, der alle betroffenen Personen und Projekte umfasst. Eine globale Regel folgt deinem Benutzerprofil in verschiedene Workspaces. Nutze sie deshalb nur für persönliche Einstellungen, die überall sicher gelten. Eine Workspace-Regel bleibt beim Repository und kann vom Team zusammen mit dem Code geprüft werden. Eine Verzeichnisregel ist sinnvoll, wenn ein Teil eines größeren Projekts eigene Konventionen hat, die andere Ordner nicht betreffen sollen.

Google Antigravity Regeln wirken kumulativ: Antigravity sammelt erkannte Anweisungen, statt jede neue Datei als Ersatz für frühere Vorgaben zu behandeln. Bei einem Konflikt haben die spezifischeren Verzeichnisregeln Vorrang. Vermeide widersprüchliche globale und Repository-Anweisungen und beschreibe lokale Ausnahmen ausdrücklich. Die Tabelle zeigt die aktuell für die Antigravity App dokumentierten Speicherorte.

Eine Regel in der Antigravity App anlegen

Öffne in der Antigravity App das Customizations-Panel über das Anwendungsmenü oder die Projekteinstellungen. Wechsle zum Tab Rules und wähle je nach Bedarf + Global oder + Workspace. Die App erstellt eine dateibasierte Regel, die du lesen und bearbeiten kannst. In der IDE- oder CLI-Oberfläche können die Bedienelemente anders aussehen. Orientiere dich dort an den dokumentierten Dateipfaden und den Hinweisen für die jeweilige Oberfläche.

Beginne bei einer Repository-Regel mit einer wiederkehrenden Entscheidung und nicht mit einem allgemeinen Manifest. Nenne die betroffenen Dateien oder Aufgaben, das gewünschte Verhalten und eine Prüfmöglichkeit. Eine überprüfbare Vorgabe wie „Führe nach Änderungen am Parser die passenden Unit-Tests aus“ ist hilfreicher als „Sei vorsichtig“. Halte projektspezifisches Wissen in der Repository-Regel, damit andere Mitwirkende es zusammen mit dem Code prüfen und aktualisieren können.

1. Bereich wählenLege fest, ob die Anweisung zum Benutzerprofil, Workspace oder Unterverzeichnis gehört.
2. Rules öffnenÖffne in der App Customizations und dann Rules; erstelle einen Eintrag für Global oder Workspace.
3. Ein Verhalten festhaltenBeschreibe Zweck, betroffene Aufgaben, erforderliche Aktion und eine sinnvolle Prüfung.
4. Datei prüfenBestätige den gespeicherten Pfad und lies den endgültigen Text, bevor du dich darauf verlässt.

Frontmatter und Aktivierungsmodi konfigurieren

Eigenständige AGENTS.md- und GEMINI.md-Dateien verwenden kein Frontmatter. Ihr Markdown-Inhalt bleibt im jeweiligen Verzeichnisbereich dauerhaft aktiv. Jede modulare Markdown-Datei in einem rules/-Ordner muss mit YAML-Frontmatter und einem gültigen Trigger beginnen. Der Trigger bestimmt, wann die Regel in den Kontext geladen wird. Wähle ihn passend dazu, wie vorhersehbar und häufig die betroffenen Aufgaben sind.

Nutze always_on für kurze Vorgaben, die bei jeder Anfrage im Bereich präsent sein sollen. model_decision eignet sich für umfangreichere Hinweise, die der Agent nur bei passender Beschreibung öffnen soll. glob aktiviert die Regel anhand von Dateimustern und benötigt das Feld globs. manual lädt sie nur nach einer ausdrücklichen @-Erwähnung. Die aktuelle Dokumentation nennt diese vier Trigger-Werte.

---
trigger: glob
globs: "*.ts, *.tsx"
description: "Diese Konventionen bei Änderungen an TypeScript-Dateien anwenden."
---

# TypeScript-Änderungen

- Exportierte Funktionen typisieren.
- Nach der Änderung den passenden TypeScript-Test ausführen.
- Generierte Dateien nicht von Hand bearbeiten.

Die Anwendung einer Regel überprüfen

Eine gespeicherte Datei beweist noch nicht, dass die gewünschte Anweisung geladen wurde. Teste die Regel mit einer kleinen, risikoarmen Anfrage, die eindeutig in ihren Bereich fällt. Verwende bei einer glob-Regel eine Datei, die dem Muster entspricht, und eine ähnliche Datei, die nicht dazu passt. Bei manual rufst du die Regel einmal ausdrücklich mit @ auf und vergleichst das Ergebnis mit einer Aufgabe ohne Erwähnung. Halte den Test eng begrenzt, damit der Einfluss der Regel erkennbar bleibt.

Achte bei der Auswertung auf das konkrete Verhalten, das du festgelegt hast, statt nur auf den Eindruck, der Agent sei allgemein vorsichtiger. Prüfe geänderte Dateien und Befehle. Fehlt das erwartete Verhalten, kontrolliere Pfad, Workspace-Stamm, Schreibweise des Frontmatters, Trigger, glob-Muster und mögliche überschreibende Verzeichnisregeln. Ändere jeweils nur eine Ursache und wiederhole denselben Test, damit die Wirkung nachvollziehbar ist.

1. Klare Aufgabe auswählenNutze eine kleine Aktion, auf die sich die Regel auswirken soll, und vermeide riskante Änderungen.
2. Grenze prüfenVergleiche bei dateibezogenen Regeln eine passende mit einer nicht passenden Datei.
3. Belege ansehenVergleiche Antwort, Befehle, geänderte Dateien und Testergebnis mit der Regel.
4. Nach Änderungen wiederholenÄndere ein Detail zu Bereich oder Trigger und führe dieselbe Prüfung erneut aus.

Regeln untersuchen und aktuell halten

Wenn Google Antigravity Regeln scheinbar ignoriert, prüfe zuerst, ob die Datei im aktiven Workspace und an einem unterstützten Speicherort liegt. Kontrolliere anschließend den exakten Dateinamen, die Schreibweise .agents und YAML-Trennzeichen sowie Einrückungen. Eine modulare Regel ohne gültigen Trigger wird möglicherweise nicht wie erwartet geladen. Teste glob mit einem sicher passenden Pfad und überprüfe die Anführungszeichen. Eine manual-Regel braucht eine ausdrückliche @-Erwähnung und wird nicht automatisch aktiviert.

Für Regeln gelten auch Kontextgrenzen. Laut Dokumentation ist eine Regeldatei nach dem Einfügen referenzierter Dateien auf 24 KB begrenzt. Aktive globale und always_on-Regeln teilen sich außerdem ein Gesamtbudget von 20.000 Tokens. Wird es überschritten, können die größten Dateien auf einen Verweis mit Pfad und Beschreibung reduziert werden. Halte always_on kurz, lagere längere Referenzen in eine model_decision-Regel aus und beschreibe in description, wann der Agent sie öffnen soll.