Revert "feat: make code review extension available for pr reviews (#18)"

This reverts commit 63750d8.

Author: mctavish

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
 

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.
 </OBJECTIVE>
 
-!{ [ "{{args}}" = "pr-review" ] && {
-    printf '
-    <CONTEXT>
-        **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.
-    </CONTEXT>
-    ' "$REPOSITORY" "$PULL_REQUEST_NUMBER" "$ADDITIONAL_CONTEXT"
-} || echo '' }
-
 <INSTRUCTIONS>
-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 <SUBMIT_REVIEW> section" || echo '6. **Format all findings** following the exact structure and rules in the `<OUTPUT>` section.' }
+6. **Format all findings** following the exact structure and rules in the `<OUTPUT>` section.
 </INSTRUCTIONS>
 
 <CRITICAL_CONSTRAINTS>
@@ -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.
 </CRITICAL_CONSTRAINTS>
 
-!{ [ "{{args}}" = "pr-review" ] && {
-    printf '
-    <SUBMIT_REVIEW>
-    **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:
-
-            <COMMENT>
-            [{{SEVERITY}}] {{COMMENT_TEXT}}
-
-            ```suggestion
-            {{CODE_SUGGESTION}}
-            ```
-            </COMMENT>
-
-        2b. When there is no code suggestion, structure the comment payload using this exact template:
-
-            <COMMENT>
-            [{{SEVERITY}}] {{COMMENT_TEXT}}
-            </COMMENT>
-
-    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.
-        </SUMMARY>
-    </SUBMIT_REVIEW>
-    '
-} || {
-    printf '
-    <OUTPUT>
-    The output **MUST** be clean, concise, and structured exactly as follows.
+<OUTPUT>
+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<LINE_NUMBER>: [<SEVERITY>] Single sentence summary of the issue.
+## File: path/to/file/one
+### L<LINE_NUMBER>: [<SEVERITY>] 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<LINE_NUMBER_2>: [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<LINE_NUMBER_2>: [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<LINE_NUMBER_3>: [HIGH] Summary of the issue in the next file.
-    Details...
-    </OUTPUT>    
-    '
-}}
+## File: path/to/file/two
+### L<LINE_NUMBER_3>: [HIGH] Summary of the issue in the next file.
+Details...
+</OUTPUT>
 """