◉ANTIGRAVITY LABJP
Articles/Antigravity Basics
◉ Antigravity Basics/2026-10-31Beginner

Ask It to Only Read on Day One: A Five-Step Ladder for What to Hand Antigravity

What to ask Antigravity on your first day, and what to hold back. A five-step ladder that widens the agent's scope from least to most breakable, plus a small shell script that counts what actually changed before and after a session.

Antigravity409getting startedagents150Git13beginner17

I was reviewing the store text for one of my wallpaper apps the night before a release. On impulse, I asked a freshly installed agent to "tidy this text and fix all the translations too." The reply came back fast, and the screen filled with a list of changes. By the next morning, I could no longer explain which files had changed or why.

The agent wasn't at fault. My request had outgrown what I was able to check.

This article walks through what to ask on your first day with Antigravity and what to hold off on, as a five-step ladder. It works even if you don't write code.

Decide this first: make the work reversible

The first thing I'd suggest isn't a clever prompt. It's a way back.

If the folder is under Git, anything the agent changes can be undone. If it isn't, take at least one full copy of the folder. If you prefer the in-app route, Antigravity Checkpoints & Rollback Mastery covers checkpoints, though Git travels with you across tools.

Before touching anything, check three things:

  1. The working folder is under Git (git status runs)
  2. There are no uncommitted changes
  3. Anything important also exists as a copy outside the folder

When all three hold, I call it "having a footing."

The ladder: widen scope from least to most breakable

Don't widen the scope all at once. The table below is how I split it. The higher the rung, the harder a mistake is to undo.

RungWhat you askWhat can be touchedWhen to move up
1Read and explainNothing changesThe explanation matches your own understanding
2Write a new notes fileOne designated folder onlyYou re-read the notes yourself
3Edit one existing fileThat one fileYou can explain the diff
4Run commandsDepends on the commandYou can say what the approval prompt will do
5Leave it running while you're awayEverything you've allowedRungs 1–4 have run cleanly a few times

On day one, rungs 1 and 2 are plenty. Rung 3 and above can wait until tomorrow without costing you anything.

Rung 1: read and explain

Make the first request contain no writing at all:

Read this folder's structure and explain in five lines what the project is for.
Do not change any file. Read only.

Compare the answer with what you already believe about the project. If they differ, either the agent misread it or the folder is poorly organized. Either way, you learned it before asking for any edits.

Writing "don't change anything" doesn't prove it was obeyed, so the next section gives you a way to check.

Rung 2: write a new notes file

Once rung 1 feels routine, allow writing, but only inside one new folder:

Only inside the notes/ folder, create notes/todo.md listing the TODOs you find.
Do not change anything outside notes/.

Existing files stay untouched, and the result is just a new note. If you dislike it, delete it. The cost of a mistake is close to zero.

Count what moved, before and after

Asking an agent to "stay inside this folder" is a request. What actually changed on disk is evidence. I trust the second.

This script marks your Git position before the session and, afterward, lists anything that changed outside the folder you allowed.

What it solves: it lists, within seconds, every file that moved beyond what you asked for.

#!/usr/bin/env bash
# session-guard.sh — count what the agent touched, before and after
# Usage: session-guard.sh before            # mark before the session
#        session-guard.sh after notes/      # after: warn if anything outside notes/ moved
set -euo pipefail
MARK=".git/agent-session-mark"
 
case "${1:-}" in
  before)
    if [ -n "$(git status --porcelain)" ]; then
      echo "Uncommitted changes found. Commit or stash first." >&2
      exit 1
    fi
    git rev-parse HEAD > "$MARK"
    echo "Marked: $(cut -c1-7 "$MARK")"
    ;;
  after)
    [ -f "$MARK" ] || { echo "Run 'before' first." >&2; exit 1; }
    allowed="${2:-}"          # prefix you allow to change; empty means "touch nothing"
    base=$(cat "$MARK")
    changed=$( { git diff --name-only "$base"; git ls-files --others --exclude-standard; } | sort -u )
    [ -z "$changed" ] && { echo "No changes. It was a read-only job."; exit 0; }
    echo "$changed" | sed 's/^/  changed: /'
    if [ -z "$allowed" ]; then outside="$changed"
    else outside=$(echo "$changed" | grep -v -- "^${allowed}" || true); fi
    if [ -n "$outside" ]; then
      echo "WARNING: files outside the allowed area moved:"
      echo "$outside" | sed 's/^/  outside: /'
      exit 2
    fi
    echo "Only the allowed area changed."
    ;;
  *)
    echo "usage: $0 before | after [allowed-prefix]" >&2; exit 64
    ;;
esac

Why it's written this way: git diff only sees tracked files, so newly created files are gathered separately with git ls-files --others. The exit codes are split into 0 (fine) and 2 (something outside), so you can drop it into automation later without rewriting it.

I ran it against a tiny test repository, and the results were:

  • Nothing requested: "No changes. It was a read-only job."
  • One file created under notes/, with notes/ allowed: "Only the allowed area changed."
  • An unrelated a.txt also modified: the outside file is named, and the exit code is 2

After a rung 1 request, "No changes" confirms the read-only promise held. For rung 2, pass notes/ as the allowed prefix.

When to climb: "I can explain it" is the condition

I don't climb by counting sessions. I climb when I can explain what happened.

  • Rung 2 to 3: can you re-read the notes and say they're correct?
  • Rung 3 to 4: can you read the diff (git diff) and say why it changed?
  • Rung 4 to 5: do you know what each command in the approval prompt does?

Climbing without that understanding leaves you where I was that first night, with changes you can't account for. If something isn't clear, ask the agent itself: "Explain this diff as if I'm new to this." Stay on the same rung until the explanation lands.

What to leave for later

A few things are worth skipping on day one:

  • Rewrites that span many files
  • Running commands you don't understand
  • Leaving something running while you're away
  • Anything that can't be taken back, such as publishing or sending

All of them are useful. Until you have a footing and can explain what changed, I think they're safer left on the shelf.

Ask for a little less than what you can verify. I plan to keep that line even as the features grow.

Your next step today

Run git status in your working folder and confirm you have a footing. Then make one rung 1 request and watch session-guard.sh after report "No changes." That is a complete first day. Pick up at rung 2 tomorrow.

Share

Thank You for Reading

Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.

  • ✦Copy-paste ready implementation code
  • ✦New advanced guides published daily
  • ✦$5/mo or $10 for lifetime access
View Membership →

If you found this article helpful, a small tip ($1.50) would mean a lot to us. Your support helps keep this site ad-free and covers server and hosting costs.

Related Articles

◉ Antigravity2026-10-15
Before You Press Delete on an Antigravity Project, Can You Name Three Things That Stay?
Does deleting a project in Antigravity 2.0 remove your source code? A community explanation, split into its two storage locations, plus a read-only script and a safe order for freeing disk space.
◉ Antigravity2026-04-25
Designing Antigravity Retry for Production — Idempotency, Backoff, Cost Ceilings, and Failure Triage
A production blueprint for Antigravity agent retry: idempotency, exponential backoff, token-budget ceilings, failure triage, and resumable checkpoints.
◉ Antigravity2026-10-28
When Antigravity Says Failed to Fetch: Decide the First Three Places to Look
A short triage order for Failed to Fetch in Antigravity: check whether the destination is reachable, whether you are still signed in, and whether a proxy or VPN sits in the middle. Includes copy-paste terminal checks and what each result means.