Home › Rules › Antigravity rules

Google Antigravity rules: 8 copy-paste examples, triggers and where the files go

Based on the Google Antigravity docs (Rules, Skills, Workflows), checked Oct 20, 2026. Sources below.

• Formats
• Antigravity
• Gemini

Short answer: Google Antigravity reads rules from plain AGENTS.md or GEMINI.md files (always on, no header needed) and from one-rule-per-file Markdown files in .agents/rules/. Each file in .agents/rules/ must start with a short YAML header whose trigger is exactly always_on, model_decision, glob or manual; a missing or misspelled trigger means Antigravity silently ignores the file. Global rules go in ~/.gemini/. And if you used Antigravity workflows: Antigravity's docs say the current workflows stop working on October 19, 2026, and point you to skills instead (below). Here are 8 rules you can copy.

Where Antigravity rules go

Rules add up rather than replace each other: Antigravity combines global, workspace and folder rules into one prompt, and when two rules conflict, the more specific folder rule wins. When the agent reads or edits a file, it walks up from that file's folder to the project root and loads the rules it finds on the way. The same locations work in the Antigravity app, the IDE and extensions, and the CLI.

Prefer clicking? In the app or IDE, open Customizations, go to the Rules tab and click + Workspace (this project) or + Global (every project).

The 4 triggers (activation modes)

8 Antigravity rules examples

1. A starter AGENTS.md (always on, no header)

# Project
A habit tracker web app for beginners. Next.js (App Router), TypeScript, Tailwind CSS, Supabase for the database and login.

# How to work with me
- I'm new to coding. Explain what you're about to change in plain English before you change it.
- Work in small steps. After each step, tell me exactly how to test it in the browser.
- Ask before changing the database, login, or anything to do with payments.

# Code rules
- Reuse components in src/components before making new ones.
- Tailwind classes only. No inline styles.
- Never put secret keys in front-end code.

# Commands
- Run locally: npm run dev
- Check before you say you're done: npm run lint and npm run build

No header needed. Cursor, Codex and GitHub Copilot's agent read AGENTS.md too, so this one file covers several tools. Want one made for your project type? Try the free generator.

2. A short always-on rule (always_on)

---
trigger: always_on
description: "Beginner-friendly working style for this project."
---

- Explain every change in plain English before making it.
- Make the smallest change that works. Don't refactor code I didn't ask about.
- When you finish, list what changed and how I can check it.

3. Ask before touching the database (model_decision)

---
trigger: model_decision
description: "Use whenever writing or changing database tables, migrations, row-level security or login code."
---

# Database rules
1. Explain the change in plain English and what could break.
2. Show me the migration before running it. Wait for my OK.
3. Never turn off row-level security.
4. Never drop a table or column without asking twice.

Only the description sits in context until a task needs the rule, so a long rule costs little the rest of the time. Write the description with the words you'd actually use when asking.

4. Test files (glob)

---
trigger: glob
globs: "*.test.ts, *.test.tsx"
description: "How to write tests in this project."
---

- One behavior per test, named in plain English: it("shows an error when the email is empty").
- Mock Supabase and outside APIs. Tests must not need the internet.
- After changing a test, run npm test and show me the result.

Separate patterns with commas and wrap them in quotes: Antigravity's docs warn that YAML treats a bare * at the start as something else.

5. Pre-launch checklist (manual)

---
trigger: manual
description: "Pre-launch checklist. Only when I @-mention it."
---

Go through this list one item at a time and tell me pass or fail for each:
1. No secret keys in front-end code or committed .env files.
2. Row-level security is on for every table that holds user data.
3. Every page has a title and meta description.
4. The site works on a phone-sized screen.
5. npm run build finishes with no errors.
Don't fix anything until I say which items to fix.

@-mention it when you're ready to ship. The full list of what to check is in the vibe coding security checklist.

6. A global rule for every project (modular global rule)

---
trigger: always_on
description: "My personal working style for every project."
---

- I'm a beginner. Use plain English and explain new terms the first time.
- Never delete files or run commands that remove data without asking me first.
- Ask before installing new packages.

