Gemini External Review
Invoke the Gemini CLI (Google's CLI agent) as an external reviewer for a second opinion.
Arguments: $ARGUMENTS
Determine Review Type
Parse $ARGUMENTS to determine the review focus. If empty, default to code.
| Argument |
Focus |
| (empty) |
Code review — bugs, security, quality, performance |
code |
Code review — bugs, security, quality, performance |
architecture or arch |
Architecture — structure, patterns, separation of concerns, scalability |
security or sec |
Security audit — vulnerabilities, auth issues, data exposure, OWASP |
docs |
Documentation — accuracy, completeness, clarity, examples |
design |
Design review — API design, naming, abstractions, DX |
performance or perf |
Performance — bottlenecks, memory, queries, caching |
test or tests |
Test review — coverage, edge cases, test quality, flaky tests |
| Anything else |
Use the argument text as a custom review prompt/focus |
Your Task
Gather context:
- Read the project's README or main docs if present.
- Run
git status, git diff --stat, git diff (staged + unstaged; keep it reasonable size),
and git log --oneline -10.
- Identify the stack (package.json, Cargo.toml, pyproject.toml, etc.) and note project structure.
Prepare the review request — build a prompt for Gemini with: project name/description,
stack, summary of recent changes, the actual diff/relevant code, the review focus, and an
instruction to act as a senior engineer/reviewer.
Execute the review in plan (read-only) mode:
gemini --approval-mode plan -o text -p "PROMPT_HERE"
Flags: --approval-mode plan = read-only, no file modifications · -o text = plain text
output (cleanest to parse) · -p = non-interactive prompt mode.
Present results — summarize key findings, highlight critical issues, note any
disagreements with Gemini's assessment, give your own take on whether the suggestions are
valid, and ask the user if they want to act on any of them.
Important Notes
- Always use
--approval-mode plan — read-only, no exceptions.
- If the diff is very large, summarize key changes instead of including everything.
- Present both Gemini's opinion and your own analysis; say so if you disagree.
Prompt Template
Adapt the review questions based on the review type determined above.
You are reviewing [PROJECT_NAME], a [DESCRIPTION].
Tech stack: [TECHNOLOGIES]
Recent commits:
[GIT LOG]
Current changes:
[GIT DIFF or relevant code]
Review focus: [REVIEW_TYPE]
[TYPE-SPECIFIC QUESTIONS based on the table above]
Be direct and critical. This is a real review, not a validation.
Now gather the context and execute the Gemini review.
1---2name: gemini-review3description: Get a second-opinion review of the current diff (or a chosen focus — architecture, security, docs, design, performance, tests) from the Gemini CLI, then present its findings alongside your own analysis. Single-reviewer counterpart to /codex-review and /review-panel; needs the `gemini` CLI installed. Triggers on `/gemini-review [focus]`, "gemini review this", "get a gemini second opinion on this diff".4---56# Gemini External Review78Invoke the Gemini CLI (Google's CLI agent) as an external reviewer for a second opinion.910**Arguments:** `$ARGUMENTS`1112## Determine Review Type1314Parse `$ARGUMENTS` to determine the review focus. If empty, default to `code`.1516| Argument | Focus |17|----------|-------|18| *(empty)* | Code review — bugs, security, quality, performance |19| `code` | Code review — bugs, security, quality, performance |20| `architecture` or `arch` | Architecture — structure, patterns, separation of concerns, scalability |21| `security` or `sec` | Security audit — vulnerabilities, auth issues, data exposure, OWASP |22| `docs` | Documentation — accuracy, completeness, clarity, examples |23| `design` | Design review — API design, naming, abstractions, DX |24| `performance` or `perf` | Performance — bottlenecks, memory, queries, caching |25| `test` or `tests` | Test review — coverage, edge cases, test quality, flaky tests |26| Anything else | Use the argument text as a custom review prompt/focus |2728## Your Task29301. **Gather context:**31 - Read the project's README or main docs if present.32 - Run `git status`, `git diff --stat`, `git diff` (staged + unstaged; keep it reasonable size),33 and `git log --oneline -10`.34 - Identify the stack (package.json, Cargo.toml, pyproject.toml, etc.) and note project structure.35362. **Prepare the review request** — build a prompt for Gemini with: project name/description,37 stack, summary of recent changes, the actual diff/relevant code, the review focus, and an38 instruction to act as a senior engineer/reviewer.39403. **Execute the review** in plan (read-only) mode:41 ```bash42 gemini --approval-mode plan -o text -p "PROMPT_HERE"43 ```44 Flags: `--approval-mode plan` = read-only, no file modifications · `-o text` = plain text45 output (cleanest to parse) · `-p` = non-interactive prompt mode.46474. **Present results** — summarize key findings, highlight critical issues, note any48 disagreements with Gemini's assessment, give your own take on whether the suggestions are49 valid, and ask the user if they want to act on any of them.5051## Important Notes5253- Always use `--approval-mode plan` — read-only, no exceptions.54- If the diff is very large, summarize key changes instead of including everything.55- Present both Gemini's opinion and your own analysis; say so if you disagree.5657## Prompt Template5859Adapt the review questions based on the review type determined above.6061```62You are reviewing [PROJECT_NAME], a [DESCRIPTION].63Tech stack: [TECHNOLOGIES]6465Recent commits:66[GIT LOG]6768Current changes:69[GIT DIFF or relevant code]7071Review focus: [REVIEW_TYPE]7273[TYPE-SPECIFIC QUESTIONS based on the table above]7475Be direct and critical. This is a real review, not a validation.76```7778Now gather the context and execute the Gemini review.
iamneilroberts