bug(/review): Fix agent not posting feedback in GitHub (#141)

This change modifies the prompt to constrain the agent on how the review
must be submitted to GitHub. This aims to improve what is seen in #134
where "more than 50% of the time PR review fails due to tool problems
posting the review."

Since this is occurring intermittently - this is a probabilistic issue,
not a permissions issue, which is why the prompt is being changed.

Primary changes: 
1. Sometimes the agent made tool calls for a fake repo `owner` to make
tool calls. The change instructs the agent to list the repository owner.
1. Surprisingly, even when the agent hallucinated a fake repo `owner`
and made tool calls with this, our logs show that these calls were
successful (so the agent thought things were working), which is why
workflow errors did not surface. I have filed a
[bug](github/github-mcp-server#842) with
GitHub MCP to ensure they are returning failures, and will ensure that
`gemini-cli` logs/telemetry is properly capturing and recording tool
call failures.
1. Sometimes the agent didn't attempt to make tool calls. The prompt was
made to be more explicit that this is a necessity.

Fixes #134

Author: leehagoodjames

.github/workflows/gemini-pr-review.yml

@@ -201,22 +201,27 @@ jobs:
             ## Role
 
             You are an expert code reviewer. You have access to tools to gather
-            PR information and perform the review. Use the available tools to
+            PR information and perform the review on GitHub. Use the available tools to
             gather information; do not ask for information to be provided.
 
+            ## Requirements
+            1. All feedback must be left on GitHub.
+            2. Any output that is not left in GitHub will not be seen.
+
             ## Steps
 
             Start by running these commands to gather the required data:
-            1. Run: echo "${PR_DATA}" to get PR details (JSON format)
-            2. Run: echo "${CHANGED_FILES}" to get the list of changed files
-            3. Run: echo "${PR_NUMBER}" to get the PR number
-            4. Run: echo "${ADDITIONAL_INSTRUCTIONS}" to see any specific review
+            1. Run: echo $"{REPOSITORY}" to get the github repository in <OWNER>/<REPO> format
+            2. Run: echo "${PR_DATA}" to get PR details (JSON format)
+            3. Run: echo "${CHANGED_FILES}" to get the list of changed files
+            4. Run: echo "${PR_NUMBER}" to get the PR number
+            5. Run: echo "${ADDITIONAL_INSTRUCTIONS}" to see any specific review
                instructions from the user
-            5. Run: gh pr diff "${PR_NUMBER}" to see the full diff and reference
+            6. Run: gh pr diff "${PR_NUMBER}" to see the full diff and reference
             Context section to understand it
-            6. For any specific files, use: cat filename, head -50 filename, or
+            7. For any specific files, use: cat filename, head -50 filename, or
                tail -50 filename
-            7. If ADDITIONAL_INSTRUCTIONS contains text, prioritize those
+            8. If ADDITIONAL_INSTRUCTIONS contains text, prioritize those
                specific areas or focus points in your review. Common instruction
                examples: "focus on security", "check performance", "review error
                handling", "check for breaking changes"
@@ -376,11 +381,11 @@ jobs:
 
             ## Review
 
-            Once you have the information, provide a comprehensive code review by:
+            Once you have the information and are ready to leave a review on GitHub, post the review to GitHub using the GitHub MCP tool by:
             1. Creating a pending review: Use the mcp__github__create_pending_pull_request_review to create a Pending Pull Request Review.
 
             2. Adding review comments:
-                2.1 Use the mcp__github__add_comment_to_pending_review to add comments to the Pending Pull Request Review. Inline comments are preferred whenever possible, so repeat this step, calling mcp__github__add_comment_to_pending_review, as needed. All comments about specific lines of code should use inline comments. It is preferred to use code suggestions when possible, which include a code block that is labeled "suggestion", which contains what the new code should be. All comments should also have a severity. They syntax is:
+                2.1 Use the mcp__github__add_comment_to_pending_review to add comments to the Pending Pull Request Review. Inline comments are preferred whenever possible, so repeat this step, calling mcp__github__add_comment_to_pending_review, as needed. All comments about specific lines of code should use inline comments. It is preferred to use code suggestions when possible, which include a code block that is labeled "suggestion", which contains what the new code should be. All comments should also have a severity. The syntax is:
                   Normal Comment Syntax:
                   <COMMENT>
                   {{SEVERITY}} {{COMMENT_TEXT}}
@@ -431,6 +436,10 @@ jobs:
                 - Highlight positive aspects of the implementation
                 - Note any recurring themes across files
 
+            ## Final Instructions
+
+            Remember, you are running in a VM and no one reviewing your output. Your review must be posted to GitHub using the MCP tools to create a pending review, add comments to the pending review, and submit the pending review.
+
 
       - name: 'Post PR review failure comment'
         if: |-

examples/workflows/pr-review/gemini-pr-review.yml

@@ -201,22 +201,27 @@ jobs:
             ## Role
 
             You are an expert code reviewer. You have access to tools to gather
-            PR information and perform the review. Use the available tools to
+            PR information and perform the review on GitHub. Use the available tools to
             gather information; do not ask for information to be provided.
 
+            ## Requirements
+            1. All feedback must be left on GitHub.
+            2. Any output that is not left in GitHub will not be seen.
+
             ## Steps
 
             Start by running these commands to gather the required data:
-            1. Run: echo "${PR_DATA}" to get PR details (JSON format)
-            2. Run: echo "${CHANGED_FILES}" to get the list of changed files
-            3. Run: echo "${PR_NUMBER}" to get the PR number
-            4. Run: echo "${ADDITIONAL_INSTRUCTIONS}" to see any specific review
+            1. Run: echo $"{REPOSITORY}" to get the github repository in <OWNER>/<REPO> format
+            2. Run: echo "${PR_DATA}" to get PR details (JSON format)
+            3. Run: echo "${CHANGED_FILES}" to get the list of changed files
+            4. Run: echo "${PR_NUMBER}" to get the PR number
+            5. Run: echo "${ADDITIONAL_INSTRUCTIONS}" to see any specific review
                instructions from the user
-            5. Run: gh pr diff "${PR_NUMBER}" to see the full diff and reference
+            6. Run: gh pr diff "${PR_NUMBER}" to see the full diff and reference
             Context section to understand it
-            6. For any specific files, use: cat filename, head -50 filename, or
+            7. For any specific files, use: cat filename, head -50 filename, or
                tail -50 filename
-            7. If ADDITIONAL_INSTRUCTIONS contains text, prioritize those
+            8. If ADDITIONAL_INSTRUCTIONS contains text, prioritize those
                specific areas or focus points in your review. Common instruction
                examples: "focus on security", "check performance", "review error
                handling", "check for breaking changes"
@@ -376,11 +381,11 @@ jobs:
 
             ## Review
 
-            Once you have the information, provide a comprehensive code review by:
+            Once you have the information and are ready to leave a review on GitHub, post the review to GitHub using the GitHub MCP tool by:
             1. Creating a pending review: Use the mcp__github__create_pending_pull_request_review to create a Pending Pull Request Review.
 
             2. Adding review comments:
-                2.1 Use the mcp__github__add_comment_to_pending_review to add comments to the Pending Pull Request Review. Inline comments are preferred whenever possible, so repeat this step, calling mcp__github__add_comment_to_pending_review, as needed. All comments about specific lines of code should use inline comments. It is preferred to use code suggestions when possible, which include a code block that is labeled "suggestion", which contains what the new code should be. All comments should also have a severity. They syntax is:
+                2.1 Use the mcp__github__add_comment_to_pending_review to add comments to the Pending Pull Request Review. Inline comments are preferred whenever possible, so repeat this step, calling mcp__github__add_comment_to_pending_review, as needed. All comments about specific lines of code should use inline comments. It is preferred to use code suggestions when possible, which include a code block that is labeled "suggestion", which contains what the new code should be. All comments should also have a severity. The syntax is:
                   Normal Comment Syntax:
                   <COMMENT>
                   {{SEVERITY}} {{COMMENT_TEXT}}
@@ -431,6 +436,10 @@ jobs:
                 - Highlight positive aspects of the implementation
                 - Note any recurring themes across files
 
+            ## Final Instructions
+
+            Remember, you are running in a VM and no one reviewing your output. Your review must be posted to GitHub using the MCP tools to create a pending review, add comments to the pending review, and submit the pending review.
+
 
       - name: 'Post PR review failure comment'
         if: |-