Files in ~/.gemini/config/rules/ need the header. If you'd rather skip it, put the same bullets in ~/.gemini/AGENTS.md, which is always on.

7. Pull in another file (@ includes)

# Project rules
Short overview and the most important rules go here.

Follow our style guide:
@[Style guide](docs/style-guide.md)

When changing the database, check @supabase/schema.sql first.

@[label](path) pastes the other file's contents into the rule (paths are relative to the rule file). A plain @path doesn't paste anything; it just gives the agent an exact file to look at. Gemini CLI uses a different syntax (@./file.md), see GEMINI.md examples.

8. Rules in subfolders (.agents/rules.json)

{
  "entries": [
    { "path": "rules", "include_only": ["frontend/react.md"] }
  ]
}

Antigravity only scans files directly inside .agents/rules/. A file like .agents/rules/frontend/react.md is ignored unless you list it in .agents/rules.json, like this. The same file can also pull in rules shared between projects.

Antigravity rules and workflows: workflows are now skills

Antigravity's docs put it this way: write a rule for constraints ("always use zod for validation") and a skill for multi-step jobs ("how to run database migrations"). Workflows were saved step-by-step routines you ran with /workflow-name. Antigravity's docs say the current workflows stop working on October 19, 2026, and that instructions for a new workflows system will follow shortly after. Until then, the docs point you to skills: run /migrate-workflows in the Antigravity app and it turns each workflow in .agents/workflows/ (and ~/.gemini/config/workflows/) into a skill, renaming the old file to .bak. You still run it with /name.

---
name: deploy-check
description: Runs the pre-deploy checks for this project (lint, tests, production build) and reports pass or fail for each. Use before deploying or when asked if the app is ready to ship.
---

# Deploy check

Run these one at a time and report pass or fail for each:
1. npm run lint
2. npm test
3. npm run build
If something fails, explain why in plain English. Don't fix anything until I say so.

A skill is a folder with a SKILL.md inside; only its name and description load up front, and the rest loads when it's needed. Global skills go in ~/.gemini/config/skills/<name>/ (Antigravity CLI: ~/.gemini/antigravity-cli/skills/<name>/). Antigravity uses the open Agent Skills format, so the SKILL.md examples for Claude Code are a good starting point.

Rule not working? Check these

• Trigger spelling. always_on, not alwaysOn; model_decision, not modelDecision. A wrong value means the rule is silently dropped.
• Header present. Every file in .agents/rules/ and ~/.gemini/config/rules/ needs the --- header. AGENTS.md and GEMINI.md don't use one.
• Required fields. model_decision needs a description; glob needs globs.
• No subfolders. Files nested inside .agents/rules/ are ignored unless listed in rules.json (example 8).
• Size. Any single rule file is cut off at 24,000 bytes, and all global and always-on rules share a 20,000-token budget. Past that, Antigravity swaps the biggest files for pointers the agent only reads when it needs to. Keep always-on rules short.

Coming from Gemini CLI?

For unpaid and Google One users, Gemini CLI was replaced by Antigravity CLI on June 18, 2026. Antigravity's migration guide says your GEMINI.md and AGENTS.md files keep working with no changes, including ~/.gemini/GEMINI.md. Workspace skills are the exception: move them from .gemini/skills/ to .agents/skills/. More on that file: GEMINI.md examples.

Related

• GEMINI.md examples (Gemini CLI and Antigravity)
• SKILL.md examples (7 copy-paste skills)
• Windsurf rules examples (now Devin Desktop)
• Cursor rules examples (10 copy-paste .mdc rules)
• Vibe coding prompts cheat sheet
• Every rules file format
• Free rules file generator

Sources

• Google Antigravity docs: Rules
• Google Antigravity docs: Agent skills
• Google Antigravity docs: Workflows
• Google Antigravity docs: Migrate from workflows to skills
• Google Antigravity docs: Migrating from Gemini CLI
• Gemini CLI docs: GEMINI.md (replacement notice)

Checked Oct 20, 2026. These tools change often; if something here no longer matches, tell us at [email protected].