diff --git a/README.md b/README.md index e7648d5..57ab85b 100644 --- a/README.md +++ b/README.md @@ -17,18 +17,7 @@ If you do not yet have Gemini CLI installed, or if the installed version is olde ## Use the extension -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. - - -### Reviewing a pull request - -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: -- `REPOSITORY`: The github repository which contains the pull request. -- `PULL_REQUEST_NUMBER`: The pull request number that need the code review. -- `ADDITIONAL_CONTEXT`: Additional context or specific area that should focus on. - -Then trigger the review with `/code-review pr-review`. - +The Code Review extension adds the `/code-review` command to Gemini CLI which analyzes code changes on your current branch for quality issues. ## Resources diff --git a/commands/code-review.toml b/commands/code-review.toml index 374cf7a..beaeacf 100644 --- a/commands/code-review.toml +++ b/commands/code-review.toml @@ -10,26 +10,15 @@ Your primary goal is to **identify potential bugs, security vulnerabilities, per 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. -!{ [ "{{args}}" = "pr-review" ] && { - printf ' - - **GitHub Repository**: %s - **Pull Request Number**: %s - **Additional User Instructions**: %s - **Pull Review Details**: use `pull_request_read.get` tool to get the title, body, and metadata about the pull request. - - ' "$REPOSITORY" "$PULL_REQUEST_NUMBER" "$ADDITIONAL_CONTEXT" -} || echo '' } - -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`' }. +1. **Execute the required command** to retrieve the changes: `git diff -U5 --merge-base origin/HEAD`. 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. -3. **Establish context** by reading relevant files and context. Prioritize: +3. **Establish context** by reading relevant files. Prioritize: a. All files present in the diff. b. Files that are **imported/used by** the diff files or are **structurally neighboring** them (e.g., related configuration or test files). 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. 5. **Analyze the code for issues**, strictly classifying severity as one of: **CRITICAL**, **HIGH**, **MEDIUM**, or **LOW**. -!{ [ "{{args}}" = "pr-review" ] && echo "6. **Submit the Review on GitHub** following the instruction in the section" || echo '6. **Format all findings** following the exact structure and rules in the `` section.' } +6. **Format all findings** following the exact structure and rules in the `` section. @@ -61,88 +50,40 @@ Provide **insightful feedback** and **concrete, ready-to-use code suggestions** * **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. -!{ [ "{{args}}" = "pr-review" ] && { - printf ' - - **Review Comment Formatting** - - - **Line Accuracy:** Ensure suggestions perfectly align with the line numbers and indentation of the code they are intended to replace. - - - Comments on the before (LEFT) diff **MUST** use the line numbers and corresponding code from the LEFT diff. - - - Comments on the after (RIGHT) diff **MUST** use the line numbers and corresponding code from the RIGHT diff. - - 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. - - 2. **Add Comments and Suggestions:** For each formulated review comment, call `add_comment_to_pending_review`. - - 2a. For each suggested change, structure the comment payload using this exact template: - - - [{{SEVERITY}}] {{COMMENT_TEXT}} - - ```suggestion - {{CODE_SUGGESTION}} - ``` - - - 2b. When there is no code suggestion, structure the comment payload using this exact template: - - - [{{SEVERITY}}] {{COMMENT_TEXT}} - - - 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: - - ## 📋 Review Summary - - A brief, high-level assessment of the Pull Request's objective and quality (2-3 sentences). - - ## 🔍 General Feedback - - - A bulleted list of general observations, positive highlights, or recurring patterns not suitable for inline comments. - - Keep this section concise and do not repeat details already covered in inline comments. - - - ' -} || { - printf ' - - The output **MUST** be clean, concise, and structured exactly as follows. + +The output **MUST** be clean, concise, and structured exactly as follows. - **If no issues are found:** +**If no issues are found:** - # Change summary: [Single sentence description of the overall change]. - No issues found. Code looks clean and ready to merge. +# Change summary: [Single sentence description of the overall change]. +No issues found. Code looks clean and ready to merge. - **If issues are found:** +**If issues are found:** - # Change summary: [Single sentence description of the overall change]. - [Optional general feedback for the entire change, e.g., unrelated change that should be in a different PR, or improved general approaches.] +# Change summary: [Single sentence description of the overall change]. +[Optional general feedback for the entire change, e.g., unrelated change that should be in a different PR, or improved general approaches.] - ## File: path/to/file/one - ### L: [] Single sentence summary of the issue. +## File: path/to/file/one +### L: [] Single sentence summary of the issue. - More details about the issue, including why it is an issue (e.g., "This could lead to a null pointer exception"). +More details about the issue, including why it is an issue (e.g., "This could lead to a null pointer exception"). - Suggested change: - ``` - while (condition) { - unchanged line; - - remove this; - + replace it with this; - + and this; - but keep this the same; - } - ``` +Suggested change: +``` + while (condition) { + unchanged line; +- remove this; ++ replace it with this; ++ and this; + but keep this the same; + } +``` - ### L: [MEDIUM] Summary of the next problem. - More details about this problem, including where else it occurs if applicable (e.g., "Also seen in lines L45, L67 of this file."). +### L: [MEDIUM] Summary of the next problem. +More details about this problem, including where else it occurs if applicable (e.g., "Also seen in lines L45, L67 of this file."). - ## File: path/to/file/two - ### L: [HIGH] Summary of the issue in the next file. - Details... - - ' -}} +## File: path/to/file/two +### L: [HIGH] Summary of the issue in the next file. +Details... + """