Gemini

Skill 5 of 23

Code Reviewer

Use this skill to review code. It supports both local changes (staged or working tree) and remote Pull Requests (by ID or URL).

2 minutes · 376 words · 10 sections

Install

$ npx skills add google-gemini/gemini-cli --skill code-reviewer

$ npx skills add google-gemini/gemini-cli

The first command installs just this skill, by the name in its SKILL.md; the second installs the whole repository.

This skill guides the agent in conducting professional and thorough code reviews for both local development and remote Pull Requests.

Workflow

1. Determine Review Target

Remote PR: If the user provides a PR number or URL (e.g., “Review PR #123”), target that remote PR.
Local Changes: If no specific PR is mentioned, or if the user asks to “review my changes”, target the current local file system states (staged and unstaged changes).

2. Preparation

For Remote PRs:

Checkout: Use the GitHub CLI to checkout the PR.
```
gh pr checkout <PR_NUMBER>
```
Preflight: Execute the project’s standard verification suite to catch automated failures early.
```
npm run preflight
```
Context: Read the PR description and any existing comments to understand the goal and history.

For Local Changes:

Identify Changes:
- Check status: git status
- Read diffs: git diff (working tree) and/or git diff --staged (staged).
Preflight (Optional): If the changes are substantial, ask the user if they want to run npm run preflight before reviewing.

3. In-Depth Analysis

Analyze the code changes based on the following pillars:

Correctness: Does the code achieve its stated purpose without bugs or logical errors?
Maintainability: Is the code clean, well-structured, and easy to understand and modify in the future? Consider factors like code clarity, modularity, and adherence to established design patterns.
Readability: Is the code well-commented (where necessary) and consistently formatted according to our project’s coding style guidelines?
Efficiency: Are there any obvious performance bottlenecks or resource inefficiencies introduced by the changes?
Security: Are there any potential security vulnerabilities or insecure coding practices?
Edge Cases and Error Handling: Does the code appropriately handle edge cases and potential errors?
Testability: Is the new or modified code adequately covered by tests (even if preflight checks pass)? Suggest additional test cases that would improve coverage or robustness.

4. Provide Feedback

Structure

Summary: A high-level overview of the review.
Findings:
- Critical: Bugs, security issues, or breaking changes.
- Improvements: Suggestions for better code quality or performance.
- Nitpicks: Formatting or minor style issues (optional).
Conclusion: Clear recommendation (Approved / Request Changes).

Tone

Be constructive, professional, and friendly.
Explain why a change is requested.
For approvals, acknowledge the specific value of the contribution.

5. Cleanup (Remote PRs only)

After the review, ask the user if they want to switch back to the default branch (e.g., main or master).

About this skill

Trigger

Use this skill to review code. It supports both local changes (staged or working tree) and remote Pull Requests (by ID or URL). It focuses on correctness, maintainability, and adherence to project standards.

The verbatim description from this skill’s front matter — the string an agent matches on to decide whether to load it.

Colophon for this issue

Colophon

How this issue was made

Source

github.com/google-gemini/gemini-cli, branch main, last pushed 8 November 2026.

Licence

Apache-2.0 — the text of every skill is reproduced unmodified, frontmatter included, under the upstream licence.

Discovery

23 skills found by walking the repository tree for SKILL.md, not by matching a directory convention. 4 distinct layouts observed: .gemini/skills/*/SKILL.md, packages/core/src/skills/builtin/*/SKILL.md, tools/caretaker-agent/cloudrun/triage-worker/.gemini/skills/*/SKILL.md, tools/gemini-cli-bot/.gemini/skills/*/SKILL.md.

Authorship

4 of 23 skills are installed into the repository rather than published from it. They are shelved in the closing “Credited skills” part and remain the work of their own authors. A skill counts as credited when its only copy lives under one agent’s dot directory; visible directories, per-agent mirror sets, and skills installable from this repository on skills.sh all count as published.

Issue colours

Resolved from a curated brand profile — hue 288°, chroma 0.190. Two accent tones are generated per issue and each is proven against its own ground before it ships: a single accent that passes AA on both light and dark paper is arithmetically impossible.

Heading repairs

1 repair applied to this skill so the document has one h1 and no skipped levels:

Removed “Code Reviewer”, a leading h1 that duplicated the skill title.

Spec compliance

2 editorial notes across 2 of 23 skills. They are printed in the margin of each skill rather than as errors here.

Code Explorer — 1 note
Spec Generator — 1 note

Images

Images inside a skill come from the upstream repository. Where the author gave no alternative text we mark the image decorative rather than inventing a description — a plausible caption we made up is worse than none for the reader who depends on it.

Signal

Install counts come from skills.sh. They measure downloads, not quality, and an unranked repository is not an unread one.

Agent surfaces

The whole issue is available as one markdown document at /google-gemini/gemini-cli.md, and each skill at its own .md URL.

Publication

Set by Skills Docs from the source repository. Body text is Literata at the reader’s chosen size and measure; code is Geist Mono. Nothing on this page was written by us except this paragraph.

Workflow

Remote PR: If the user provides a PR number or URL (e.g., “Review PR #123”), target that remote PR.

Local Changes: If no specific PR is mentioned, or if the user asks to “review my changes”, target the current local file system states (staged and unstaged changes).

Checkout: Use the GitHub CLI to checkout the PR.

gh pr checkout <PR_NUMBER>

Preflight: Execute the project’s standard verification suite to catch automated failures early.

npm run preflight

Context: Read the PR description and any existing comments to understand the goal and history.

Identify Changes:

Check status: git status
Read diffs: git diff (working tree) and/or git diff --staged (staged).

Preflight (Optional): If the changes are substantial, ask the user if they want to run npm run preflight before reviewing.

Analyze the code changes based on the following pillars:

Correctness: Does the code achieve its stated purpose without bugs or logical errors?

Maintainability: Is the code clean, well-structured, and easy to understand and modify in the future? Consider factors like code clarity, modularity, and adherence to established design patterns.

Readability: Is the code well-commented (where necessary) and consistently formatted according to our project’s coding style guidelines?

Efficiency: Are there any obvious performance bottlenecks or resource inefficiencies introduced by the changes?

Security: Are there any potential security vulnerabilities or insecure coding practices?

Edge Cases and Error Handling: Does the code appropriately handle edge cases and potential errors?

Testability: Is the new or modified code adequately covered by tests (even if preflight checks pass)? Suggest additional test cases that would improve coverage or robustness.

Summary: A high-level overview of the review.

Findings:

Critical: Bugs, security issues, or breaking changes.
Improvements: Suggestions for better code quality or performance.
Nitpicks: Formatting or minor style issues (optional).

Conclusion: Clear recommendation (Approved / Request Changes).

Be constructive, professional, and friendly.

Explain why a change is requested.

For approvals, acknowledge the specific value of the contribution.

After the review, ask the user if they want to switch back to the default branch (e.g., main or master).