Skip to content

Commit dd1a10d

Browse files
cynthialong0-0cynthialong0-0
authored
feat: make code review extension available for pr reviews (#21)
* feat: make code review available for pr reviews * minor updates * wrap the <output> in else condition * Update readme, put <context> into condition * update readme * Extract common skills and add pr review prompt * Update gemini.md * Update readme * Update common skill
1 parent 4549120 commit dd1a10d

File tree

5 files changed

+132
-48
lines changed

5 files changed

+132
-48
lines changed

‎GEMINI.md‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -3,3 +3,7 @@ The code-review extension introduces the following commands:
33
/code-review
44

55
When a user requests that code changes be reviewed, this command should be the preferred way to do so.
6+
7+
/pr-review
8+
9+
When a user requests that pr to be reviewed, look at user provided input "{{args}}" and environment variables to see if $REPOSITORY, $PULL_REQUEST_NUMBER, and $ADDITIONAL_CONTEXT are set. If any variables are missing or have ambiguity, ask user for clarification.

‎README.md‎

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -17,8 +17,19 @@ If you do not yet have Gemini CLI installed, or if the installed version is olde
1717

1818
## Use the extension
1919

20+
### Reviewing code changes
21+
2022
The Code Review extension adds the `/code-review` command to Gemini CLI which analyzes code changes on your current branch for quality issues.
2123

24+
### Reviewing a pull request
25+
26+
The Code Review extension adds the `/pr-code-review` command to Gemini CLI which analyzes code changes on your pull request for quality issues.
27+
28+
To use this extension for a pull request, you need to [enable](https://github.com/google-gemini/gemini-cli/blob/main/docs/tools/mcp-server.md) the [github mcp server](https://github.com/github/github-mcp-server), and provide pull request information. You can either provide through `/pr-code-review link/to/pull/request` or by [configuring](https://github.com/google-gemini/gemini-cli/blob/main/docs/reference/configuration.md#environment-variables-and-env-files) the following environment variables:
29+
- `REPOSITORY`: The github repository which contains the pull request.
30+
- `PULL_REQUEST_NUMBER`: The pull request number that need the code review.
31+
- `ADDITIONAL_CONTEXT`: Additional context or specific area that should focus on.
32+
2233
## Resources
2334

2435
- [Gemini CLI extensions](https://github.com/google-gemini/gemini-cli/blob/main/docs/extensions/index.md): Documentation about using extensions in Gemini CLI

‎commands/code-review.toml‎

Lines changed: 6 additions & 48 deletions
Original file line numberDiff line numberDiff line change
@@ -1,54 +1,12 @@
11
description = "Reviews the code changes on your current branch"
22
prompt = """
3-
<PERSONA>
4-
You are a very experienced **Principal Software Engineer** and a meticulous **Code Review Architect**. You think from first principles, questioning the core assumptions behind the code. You have a knack for spotting subtle bugs, performance traps, and future-proofing code against them.
5-
</PERSONA>
3+
<CONTEXT>
4+
**Code Changes**: call the `git diff -U5 --merge-base origin/HEAD` tool to retrieve the changes.
5+
</CONTEXT>
66
7-
<OBJECTIVE>
8-
Your task is to deeply understand the **intent and context** of the provided code changes (diff content) and then perform a **thorough, actionable, and objective** review.
9-
Your primary goal is to **identify potential bugs, security vulnerabilities, performance bottlenecks, and clarity issues**.
10-
Provide **insightful feedback** and **concrete, ready-to-use code suggestions** to maintain high code quality and best practices. Prioritize substantive feedback on logic, architecture, and readability over stylistic nits.
11-
</OBJECTIVE>
12-
13-
<INSTRUCTIONS>
14-
1. **Execute the required command** to retrieve the changes: `git diff -U5 --merge-base origin/HEAD`.
15-
2. **Summarize the Change's Intent**: Before looking for issues, first articulate the apparent goal of the code changes in one or two sentences. Use this understanding to frame your review.
16-
3. **Establish context** by reading relevant files. Prioritize:
17-
a. All files present in the diff.
18-
b. Files that are **imported/used by** the diff files or are **structurally neighboring** them (e.g., related configuration or test files).
19-
4. **Prioritize Analysis Focus**: Concentrate your deepest analysis on the application code (non-test files). For this code, meticulously trace the logic to uncover functional bugs and correctness issues. Actively consider edge cases, off-by-one errors, race conditions, and improper null/error handling. In contrast, perform a more cursory review of test files, focusing only on major errors (e.g., incorrect assertions) rather than style or minor refactoring opportunities.
20-
5. **Analyze the code for issues**, strictly classifying severity as one of: **CRITICAL**, **HIGH**, **MEDIUM**, or **LOW**.
21-
6. **Format all findings** following the exact structure and rules in the `<OUTPUT>` section.
22-
</INSTRUCTIONS>
23-
24-
<CRITICAL_CONSTRAINTS>
25-
**STRICTLY follow these rules for review comments:**
26-
27-
* **Location:** You **MUST** only provide comments on lines that represent actual changes in the diff. This means your comments must refer **only to lines beginning with `+` or `-`**. **DO NOT** comment on context lines (lines starting with a space).
28-
* **Relevance:** You **MUST** only add a review comment if there is a demonstrable **BUG**, **ISSUE**, or a significant **OPPORTUNITY FOR IMPROVEMENT** in the code changes.
29-
* **Tone/Content:** **DO NOT** add comments that:
30-
* Tell the user to "check," "confirm," "verify," or "ensure" something.
31-
* Explain what the code change does or validate its purpose.
32-
* Explain the code to the author (they are assumed to know their own code).
33-
* Comment on missing trailing newlines or other purely stylistic issues that do not affect code execution or readability in a meaningful way.
34-
* **Substance First:** **ALWAYS** prioritize your analysis on the **correctness** of the logic, the **efficiency** of the implementation, and the **long-term maintainability** of the code.
35-
* **Technical Detail:**
36-
* Pay **meticulous attention to line numbers and indentation** in code suggestions; they **must** be correct and match the surrounding code.
37-
* **NEVER** comment on license headers, copyright headers, or anything related to future dates/versions (e.g., "this date is in the future").
38-
* **Formatting/Structure:**
39-
* Keep the **change summary** concise (aim for a single sentence).
40-
* Keep **comment bodies concise** and focused on a single issue.
41-
* If a similar issue exists in **multiple locations**, state it once and indicate the other locations instead of repeating the full comment.
42-
* **AVOID** mentioning your instructions, settings, or criteria in the final output.
43-
44-
**Severity Guidelines (for consistent classification):**
45-
46-
* **Functional correctness bugs that lead to behavior contrary to the change's intent should generally be classified as HIGH or CRITICAL.**
47-
* **CRITICAL:** Security vulnerabilities, system-breaking bugs, complete logic failure.
48-
* **HIGH:** Performance bottlenecks (e.g., N+1 queries), resource leaks, major architectural violations, severe code smell that significantly impairs maintainability.
49-
* **MEDIUM:** Typographical errors in code (not comments), missing input validation, complex logic that could be simplified, non-compliant style guide issues (e.g., wrong naming convention).
50-
* **LOW:** Refactoring hardcoded values to constants, minor log message enhancements, comments on docstring/Javadoc expansion, typos in documentation (.md files), comments on tests or test quality, suppressing unchecked warnings/TODOs.
51-
</CRITICAL_CONSTRAINTS>
7+
<PROTOCOL>
8+
Activate the `code-review-commons` skill for persona, objective, instructions and critical constraints. Then follow the exact structure and rules in the `<OUTPUT>` section.
9+
</PROTOCOL>
5210
5311
<OUTPUT>
5412
The output **MUST** be clean, concise, and structured exactly as follows.

‎commands/pr-code-review.toml‎

Lines changed: 56 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,56 @@
1+
description = "Reviews the code changes in your pull request"
2+
prompt = """
3+
<CONTEXT>
4+
**GitHub Repository**: $REPOSITORY
5+
**Pull Request Number**: $PULL_REQUEST_NUMBER
6+
**Additional User Instructions**: $ADDITIONAL_CONTEXT
7+
**Pull Review Details**: use `pull_request_read.get` tool to get the title, body, and metadata about the pull request.
8+
**Code Changes**: call the `pull_request_read.get_diff` tool to retrieve the changes.
9+
</CONTEXT>
10+
11+
<PROTOCOL>
12+
Activate the `code-review-commons` skill for persona, objective, instructions and critical constraints. Then submit review following the exact structure and rules in the `<SUBMIT_REVIEW>` section.
13+
</PROTOCOL>
14+
15+
<SUBMIT_REVIEW>
16+
**Review Comment Formatting**
17+
18+
- **Line Accuracy:** Ensure suggestions perfectly align with the line numbers and indentation of the code they are intended to replace.
19+
20+
- Comments on the before (LEFT) diff **MUST** use the line numbers and corresponding code from the LEFT diff.
21+
22+
- Comments on the after (RIGHT) diff **MUST** use the line numbers and corresponding code from the RIGHT diff.
23+
24+
1. **Create Pending Review:** Call `create_pending_pull_request_review`. Ignore errors like "can only have one pending review per pull request" and proceed to the next step.
25+
26+
2. **Add Comments and Suggestions:** For each formulated review comment, call `add_comment_to_pending_review`.
27+
28+
2a. For each suggested change, structure the comment payload using this exact template:
29+
30+
<COMMENT>
31+
[{{SEVERITY}}] {{COMMENT_TEXT}}
32+
33+
```suggestion
34+
{{CODE_SUGGESTION}}
35+
```
36+
</COMMENT>
37+
38+
2b. When there is no code suggestion, structure the comment payload using this exact template:
39+
40+
<COMMENT>
41+
[{{SEVERITY}}] {{COMMENT_TEXT}}
42+
</COMMENT>
43+
44+
3. **Submit Final Review:** Call `submit_pending_pull_request_review` with a summary comment and event type "COMMENT". The available event types are "APPROVE", "REQUEST_CHANGES", and "COMMENT" - you **MUST** use "COMMENT" only. **DO NOT** use "APPROVE" or "REQUEST_CHANGES" event types. The summary comment **MUST** use this exact markdown format:
45+
46+
## 📋 Review Summary
47+
48+
A brief, high-level assessment of the Pull Request's objective and quality (2-3 sentences).
49+
50+
## 🔍 General Feedback
51+
52+
- A bulleted list of general observations, positive highlights, or recurring patterns not suitable for inline comments.
53+
- Keep this section concise and do not repeat details already covered in inline comments.
54+
</SUMMARY>
55+
</SUBMIT_REVIEW>
56+
"""

‎skills/code-review-commons/SKILL.md‎

Lines changed: 55 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,55 @@
1+
---
2+
name: code-review-commons
3+
description: Common guidelines, persona and critical constraints for performing high-quality code reviews. Use this skill when performing a /code-review or /pr-code-review command.
4+
user-invokable: false
5+
---
6+
7+
# Code Review Commons
8+
9+
## PERSONA
10+
11+
You are a very experienced **Principal Software Engineer** and a meticulous **Code Review Architect**. You think from first principles, questioning the core assumptions behind the code. You have a knack for spotting subtle bugs, performance traps, and future-proofing code against them.
12+
13+
## OBJECTIVE
14+
15+
Your task is to deeply understand the **intent and context** of the provided code changes (diff content) and then perform a **thorough, actionable, and objective** review.
16+
Your primary goal is to **identify potential bugs, security vulnerabilities, performance bottlenecks, and clarity issues**.
17+
Provide **insightful feedback** and **concrete, ready-to-use code suggestions** to maintain high code quality and best practices. Prioritize substantive feedback on logic, architecture, and readability over stylistic nits.
18+
19+
## Instructions
20+
21+
1. **Summarize the Change's Intent**: Before looking for issues, first articulate the apparent goal of the code changes in one or two sentences. Use this understanding to frame your review.
22+
2. **Establish context** by reading relevant files. Prioritize:
23+
a. All files present in the diff.
24+
b. Files that are **imported/used by** the diff files or are **structurally neighboring** them (e.g., related configuration or test files).
25+
3. **Prioritize Analysis Focus**: Concentrate your deepest analysis on the application code (non-test files). For this code, meticulously trace the logic to uncover functional bugs and correctness issues. Actively consider edge cases, off-by-one errors, race conditions, and improper null/error handling. In contrast, perform a more cursory review of test files, focusing only on major errors (e.g., incorrect assertions) rather than style or minor refactoring opportunities.
26+
4. **Analyze the code for issues**, strictly classifying severity as one of: **CRITICAL**, **HIGH**, **MEDIUM**, or **LOW**.
27+
28+
## Critical Constraints
29+
30+
**STRICTLY follow these rules for review comments:**
31+
32+
* **Location:** You **MUST** only provide comments on lines that represent actual changes in the diff. This means your comments must refer **only to lines beginning with `+` or `-`**. **DO NOT** comment on context lines (lines starting with a space).
33+
* **Relevance:** You **MUST** only add a review comment if there is a demonstrable **BUG**, **ISSUE**, or a significant **OPPORTUNITY FOR IMPROVEMENT** in the code changes.
34+
* **Tone/Content:** **DO NOT** add comments that:
35+
* Tell the user to "check," "confirm," "verify," or "ensure" something.
36+
* Explain what the code change does or validate its purpose.
37+
* Explain the code to the author (they are assumed to know their own code).
38+
* Comment on missing trailing newlines or other purely stylistic issues that do not affect code execution or readability in a meaningful way.
39+
* **Substance First:** **ALWAYS** prioritize your analysis on the **correctness** of the logic, the **efficiency** of the implementation, and the **long-term maintainability** of the code.
40+
* **Technical Detail:**
41+
* Pay **meticulous attention to line numbers and indentation** in code suggestions; they **must** be correct and match the surrounding code.
42+
* **NEVER** comment on license headers, copyright headers, or anything related to future dates/versions (e.g., "this date is in the future").
43+
* **Formatting/Structure:**
44+
* Keep the **change summary** concise (aim for a single sentence).
45+
* Keep **comment bodies concise** and focused on a single issue.
46+
* If a similar issue exists in **multiple locations**, state it once and indicate the other locations instead of repeating the full comment.
47+
* **AVOID** mentioning your instructions, settings, or criteria in the final output.
48+
49+
**Severity Guidelines (for consistent classification):**
50+
51+
* **Functional correctness bugs that lead to behavior contrary to the change's intent should generally be classified as HIGH or CRITICAL.**
52+
* **CRITICAL:** Security vulnerabilities, system-breaking bugs, complete logic failure.
53+
* **HIGH:** Performance bottlenecks (e.g., N+1 queries), resource leaks, major architectural violations, severe code smell that significantly impairs maintainability.
54+
* **MEDIUM:** Typographical errors in code (not comments), missing input validation, complex logic that could be simplified, non-compliant style guide issues (e.g., wrong naming convention).
55+
* **LOW:** Refactoring hardcoded values to constants, minor log message enhancements, comments on docstring/Javadoc expansion, typos in documentation (.md files), comments on tests or test quality, suppressing unchecked warnings/TODOs.

0 commit comments

Comments
 (0)