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:
- The working folder is under Git (
git statusruns) - There are no uncommitted changes
- 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.
| Rung | What you ask | What can be touched | When to move up |
|---|---|---|---|
| 1 | Read and explain | Nothing changes | The explanation matches your own understanding |
| 2 | Write a new notes file | One designated folder only | You re-read the notes yourself |
| 3 | Edit one existing file | That one file | You can explain the diff |
| 4 | Run commands | Depends on the command | You can say what the approval prompt will do |
| 5 | Leave it running while you're away | Everything you've allowed | Rungs 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
;;
esacWhy 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/, withnotes/allowed: "Only the allowed area changed." - An unrelated
a.txtalso 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.