|
| 1 | +description = "Review a specific pull request" |
| 2 | + |
| 3 | +prompt = """ |
| 4 | +## Mission: Comprehensive Pull Request Review |
| 5 | +
|
| 6 | +Today, our mission is to meticulously review community pull requests (PRs) for this project. We will proceed systematically, evaluating each candidate PR for its quality, adherence to standards, and readiness for merging. |
| 7 | +
|
| 8 | +### Workflow: |
| 9 | +
|
| 10 | +1. **PR Preparation & Initial Assessment**: |
| 11 | + * **You will check out the designated PR {{args}}** into a temporary branch. |
| 12 | + * **Execute the preflight checks (`npm run preflight`)**. This includes building, linting, and running all unit tests. |
| 13 | + * Analyze the output of these preflight checks, noting any failures, warnings, or linting issues. |
| 14 | +
|
| 15 | +2. **In-Depth Code Review**: |
| 16 | + * **Your primary role is to conduct a thorough and in-depth code review** of the changes introduced in the PR. Focus your analysis on the following criteria: |
| 17 | + * **Correctness**: Does the code achieve its stated purpose without bugs or logical errors? |
| 18 | + * **Maintainability**: Is the code clean, well-structured, and easy to understand and modify in the future? Consider factors like code clarity, modularity, and adherence to established design patterns. |
| 19 | + * **Readability**: Is the code well-commented (where necessary) and consistently formatted according to our project's coding style guidelines? |
| 20 | + * **Efficiency**: Are there any obvious performance bottlenecks or resource inefficiencies introduced by the changes? |
| 21 | + * **Security**: Are there any potential security vulnerabilities or insecure coding practices? |
| 22 | + * **Edge Cases and Error Handling**: Does the code appropriately handle edge cases and potential errors? |
| 23 | + * **Testability**: Is the new or modified code adequately covered by tests (even if preflight checks pass)? Suggest additional test cases that would improve coverage or robustness. |
| 24 | + * Based on your analysis, you will determine if the PR is **safe to merge**. |
| 25 | +
|
| 26 | +3. **Reviewing Previous Feedback**: |
| 27 | + * **Access and examine the PR's history** to identify any **outstanding requests or unresolved comments from previous reviews**. Incorporate these into your current review and explicitly highlight if they have been adequately addressed in the current state of the PR. |
| 28 | +
|
| 29 | +4. **Decision and Output Generation**: |
| 30 | + * **If the PR is deemed safe to merge** (after your comprehensive review and considering previous feedback): |
| 31 | + * Draft a **friendly, concise, and professional approval message**. |
| 32 | + * **The approval message should:** |
| 33 | + * Clearly state that the PR is approved. |
| 34 | + * Briefly acknowledge the quality or value of the contribution (e.g., "Great work on X feature!" or "Appreciate the fix for Y issue!"). |
| 35 | + * **Do NOT mention the preflight checks or unit testing**, as these are internal processes. |
| 36 | + * Be suitable for public display on GitHub. |
| 37 | + * **If the PR is NOT safe to merge**: |
| 38 | + * Provide a **clear, constructive, and detailed summary of the issues found**. |
| 39 | + * Suggest **specific actionable changes** required for the PR to become merge-ready. |
| 40 | + * Ensure the feedback is professional and encourages the contributor. |
| 41 | +
|
| 42 | +### Post-PR Action: |
| 43 | +
|
| 44 | +* After providing your review and decision for the current PR, I will wait for you to perform any manual testing you wish to do. Please let me know when you are finished. |
| 45 | +* Once you have confirmed that you are done, I will switch to the `main` branch, clean up the local branch, and perform a pull to ensure we are synchronized with the latest upstream changes for the next review. |
| 46 | +
|
| 47 | +""" |
0 commit comments