Global Rules for Antigravity Users: A Better Way to Work With AI Coding Agents

If you've ever worked with an AI coding agent like Antigravity across a real project, you've probably run into the same repeated problem: you keep re-typing the same instructions in every single prompt. "Don't hardcode values." "Cite the actual file and line." "Don't break existing tests." "Give me a table, not a wall of text." Eventually you realize these aren't one-off preferences — they're rules that should apply to every task, every time, without you having to restate them.

Here's a practical set of global rules that came out of exactly that realization, refined across several real review and refactor tasks on a production codebase. Set these once as your agent's standing context, and your day-to-day prompts can shrink down to just the task itself.

Why Global Rules Matter More Than Clever Prompts

A single well-written prompt only helps once. The moment you start a new session, or hand off a task to a teammate using the same agent, all of that context is gone unless it's written down somewhere the agent reads automatically. Global rules solve this by moving your defaults out of individual prompts and into a persistent file the agent treats as always-on instructions — commonly saved as an AGENTS.md or equivalent project-rules file.

The result is that every prompt you write afterward only needs to specify what's actually unique to that task: the target, the scope, and any exceptions. Everything else — how thorough the review should be, how fixes should be tested, how output should be formatted — is already handled.

The Rules Themselves

1. Expert Voice, Grounded Claims

Tell your agent to act as a senior domain expert for the task at hand, not a generic assistant. More importantly, require that every finding or recommendation cite a specific file, function, or line from your actual codebase. If the agent can't point to real evidence, it should say so instead of filling the gap with generic best-practice filler.

2. Exhaustiveness Over Sampling

Large codebases tempt agents into reviewing a representative sample and presenting it as complete. Explicitly forbid this. If the scope is too big for one pass, the agent should say so and propose a batching plan rather than silently skipping files.

3. No Fabrication

Facts, statistics, API behaviors, and quotes should never be invented. Anything ambiguous should be flagged as uncertain, not confidently guessed.

4. Preserve What Already Works

Fixes and rewrites should never break passing tests or established architecture as a side effect. Push your agent toward minimal, incremental changes, and require it to justify any full rewrite before proposing one. When migrating or regenerating content, treat the original files as read-only and write new output somewhere else entirely.

5. No Hardcoding

Values, secrets, model names, thresholds, and paths should stay config or environment driven, matching however your existing system already manages configuration.

6. Every Fix Needs Proof

No code change is complete without a corresponding test case. Require the agent to state exactly what existing behavior a fix must not break.

7. Security by Default

Even when not explicitly asked, every review should check for hardcoded secrets, injection risks, unsafe deserialization, missing input validation, and sensitive data leaking into logs.

8. Structured, Consistent Output

Ask for tables when comparing or listing findings, ranked lists for priorities, and named sections instead of long paragraphs. A good review should always end with a short summary, a findings table, and a prioritized remediation plan — in that order.

9. Resumability for Long Tasks

For anything too large for a single session, work in batches and save progress to a file immediately after each one. Keep a simple status table (done, in progress, pending) so a new session can pick up exactly where the last one stopped, without redoing finished work.

10. Verify Before Agreeing

If you propose a change or state something as already true — "the tests are passing," for instance — the agent should verify it against the actual code or test output rather than taking your word for it.

11. Scope Discipline

Known limitations or deliberately deferred features shouldn't get re-flagged as gaps unless you ask the agent to revisit them. Keep the agent focused on what was actually asked.

A Simple Template for Everyday Prompts

Once these rules are in place, most prompts reduce to four things: what the task is, where the scope lives, what's explicitly excluded, and where the output should go. Everything about thoroughness, safety, testing, and formatting is already covered by the standing rules, so you stop re-explaining the same expectations every single time you open a new session.

The Bigger Payoff

The real value of a rules file like this isn't just saving keystrokes. It's consistency. When an agent applies the same standards to every review — the same rigor about citing evidence, the same insistence on test coverage, the same refusal to fabricate or hardcode — you can actually trust its output enough to act on it directly, instead of re-verifying everything yourself afterward. For anyone running serious development work through an AI agent, that trust is the entire point.