antigravity-cli-runtim…
Internal helper contract for calling the antigravity companion runtime from Claude Code
How to write effective prompts for Google Antigravity / Gemini 3.5 agents (used when delegating to or reviewing with the antigravity plugin)
$ npx -y skills add Idun-Group/antigravity-plugin-cc --skill gemini-3-prompting --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/gemini-3-promptingContext preview
The summary Claude sees to decide when to auto-load this skill.
How to write effective prompts for Google Antigravity / Gemini 3.5 agents (used when delegating to or reviewing with the antigravity plugin)
name: gemini-3-prompting description: "How to write effective prompts for Google Antigravity / Gemini 3.5 agents (used when delegating to or reviewing with the antigravity plugin)"
You drive `agy` (Antigravity, Gemini 3.5) in print mode through the companion's `delegate`, `review`, and `resume` subcommands. Print mode is headless: one prompt in, one result out. The agent cannot stop to ask you a clarifying question, so the prompt you send is the whole brief. Write it like a work order for a fast, literal junior engineer.
This guide is the short version. The depth lives in two reference files:
Based on Google's Gemini 3.5 developer/prompting guides and practitioner write-ups:
You do **not** pick the model in the prompt. There is no model flag on `agy` — the model is set with `/model` inside the TUI and persisted. Never instruct the agent to "use Gemini 3.5 Pro" or pass `-m`.
1. **Goal** — one sentence, the outcome you want. 2. **Acceptance criteria** — how *you* will know it's done (tests pass, endpoint returns X, build is green). This is what turns a vague request into a checkable one. 3. **Where to look** — the files, dirs, or modules that matter. Saves the agent a blind search and keeps it on target. 4. **Scope boundaries** — what NOT to touch (other modules, public API shape, formatting of unrelated files). Put these last. 5. **Output expectation** — code change only, or also a short summary of what changed and why.
Keep it tight. A focused 8-line brief beats a 40-line essay; over-stuffed context buries the actual ask.
`delegate` is **write-capable by default** — it can edit files and run commands. Choose deliberately:
| Use | When | |-----|------| | `--read-only` | Investigation, root-cause, "explain how X works," planning, anything where you want analysis without touching the tree. Safe to run unattended. | | `--sandbox` | You want it to *try* changes (run commands, scratch edits) but keep them contained from your real working tree. | | write-capable (default) | You actually want the fix/feature applied to the repo, and you'll review the diff after. |
`review` is already read-only and sandboxed — it never edits, it just reports on the diff.
If you're unsure whether a task should write, start `--read-only` to get the plan, then re-run write-capable (or `resume` the conversation) to apply it.
Drive Google's Antigravity CLI (agy, powered by Gemini 3.5) without leaving Claude Code. A Claude Code plugin that hands work to agy — Google's Antigravity CLI — and brings the result back into your session.
Repo: Idun-Group/antigravity-plugin-cc
Internal helper contract for calling the antigravity companion runtime from Claude Code
How to interpret Antigravity companion output — successful responses, quota/auth/backend errors, and applying file changes