Skip to content

Commit 63750d8

Browse files
cynthialong0-0cynthialong0-0
authored
feat: make code review extension available for pr reviews (#18)
* feat: make code review available for pr reviews * minor updates * wrap the <output> in else condition * Update readme, put <context> into condition * update readme
1 parent a2fb26f commit 63750d8

File tree

2 files changed

+101
-31
lines changed

2 files changed

+101
-31
lines changed

‎README.md‎

Lines changed: 12 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -17,7 +17,18 @@ If you do not yet have Gemini CLI installed, or if the installed version is olde
1717

1818
## Use the extension
1919

20-
The Code Review extension adds the `/code-review` command to Gemini CLI which analyzes code changes on your current branch for quality issues.
20+
The Code Review extension adds the `/code-review` command to Gemini CLI which analyzes code changes on your current branch or specific pull request for quality issues.
21+
22+
23+
### Reviewing a pull request
24+
25+
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 [configure](https://github.com/google-gemini/gemini-cli/blob/main/docs/reference/configuration.md#environment-variables-and-env-files) the following environment variables:
26+
- `REPOSITORY`: The github repository which contains the pull request.
27+
- `PULL_REQUEST_NUMBER`: The pull request number that need the code review.
28+
- `ADDITIONAL_CONTEXT`: Additional context or specific area that should focus on.
29+
30+
Then trigger the review with `/code-review pr-review`.
31+
2132

2233
## Resources
2334

‎commands/code-review.toml‎

Lines changed: 89 additions & 30 deletions
Original file line numberDiff line numberDiff line change
@@ -10,15 +10,26 @@ Your primary goal is to **identify potential bugs, security vulnerabilities, per
1010
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.
1111
</OBJECTIVE>
1212
13+
!{ [ "{{args}}" = "pr-review" ] && {
14+
printf '
15+
<CONTEXT>
16+
**GitHub Repository**: %s
17+
**Pull Request Number**: %s
18+
**Additional User Instructions**: %s
19+
**Pull Review Details**: use `pull_request_read.get` tool to get the title, body, and metadata about the pull request.
20+
</CONTEXT>
21+
' "$REPOSITORY" "$PULL_REQUEST_NUMBER" "$ADDITIONAL_CONTEXT"
22+
} || echo '' }
23+
1324
<INSTRUCTIONS>
14-
1. **Execute the required command** to retrieve the changes: `git diff -U5 --merge-base origin/HEAD`.
25+
1. **Retrieve the changes**: !{ [ "{{args}}" = "pr-review" ] && echo 'call the `pull_request_read.get_diff` tool' || echo 'run `git diff -U5 --merge-base origin/HEAD`' }.
1526
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:
27+
3. **Establish context** by reading relevant files and context. Prioritize:
1728
a. All files present in the diff.
1829
b. Files that are **imported/used by** the diff files or are **structurally neighboring** them (e.g., related configuration or test files).
1930
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.
2031
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.
32+
!{ [ "{{args}}" = "pr-review" ] && echo "6. **Submit the Review on GitHub** following the instruction in the <SUBMIT_REVIEW> section" || echo '6. **Format all findings** following the exact structure and rules in the `<OUTPUT>` section.' }
2233
</INSTRUCTIONS>
2334
2435
<CRITICAL_CONSTRAINTS>
@@ -50,40 +61,88 @@ Provide **insightful feedback** and **concrete, ready-to-use code suggestions**
5061
* **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.
5162
</CRITICAL_CONSTRAINTS>
5263
53-
<OUTPUT>
54-
The output **MUST** be clean, concise, and structured exactly as follows.
64+
!{ [ "{{args}}" = "pr-review" ] && {
65+
printf '
66+
<SUBMIT_REVIEW>
67+
**Review Comment Formatting**
68+
69+
- **Line Accuracy:** Ensure suggestions perfectly align with the line numbers and indentation of the code they are intended to replace.
70+
71+
- Comments on the before (LEFT) diff **MUST** use the line numbers and corresponding code from the LEFT diff.
72+
73+
- Comments on the after (RIGHT) diff **MUST** use the line numbers and corresponding code from the RIGHT diff.
74+
75+
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.
76+
77+
2. **Add Comments and Suggestions:** For each formulated review comment, call `add_comment_to_pending_review`.
78+
79+
2a. For each suggested change, structure the comment payload using this exact template:
80+
81+
<COMMENT>
82+
[{{SEVERITY}}] {{COMMENT_TEXT}}
83+
84+
```suggestion
85+
{{CODE_SUGGESTION}}
86+
```
87+
</COMMENT>
88+
89+
2b. When there is no code suggestion, structure the comment payload using this exact template:
90+
91+
<COMMENT>
92+
[{{SEVERITY}}] {{COMMENT_TEXT}}
93+
</COMMENT>
94+
95+
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:
96+
97+
## 📋 Review Summary
98+
99+
A brief, high-level assessment of the Pull Request's objective and quality (2-3 sentences).
100+
101+
## 🔍 General Feedback
102+
103+
- A bulleted list of general observations, positive highlights, or recurring patterns not suitable for inline comments.
104+
- Keep this section concise and do not repeat details already covered in inline comments.
105+
</SUMMARY>
106+
</SUBMIT_REVIEW>
107+
'
108+
} || {
109+
printf '
110+
<OUTPUT>
111+
The output **MUST** be clean, concise, and structured exactly as follows.
55112
56-
**If no issues are found:**
113+
**If no issues are found:**
57114
58-
# Change summary: [Single sentence description of the overall change].
59-
No issues found. Code looks clean and ready to merge.
115+
# Change summary: [Single sentence description of the overall change].
116+
No issues found. Code looks clean and ready to merge.
60117
61-
**If issues are found:**
118+
**If issues are found:**
62119
63-
# Change summary: [Single sentence description of the overall change].
64-
[Optional general feedback for the entire change, e.g., unrelated change that should be in a different PR, or improved general approaches.]
120+
# Change summary: [Single sentence description of the overall change].
121+
[Optional general feedback for the entire change, e.g., unrelated change that should be in a different PR, or improved general approaches.]
65122
66-
## File: path/to/file/one
67-
### L<LINE_NUMBER>: [<SEVERITY>] Single sentence summary of the issue.
123+
## File: path/to/file/one
124+
### L<LINE_NUMBER>: [<SEVERITY>] Single sentence summary of the issue.
68125
69-
More details about the issue, including why it is an issue (e.g., "This could lead to a null pointer exception").
126+
More details about the issue, including why it is an issue (e.g., "This could lead to a null pointer exception").
70127
71-
Suggested change:
72-
```
73-
while (condition) {
74-
unchanged line;
75-
- remove this;
76-
+ replace it with this;
77-
+ and this;
78-
but keep this the same;
79-
}
80-
```
128+
Suggested change:
129+
```
130+
while (condition) {
131+
unchanged line;
132+
- remove this;
133+
+ replace it with this;
134+
+ and this;
135+
but keep this the same;
136+
}
137+
```
81138
82-
### L<LINE_NUMBER_2>: [MEDIUM] Summary of the next problem.
83-
More details about this problem, including where else it occurs if applicable (e.g., "Also seen in lines L45, L67 of this file.").
139+
### L<LINE_NUMBER_2>: [MEDIUM] Summary of the next problem.
140+
More details about this problem, including where else it occurs if applicable (e.g., "Also seen in lines L45, L67 of this file.").
84141
85-
## File: path/to/file/two
86-
### L<LINE_NUMBER_3>: [HIGH] Summary of the issue in the next file.
87-
Details...
88-
</OUTPUT>
142+
## File: path/to/file/two
143+
### L<LINE_NUMBER_3>: [HIGH] Summary of the issue in the next file.
144+
Details...
145+
</OUTPUT>
146+
'
147+
}}
89148
"""

0 commit comments

Comments
 (0)