Setting /goals
A skill that makes the agent state what it is trying to achieve before it touches anything — so you correct the aim instead of the output.
Why a goal command at all
The failure mode this fixes is specific. You ask for something, the agent starts editing, and forty seconds later you realise it understood the request differently than you meant it. Now you are reviewing a diff you did not want, and the cheapest thing to do is throw it away.
A goal command moves that discovery to the front. It costs one round trip and it makes the agent say, in its own words, what it thinks success looks like — before there is anything to throw away.
The shape is always the same:
restate the objective in one sentence
list what will be true when it is done
name what is explicitly out of scope
stop, and wait
Point four is the one people leave out, and it is the one that matters. A command that states a goal and then starts working has not bought you anything.
What goes in the file
Keep it short. A long command is a long prompt, and a long prompt gets summarised by the model before it gets followed. Three constraints do the work:
Force a single sentence for the objective. If it cannot be said in one, the task is two tasks and you have learned that early.
Demand an out-of-scope list. This is where a misread surfaces. The agent will cheerfully list "not touching the auth module" when the auth module was the entire point.
Forbid edits in the same turn. Otherwise the model will helpfully get started, which defeats the purpose.
One thing to get right before you write it
This is a command you invoke, never one the agent decides to run. That distinction is now something you can actually declare rather than hope for, and it matters here: a goal statement the agent volunteers mid-task is noise, because the point is that you stopped to check the aim.
In Claude Code
Skills live in .claude/skills/<name>/SKILL.md, and the directory name is the command name — so
this lands at /goals.
---
name: goals
description: State the objective and stop, before any edits
disable-model-invocation: true
---
Before doing anything else, answer in this exact shape:
**Objective** - one sentence. If it takes two, say so and stop.
**Done when** - the observable conditions that will be true. Not steps. Conditions.
**Not doing** - what is deliberately out of scope for this change.
Then stop. Do not read further files, do not propose a plan, do not edit anything.
Wait for me to confirm or correct the objective.
The request: $ARGUMENTS$ARGUMENTS is substituted with whatever follows the command, so /goals rework the billing retry
passes that string through. Drop the file in and it is available immediately — no restart.
disable-model-invocation: true is the important line. Without it, Claude can decide to run
this skill on its own when it thinks the situation calls for it. That is the opposite of what a
checkpoint is for. With it, the skill's description also stays out of context until you invoke it,
which costs you nothing the rest of the time.
Put the skill in .claude/skills/ inside the repo when the whole team should have it, and in
~/.claude/skills/ when it is a personal habit.
If you have an older
.claude/commands/goals.md, it still works. Custom commands were merged into skills, and a command file and a skill directory both produce/goals. The skill form is worth moving to for the frontmatter above and for a directory you can put supporting files in.
In Antigravity CLI
Skills are markdown files with frontmatter, and a registered skill becomes a slash command
automatically. For one that travels with the repo, create .agents/skills/ at the project root and
drop goals.md in it:
---
name: goals
description: State the objective and stop, before any edits
---
Before doing anything else, answer in this exact shape:
**Objective** - one sentence. If it takes two, say so and stop.
**Done when** - the observable conditions that will be true. Not steps. Conditions.
**Not doing** - what is deliberately out of scope for this change.
Then stop. Do not read further files, do not propose a plan, do not edit anything.
Wait for me to confirm or correct the objective.Run agy in that directory and /goals is available in the prompt box. For a personal habit rather
than a team one, the same file goes in ~/.gemini/antigravity-cli/skills/, which is imported into
every workspace. /skills lists what actually loaded, local and global.
Two things to watch. If you are migrating from Gemini CLI, the workspace path moved — skills used
to live in .gemini/skills/ and the docs are explicit that you have to relocate the folder to
.agents/skills/ by hand or the agent won't see them. The old TOML custom commands don't carry over
either; agy plugin import gemini converts them to skills for you.
The second is the very long context window: it has often read a lot of the repo before you ask, so its objective statement tends to be better informed and its out-of-scope list tends to be longer than you want. Trim it rather than trusting it.
Using it
Run it before the work, not after you are unhappy with the work:
On anything touching more than about three files. Below that, the cost of a wrong turn is lower than the round trip.
On anything where you are not certain you can describe the outcome yourself. If you cannot, the agent definitely cannot, and you want to find that out now.
Never on a mechanical edit. Asking for a goal statement before a rename is theatre.
The part people get wrong
The output of this is not documentation. Do not save it, do not paste it into the ticket, do not ask for it in a nice format. It is a checkpoint — you read it, you either correct it or you say go, and then it is done being useful.
If you find yourself keeping the goal statements, that is a signal your tickets are underspecified, and the fix belongs in the tickets.
.claude/skills/goals/SKILL.md---
name: goals
description: State the objective and stop, before any edits
disable-model-invocation: true
---
Before doing anything else, answer in this exact shape:
**Objective** - one sentence. If it takes two, say so and stop.
**Done when** - the observable conditions that will be true. Not steps. Conditions.
**Not doing** - what is deliberately out of scope for this change.
Then stop. Do not read further files, do not propose a plan, do not edit anything.
Wait for me to confirm or correct the objective.
The request: $ARGUMENTS