PR Review Skill
Provide a clear, concise, and actionable review of Pull Requests. Focus on overall codebase quality, including readability, maintainability, functionality, adherence to best practices, performance optimizations, and testing coverage.
Focus Areas
- •Code Quality: Assess readability, organization, and maintainability.
- •Functionality: Ensure the PR meets its intended purpose and works as expected.
- •Best Practices: Evaluate adherence to coding standards, design patterns, and project guidelines.
- •Performance: Identify potential performance improvements or optimizations.
- •Testing: Review the comprehensiveness and effectiveness of test coverage.
- •Security: Identify any potential security vulnerabilities or concerns.
- •Bugs Found: List any bugs identified in the PR.
Critical Instructions
- •If you have nothing to say about a particular section, omit it from the review.
- •If there are no issues and the PR is good to go, mention it in the conclusion. No unnecessary feedback.
- •Avoid minor nitpicks and repetitive feedback.
Scoring Criteria
| Score | Level | Criteria |
|---|---|---|
| 90-100 | Exceptional | Clean, efficient, well-documented. >90% test coverage. No security issues. Optimal performance. |
| 75-89 | High Quality | Well-structured, maintainable. 70-90% test coverage. Minor optimization opportunities. |
| 60-74 | Average | Functional but needs improvement. 40-70% test coverage. Some code duplication. |
| 40-59 | Below Average | Significant structural issues. <40% test coverage. Multiple security concerns. |
| 0-39 | Poor | Major architectural problems. Missing/broken tests. Critical security vulnerabilities. |
Review Template
markdown
### AI Review Summary **Score:** [0-100] _Brief summary of the PR purpose and main changes._ **Key changes:** - Change 1 - Change 2 --- **Key Strengths** - **[Area]:** Description of strength - **[Area]:** Description of strength --- **Areas for Improvement** (if any) - **[Issue]:** _Suggestion:_ Actionable recommendation --- **Bugs Found** (if any) | Bug Name | Affected Files | Description | Confidence | | --------------------- | -------------- | ----------- | --------------- | | [Bug Link](#bug-name) | `path/file.ts` | Description | High/Medium/Low | ### Bug Details #### Bug: [Bug Name](#bug-name) - **Affected Files:** `path/file.ts` - **Description:** Detailed explanation - **Confidence:** High/Medium/Low --- **Issues Found** (if any) | Issue Type | Issue Name | Affected Components | Description | Severity | | ------------------- | ------------------------- | ------------------- | ----------- | --------------- | | Performance/Testing | [Issue Link](#issue-name) | Component | Description | High/Medium/Low | ### Issue Details #### Issue: [Issue Name](#issue-name) - **Type:** Performance/Testing - **Affected Components:** `path/file.ts` - **Description:** Detailed explanation - **Severity:** High/Medium/Low --- **Performance Considerations** (if any) - **[Optimization]:** Actionable suggestion --- **Testing** (if any) - **[Coverage Gap]:** Suggestion for additional tests --- **Conclusion** _Summary of overall quality and readiness for merging._
Best Practices
- •Use clear and concise language
- •Limit each section to 2-3 critical points
- •Use bullet points and clear headings
- •Provide actionable suggestions, not just complaints
- •Link bug/issue names to their details sections
- •Focus on impact, not style preferences