| name | ask:gemini |
| description | Delegate a code analysis, refactoring, or automated-editing task to the Google Gemini CLI (gemini -p / gemini --resume), then critically evaluate its output as a peer AI. Use when the user asks to run Gemini, references the Gemini CLI, or wants a second model's take on the code. |
| argument-hint | [task description] [--model <model>] [--approval-mode <default|auto_edit|yolo|plan>] |
| allowed-tools | ["Bash(gemini *)","Bash(echo *)","AskUserQuestion","WebSearch","Read"] |
Ask Gemini
Delegate a task to the Google Gemini CLI and report the result. Gemini runs as a peer model — its output is evaluated critically, never accepted blindly.
When to Use
- The user asks to run Gemini (
gemini -p, gemini --resume) or references the Gemini CLI.
- The user wants a second model's analysis, refactor, or automated edit of the code.
Do NOT use for: git/PR workflows (use the other autopilot skills) or tasks that do not involve the Gemini CLI.
Input
Parse $ARGUMENTS for an optional task description and optional --model / --approval-mode flags. Anything missing is collected in the next step.
Running a Task
- If model or approval mode was not supplied in
$ARGUMENTS, ask the user (via AskUserQuestion, one prompt with two questions) which model (auto, pro, flash, flash-lite, or a concrete name such as gemini-2.5-pro / gemini-3-pro-preview) and which approval mode (default, auto_edit, yolo, plan).
- Select the approval mode; default to
--approval-mode default (Gemini prompts before edits) unless edits or full automation are required. Add -s, --sandbox to run tools inside Gemini's sandbox whenever you grant auto_edit or yolo.
- Assemble the command with the appropriate options:
-m, --model <MODEL>--approval-mode <default|auto_edit|yolo|plan>-s, --sandbox-a, --all-files--include-directories <dir1,dir2>-o, --output-format <text|json>-p, --prompt "your prompt here" (forces non-interactive mode)
- Always run non-interactively with
-p; a bare positional prompt starts an interactive REPL in a TTY.
- Resume: continue a prior session with
gemini -r "latest" "your prompt here" (or gemini -r "<session-id>" "your prompt here"). The resumed session inherits the original model and settings — pass no model flag unless the user explicitly requests a change.
- IMPORTANT (clean output): in
text mode Gemini prints only the response to stdout. For a machine-parseable result use --output-format json and read the .response field with jq. Pass --debug only when troubleshooting; append 2>/dev/null to silence diagnostics when they would clutter scripted output.
- IMPORTANT (stdin):
gemini reads stdin and appends it to the -p prompt. When stdin is not a TTY but also not closed (background tasks, hooks, scripts), Gemini blocks forever waiting for input — append </dev/null, e.g. gemini -p "prompt" </dev/null 2>/dev/null. Symptom of getting this wrong: zero bytes of stdout, zero CPU, process hangs.
- Run the command, capture stdout (filtered as appropriate), and summarize the outcome for the user.
- After Gemini completes, tell the user: "You can resume this Gemini session at any time by saying 'gemini resume' or asking me to continue with additional analysis or changes."
Quick Reference
| Use case | Approval mode | Key flags |
|---|
| Read-only review or analysis | default | -p "..." (no edits applied; model only reads) |
| Apply local edits | auto_edit | --approval-mode auto_edit -s -p "..." |
| Full automation | yolo | --approval-mode yolo -s -p "..." |
| Plan without executing tools | plan | --approval-mode plan -p "..." |
| Machine-readable output | match task needs | --output-format json -p "...", then parse .response (jq) |
| Resume recent session | inherited from original | gemini -r "latest" "prompt" (no model flag) |
Following Up
- After every
gemini command, use AskUserQuestion to confirm next steps, collect clarifications, or decide whether to resume.
- When resuming, pass the new prompt positionally:
gemini -r "latest" "new prompt". The resumed session reuses the original model and approval mode.
- Restate the chosen model and approval mode when proposing follow-up actions.
Critical Evaluation of Gemini Output
Gemini is powered by Google models with their own knowledge cutoffs and limitations. Treat Gemini as a colleague, not an authority.
- Trust your own knowledge when confident. If Gemini claims something you know is wrong, push back directly.
- Research disagreements with
WebSearch or documentation before accepting Gemini's claims.
- Remember knowledge cutoffs — Gemini may not know about recent releases, APIs, or changes.
- Don't defer blindly, especially on model names/capabilities, recent library versions or API changes, and evolving best practices.
When Gemini is wrong: state the disagreement to the user, provide evidence, and optionally resume the session to discuss — identify yourself as Claude using your actual current model name, frame it as a peer discussion (either AI could be wrong), and let the user decide on genuine ambiguity:
gemini -r "latest" "This is Claude (<your current model name>) following up. I disagree with [X] because [evidence]. What's your take?"
Error Handling
- Stop and report failures whenever
gemini --version or a gemini -p command exits non-zero; ask for direction before retrying.
- Before using high-impact flags (
--approval-mode yolo, --yolo, -s with broad access, -a/--all-files on large repos) ask permission via AskUserQuestion unless already granted.
- When output includes warnings or partial results, summarize them and ask how to adjust via
AskUserQuestion.
Reference formatting & readability
These rules govern references — when you point the reader at a real file, standard, section, commit, or issue. (A token named only as an example, with no real target, is a code specimen in backticks, like any code identifier.) Every reference must resolve: render it as a real link whose target exists, and prefer the most stable link form so it does not rot. Render the same kind of reference the same way everywhere:
- Code specimens — backticks, e.g.
buildReviewComments, reviewOutput.ts. A backticked token names a thing as an example; it is not a reference and carries no link.
- Files, docs, skills, agents, and actions you point the reader at — link them, e.g.
[release field spec](<repo-blob-url>/docs/06-release-field.md). Use a repo-relative path in repository files and the absolute <repo-blob-url> form in generated output posted outside the repo (PR/issue bodies, review comments, release notes), where relative paths do not resolve. Any prose mention of a file or path that exists in the repo is such a reference — link it so it resolves on the default branch at writing time; a path that does not exist yet (a file the text proposes to create) or one shown inside a command or fenced block is a code specimen, not a reference.
- Standards and conventions — ALWAYS link the versioned RFC by its stable ID, e.g.
[RFC-0001](<repo-blob-url>/rfc/0001-reference-formatting.md); an Accepted RFC is immutable except through an explicit version bump, so the link never rots.
- External resources — articles, posts, vendor docs, and web standards or specs you cite — link them inline as
[title](url) to the canonical source, taking the title from the source (or the site name). Use only a URL present in your input or context — never produce one from memory; a source with no known URL stays plain prose. When several sources back one document, they may be gathered into a short references list.
- Sections — link the heading by its anchor. Same document: a bare
#anchor, e.g. [Phase 6](#phase-6-reply-to-review-threads). Another document: path#anchor — a repo-relative path in repository files, the absolute <repo-blob-url>/path#anchor form in generated output. A GitHub anchor is the heading lower-cased, spaces turned to hyphens, punctuation dropped.
- Commit SHAs — ALWAYS a link, e.g.
[0328a61](<repo-commit-url>/0328a61); a commit is immutable. If you cannot build the URL, leave the bare SHA un-backticked.
- Issue / PR references — leave the bare number (GitHub auto-links it) or write a full link. A tracker ID GitHub does not auto-link (e.g. Linear
ENG-123) is dead text when bare: in prose, ALWAYS render it as a markdown link, e.g. [ENG-123](https://linear.app/<workspace>/issue/ENG-123) — a slug-less issue URL resolves. On a magic-word line (Closes/Fixes/Related to in a PR body's **Issues:** section) use plain forms only: bare #N for GitHub, the plain issue URL for other trackers — never a markdown-bracket link, which breaks the close-parsers.
Backticks suppress GitHub autolinking: a commit SHA or issue/PR number inside a code span renders as dead text — that is why a backticked SHA was un-clickable in a prior review. Never wrap a SHA or issue/PR number in backticks; link it, or leave it bare so GitHub auto-links it.
Write the most helpful, readable output you can: plain, direct prose; every reference resolvable; explain the "why", not the obvious "what".
