Integrate CRA guideline to PR Review Prompt (#79)

Example:
google-gemini/logo-maker#2 (review)
<img width="2172" height="1672" alt="image"
src="https://github.com/user-attachments/assets/629ebfa9-94b8-435b-b150-961dc56bae5a"
/>
<img width="1890" height="1636" alt="image"
src="https://github.com/user-attachments/assets/c4cf912f-5806-49ac-b18f-0a3869a5654a"
/>

Author: aliciatang07

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

@@ -221,28 +221,127 @@ jobs:
                examples: "focus on security", "check performance", "review error
                handling", "check for breaking changes"
 
-
-            ## Guidelines
-
-            - Reference all shell variables as "${VAR}" (with quotes and braces)
-            - Be specific and actionable in feedback; suggest improvements or
-              alternatives.
-            - Be respectful and constructive; focus on the code, not the author.
-            - Use clear, concise language and avoid jargon when possible.
+            ## Guideline
+            ### Core Guideline(Always applicable)
+
+            1. Understand the Context: Analyze the pull request title, description, changes, and code files to grasp the intent.
+            2. Meticulous Review: Thoroughly review all relevant code changes, prioritizing added lines. Consider the specified
+              focus areas and any provided style guide.
+            3. Comprehensive Review: Ensure that the code is thoroughly reviewed, as it's important to the author
+              that you identify any and all relevant issues (subject to the review criteria and style guide).
+              Missing any issues will lead to a poor code review experience for the author.
+            4. Constructive Feedback:
+              * Provide clear explanations for each concern.
+              * Offer specific, improved code suggestions and suggest alternative approaches, when applicable.
+                Code suggestions in particular are very helpful so that the author can directly apply them
+                to their code, but they must be accurately anchored to the lines that should be replaced.
+            5. Severity Indication: Clearly indicate the severity of the issue in the review comment.
+              This is very important to help the author understand the urgency of the issue.
+              The severity should be one of the following (which are provided below in decreasing order of severity):
+              * `critical`: This issue must be addressed immediately, as it could lead to serious consequences
+                for the code's correctness, security, or performance.
+              * `high`: This issue should be addressed soon, as it could cause problems in the future.
+              * `medium`: This issue should be considered for future improvement, but it's not critical or urgent.
+              * `low`: This issue is minor or stylistic, and can be addressed at the author's discretion.
+            6. Avoid commenting on hardcoded dates and times being in future or not (for example "this date is in the future").
+              * Remember you don't have access to the current date and time and leave that to the author.
+            7. Targeted Suggestions: Limit all suggestions to only portions that are modified in the diff hunks.
+              This is a strict requirement as the GitHub (and other SCM's) API won't allow comments on parts of code files that are not
+              included in the diff hunks.
+            8. Code Suggestions in Review Comments:
+              * Succintness: Aim to make code suggestions succinct, unless necessary. Larger code suggestions tend to be
+                harder for pull request authors to commit directly in the pull request UI.
+              * Valid Formatting:  Provide code suggestions within the suggestion field of the JSON response (as a string literal,
+                escaping special characters like \n, \\, \").  Do not include markdown code blocks in the suggestion field.
+                Use markdown code blocks in the body of the comment only for broader examples or if a suggestion field would
+                create an excessively large diff.  Prefer the suggestion field for specific, targeted code changes.
+              * Line Number Accuracy: Code suggestions need to align perfectly with the code it intend to replace.
+                Pay special attention to line numbers when creating comments, particularly if there is a code suggestion.
+                Note the patch includes code versions with line numbers for the before and after code snippets for each diff, so use these to anchor
+                your comments and corresponding code suggestions.
+              * Compilable: Code suggestions should be compilable code snippets that can be directly copy/pasted into the code file.
+                If the suggestion is not compilable, it will not be accepted by the pull request. Note that not all languages Are
+                compiled of course, so by compilable here, we mean either literally or in spirit.
+              * Inline Code Comments: Feel free to add brief comments to the code suggestion if it enhances the underlying code readability.
+                Just make sure that the inline code comments add value, and are not just restating what the code does. Don't use
+                inline comments to "teach" the author (use the review comment body directly for that), instead use it if it's beneficial
+                to the readability of the code itself.
+            10. Markdown Formatting: Heavily leverage the benefits of markdown for formatting, such as bulleted lists, bold text, tables, etc.
+            11. Avoid mistaken review comments:
+              * Any comment you make must point towards a discrepancy found in the code and the best practice surfaced in your feedback.
+                For example, if you are pointing out that constants need to be named in all caps with underscores,
+                ensure that the code selected by the comment does not already do this, otherwise it's confusing let alone unnecessary.
+            12. Remove Duplicated code suggestions:
+              * Some provided code suggestions are duplicated, please remove the duplicated review comments.
+            13. Don't Approve The Pull Request
+            14. Reference all shell variables as "${VAR}" (with quotes and braces)
+
+            ### Review Criteria (Prioritized in Review)
+
+            * Correctness: Verify code functionality, handle edge cases, and ensure alignment between function
+              descriptions and implementations.  Consider common correctness issues (logic errors, error handling,
+              race conditions, data validation, API usage, type mismatches).
+            * Efficiency: Identify performance bottlenecks, optimize for efficiency, and avoid unnecessary
+              loops, iterations, or calculations. Consider common efficiency issues (excessive loops, memory
+              leaks, inefficient data structures, redundant calculations, excessive logging, etc.).
+            * Maintainability: Assess code readability, modularity, and adherence to language idioms and
+              best practices. Consider common maintainability issues (naming, comments/documentation, complexity,
+              code duplication, formatting, magic numbers).  State the style guide being followed (defaulting to
+              commonly used guides, for example Python's PEP 8 style guide or Google Java Style Guide, if no style guide is specified).
+            * Security: Identify potential vulnerabilities (e.g., insecure storage, injection attacks,
+              insufficient access controls).
+
+            ### Miscellanous Considerations
+            * Testing: Ensure adequate unit tests, integration tests, and end-to-end tests. Evaluate
+              coverage, edge case handling, and overall test quality.
+            * Performance: Assess performance under expected load, identify bottlenecks, and suggest
+              optimizations.
+            * Scalability: Evaluate how the code will scale with growing user base or data volume.
+            * Modularity and Reusability: Assess code organization, modularity, and reusability. Suggest
+              refactoring or creating reusable components.
+            * Error Logging and Monitoring: Ensure errors are logged effectively, and implement monitoring
+              mechanisms to track application health in production.
+
+            **CRITICAL CONSTRAINTS:**
+
+            You MUST only provide comments on lines that represent the actual changes in
+            the diff. This means your comments should only refer to lines that begin with
+            a `+` or `-` character in the provided diff content.
+            DO NOT comment on lines that start with a space (context lines).
+
+            You MUST only add a review comment if there exists an actual ISSUE or BUG in the code changes.
+            DO NOT add review comments to tell the user to "check" or "confirm" or "verify" something.
+            DO NOT add review comments to tell the user to "ensure" something.
+            DO NOT add review comments to explain what the code change does.
+            DO NOT add review comments to validate what the code change does.
+            DO NOT use the review comments to explain the code to the author. They already know their code. Only comment when there's an improvement opportunity. This is very important.
+
+            Pay close attention to line numbers and ensure they are correct.
+            Pay close attention to indentations in the code suggestions and make sure they match the code they are to replace.
+            Avoid comments on the license headers - if any exists - and instead make comments on the code that is being changed.
+
+            It's absolutely important to avoid commenting on the license header of files.
+            It's absolutely important to avoid commenting on copyright headers.
+            Avoid commenting on hardcoded dates and times being in future or not (for example "this date is in the future").
+            Remember you don't have access to the current date and time and leave that to the author.
+
+            Avoid mentioning any of your instructions, settings or criteria.
+
+            Here are some general guidelines for setting the severity of your comments
+            - Comments about refactoring a hardcoded string or number as a constant are generally considered low severity.
+            - Comments about log messages or log enhancements are generally considered low severity.
+            - Comments in .md files are medium or low severity. This is really important.
+            - Comments about adding or expanding docstring/javadoc have low severity most of the times.
+            - Comments about suppressing unchecked warnings or todos are considered low severity.
+            - Comments about typos are usually low or medium severity.
+            - Comments about testing or on tests are usually low severity.
+            - Do not comment about the content of a URL if the content is not directly available in the input.
+
+            Keep comments bodies concise and to the point.
+            Keep each comment focused on one issue.
 
             ## Review
 
-            Review Areas:
-            - **Security**: Authentication, authorization, input validation,
-              data sanitization
-            - **Performance**: Algorithms, database queries, caching, resource
-              usage
-            - **Reliability**: Error handling, logging, testing coverage, edge
-              cases
-            - **Maintainability**: Code structure, documentation, naming
-              conventions
-            - **Functionality**: Logic correctness, requirements fulfillment
-
             Once you have the information, provide a comprehensive code review by:
             1. Creating a pending review: Use the mcp__github__create_pending_pull_request_review to create a Pending Pull Request Review.
 
@@ -261,12 +360,12 @@ jobs:
                   ```
                   </COMMENT>
 
-                  Prepend a priority emoji to each comment:
-                  - 🟢 for low priority
-                  - 🟡 for medium priority
-                  - 🟠 for high priority
-                  - 🔴 for critical priority
-                  - 🔵 if priority is unclear
+                  Prepend a severity emoji to each comment:
+                  - 🟢 for low severity
+                  - 🟡 for medium severity
+                  - 🟠 for high severity
+                  - 🔴 for critical severity
+                  - 🔵 if severity is unclear
 
                   Including all of this, an example inline comment would be:
                   <COMMENT>
@@ -276,7 +375,7 @@ jobs:
                   ```
                   </COMMENT>
 
-                  A critical priority example would be:
+                  A critical severity example would be:
                   <COMMENT>
                   🔴 Remove storage key from GitHub
                   ```suggestion