How do I start a remote PR review?

Identify the PR via URL or number, checkout with gh pr checkout , run npm run preflight, then read the PR description and history to inform your review.

How do I review local changes?

Inspect git status, review diffs with git diff and git diff --staged, optionally run preflight, and evaluate against the pillars.

How should feedback be delivered?

Provide a structured report with a Summary, Findings (Critical, Improvements, Nitpicks), and a clear Conclusion (Approved or Request Changes), with rationale and suggested next steps.

code-reviewer

Scanned

npx machina-cli add skill google-gemini/gemini-cli/code-reviewer --openclaw

Files (1)

SKILL.md

3.1 KB

Code Reviewer

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).

Source

git clone https://github.com/google-gemini/gemini-cli/blob/main/.gemini/skills/code-reviewer/SKILL.mdView on GitHub

Overview

Code-reviewer guides thorough reviews for both remote pull requests and local changes. It emphasizes correctness, maintainability, readability, security, and adherence to project standards. The workflow helps identify issues early and provide structured, actionable feedback.

How This Skill Works

First, it determines the review target: remote PR or local changes. For remote PRs, it checks out the PR with gh pr checkout, runs the preflight suite, and reads the description and history. For local changes, it inspects git status and diffs (git diff, git diff --staged), optionally runs preflight, and then analyzes across correctness, maintainability, readability, efficiency, security, edge cases, and testability.

When to Use It

Review a remote pull request by number or URL (e.g., 'Review PR #123').
Review local changes when no PR is mentioned or when a user asks to 'review my changes'.
Run the preflight verification to catch automated failures early.
Provide structured feedback with findings, improvements, and nitpicks.
After review, decide Approve or Request Changes and perform post-review cleanup (remote PRs).

Quick Start

Step 1: Determine if you are reviewing a Remote PR or Local Changes.
Step 2: For Remote PRs, run gh pr checkout <PR_NUMBER> and npm run preflight; for Local Changes, check git status and git diff.
Step 3: Analyze per the pillars (Correctness, Maintainability, Readability, Efficiency, Security, Edge Cases, Testability) and provide structured feedback, then decide on Approved or Changes Requested.

Best Practices

Always confirm the review target before starting.
Run npm run preflight early for remote PRs or substantial changes.
Evaluate across Correctness, Maintainability, Readability, Efficiency, Security, Edge Cases, and Testability.
Suggest concrete test cases and improvements with rationale.
Communicate feedback with constructive tone, explain why changes are needed, and document next steps.

Example Use Cases

A PR refactors a core module and requires updated tests and documentation references.
A bug-fix PR adds null checks and handles edge cases that were previously crashing.
A performance-impacting PR requires notes on profiling and potential optimizations.
A local change set introduces formatting issues or minor style deviations for nitpicks.
A remote PR has unclear history; review clarifies intent and strengthens test coverage.

Frequently Asked Questions

Add this skill to your agents