Good Gemini CLI prompts attach the right files with @, say what must not change, and end with a command Gemini can run to check its work. Below are 13 original prompts for Google's open source terminal agent, built on features its official docs describe: Plan Mode, @ file context, subagents, custom commands, GEMINI.md, skills and headless mode.
One thing to know first: Gemini CLI is no longer for everyone. The Gemini CLI README says free individual access and Google AI Pro and Ultra (Google One) "moved to Antigravity CLI on June 18, 2026." It now targets organizations with Gemini Code Assist Standard or Enterprise licenses or Code Assist for GitHub on Google Cloud, and Google's transition post says it stays accessible with paid Gemini and Gemini Enterprise Agent Platform API keys. If you are in one of those groups, these prompts apply as written. If not, see the Antigravity guide and the Antigravity CLI guide; the Gemini CLI guide has more background.
How to use these prompts
Paste a prompt into Gemini CLI and replace the blanks in double braces, or keep the default after the colon: {{test_command:npm test}} means npm test unless you change it.
The features these prompts rely on:
| Feature | What it does | How to reach it |
|---|---|---|
@path |
Reads a file into the prompt; for a folder, passes the path for Gemini to explore | Type @ and a path |
| Plan Mode | Read-only research and planning before edits | Shift+Tab, /plan, or --approval-mode=plan |
| Subagents | Specialists such as codebase_investigator with their own context |
Start the prompt with @agent_name |
! shell mode |
Runs a shell command from the prompt | !git status, or ! alone to toggle |
| GEMINI.md | Project instructions loaded into every prompt | /init to create, /memory show to inspect |
| Custom commands | Saved prompts as slash commands in TOML files | .gemini/commands/ |
| Checkpoints | Undo file changes made by a tool | /restore, after enabling checkpointing |
Git-ignored files such as node_modules/ and .env are skipped by @ by default, which keeps secrets out of the prompt.
How do you explore a codebase with Gemini CLI?
1. Summarize a folder
Point @ at a directory. Gemini gets the path and lists the files itself with its tools.
@{{folder:src/}} Explain this codebase to a developer joining today:
1. What the project does, in two sentences.
2. The main folders and what each one owns.
3. How {{flow:a request}} moves from {{entry_point:the router}} to the database.
4. The build, test and lint commands.
Cite file paths. Say "unclear" instead of guessing. Don't edit anything.
2. Hand a deep question to the codebase investigator
Gemini CLI ships a built-in codebase_investigator subagent for analyzing code and complex dependencies. Starting the prompt with its name tells the main agent to use it. Google's subagents docs list the others.
@codebase_investigator Map how {{component_a:the payment service}} depends on
{{component_b:the user service}}: every call between them, shared types,
and anything that would break if {{change:the user ID became a UUID}}.
Return a list of file paths with one line on each.
How do you plan changes in Gemini CLI?
3. Plan a feature in Plan Mode
Type /plan followed by the goal and the prompt is submitted at once in read-only mode. When the plan appears, press Ctrl+G to edit it in your editor (the Plan Mode page still lists the older Ctrl+X, which the shortcuts reference marks deprecated), then approve it to start implementation. Details are in Google's Plan Mode docs.
/plan {{goal:Add rate limiting to the public API}}. Start from @{{start_file:src/api/router.ts}}. List the files to change, what changes in each, the tests to add, and the risks. Ask me about anything you would otherwise guess.
4. Get questioned before the plan
Plan Mode can ask you questions, so use it to pin down requirements before any code exists.
I want to build {{feature:a CSV export for the reports page}}. Before
writing a plan, ask me one question at a time about scope, data
volume, permissions and error handling. Challenge anything that looks
wrong given the code. When we agree, write the plan with a test for
each step.
How do you build and fix with Gemini CLI?
5. Fix a bug with a failing test first
Bug: {{symptom:users are logged out after refreshing the page}}.
Likely area: @{{area:src/auth/}}
Run {{test_command:npm test}} to see the current state. Write a failing
test that reproduces the bug and show it failing. Then fix the root
cause with the smallest change. Don't suppress errors or loosen checks.
Rerun the tests until they pass and explain the cause in two sentences.
6. Build from a sketch or mockup
The README lists generating apps from PDFs, images or sketches as a core use. Attach the image with @.
@{{image:designs/settings-mockup.png}} Build this screen as
{{component:a SettingsPage component}} in {{stack:React with Tailwind}}.
Reuse components from @{{components_dir:src/components/}} where they
fit. Don't add libraries. When done, list anything in the image you
couldn't match.
7. Check current docs before an upgrade
Gemini CLI has web fetch and search tools, which help when the model's knowledge may be out of date.
We're upgrading {{library:Next.js}} from {{from_version:14}} to
{{to_version:15}}. Search the web for the official upgrade guide and
read it. Then list every breaking change that affects this codebase,
with the file paths where each one applies. Don't edit anything yet.
Link the sources you used.
How do you review code with Gemini CLI?
8. Review your uncommitted changes
Run git diff and review the changes as a strict senior engineer.
Priorities, in order: bugs and wrong logic, security
({{security_focus:auth checks, injection, secrets in code}}), missing
error handling, missing tests. For each finding give the file and
line, severity (blocker, should fix, nit) and the fix. Don't edit files.
9. Save the review as a custom command
Custom commands are TOML files with a prompt field. Inside the prompt, !{...} runs a shell command and inserts its output, after you confirm. If the prompt has no arguments placeholder and you add text after the command, the full command you typed is appended to the end of the prompt. Google's custom commands docs cover the syntax.
Create .gemini/commands/{{command_name:review}}.toml with a description
and a prompt that reviews the output of !{git diff} using these
priorities: bugs, security, missing error handling, missing tests.
Each finding should have file, line, severity and fix. Then tell me to
run /commands reload and how to call the command.
How do you set up GEMINI.md, subagents and skills?
10. Tighten the GEMINI.md that /init created
Run /init first, then this. Google's GEMINI.md docs explain the global, project and folder levels and @file.md imports. The GEMINI.md guide has examples.
Read GEMINI.md and run every command in it to confirm it works. Then
rewrite it to include: the exact build, test and lint commands, the
main folders in one line each, conventions that differ from the
language's defaults, and a "do not" list: {{do_not:never edit files in src/generated, never commit .env}}.
Cut anything you can learn from the code. Keep it under 80 lines and
show me the diff before saving.
11. Create a custom subagent
Project subagents are Markdown files in .gemini/agents/ with YAML frontmatter; the body becomes the subagent's system prompt.
Create .gemini/agents/{{agent_name:security-auditor}}.md with
frontmatter that sets name, a description telling you when to use it,
and tools limited to {{tools:read_file and grep_search}}. In the body,
tell it to {{role:audit code for injection, auth flaws and secrets in code, with file and line for each finding}}.
Then reload agents and use it on @{{target:src/api/}}.
12. Turn a repeated workflow into a skill
Gemini CLI reads workspace skills from .gemini/skills/ or .agents/skills/ and asks for your consent before activating one. The Gemini CLI skills guide covers the format.
Create a skill at .agents/skills/{{skill_name:release-notes}}/SKILL.md
that {{job:writes release notes from the commits since the last tag}}.
Add frontmatter with a name matching the folder and a description that
says what it does and when to use it. In the body, give numbered steps,
the exact output format and two rules about what to leave out.
How do you run Gemini CLI in scripts?
13. A prompt for headless mode
Pass a prompt with -p and Gemini CLI runs without the interactive UI. Add --output-format json to get one object with the response and stats. Write headless prompts so they never need a follow-up question.
Read {{log_file:ci-output.txt}}. Find the first real failure, not the
errors that follow from it. Explain the cause in one sentence and name
the file and line most likely responsible. Don't edit any files. End
with exactly one line: STATUS: CODE_BUG, TEST_BUG or ENVIRONMENT.
What makes a Gemini CLI prompt work?
Give Gemini the real material and a way to check itself. @ beats describing where code lives, and a test or build command at the end of the prompt beats "make sure it works." For anything that touches several files, plan first: Plan Mode keeps Gemini to reading and writing plan files until you approve.
Keep context clean. /clear starts a new session with empty context, and /compress replaces the history with a summary when you want to keep going. If a change goes wrong, /rewind (or Esc twice) steps back through the conversation and can revert file changes. Turn on checkpointing in settings.json if you also want /restore to roll files back to just before a tool ran.
Put anything you repeat into GEMINI.md, a custom command or a skill instead of retyping it. To share one instruction file across tools, the docs show setting context.fileName so Gemini CLI also reads AGENTS.md. For setup questions, the Gemini CLI MCP guide and the comparisons with Claude Code and Codex go further.
The same approach works in other agents: see the Claude Code prompts, Codex prompts and GitHub Copilot prompts. For the Gemini chat app, use the Gemini prompts collection.
Keep your best Gemini CLI prompts
Prompts like these are worth keeping. Kipt stores them as Markdown in a private GitHub repo you own: save a prompt with its blanks, tag it, and find it again with Cmd+K. When one becomes a workflow, the free SKILL.md generator turns it into a valid SKILL.md you can put in .agents/skills/.