GitHub PR Reviewer

Performs rigorous peer review on GitHub Pull Request diffs. Evaluates logic correctness, edge cases, security regressions, test coverage, and documentation.

1. Purpose

Provide constructive, objective code review feedback with concrete code suggestions.

2. When to Use

Use this skill when:

• Reviewing open pull requests (gh pr diff).
• Providing review verdicts (APPROVE, REQUEST_CHANGES, COMMENT).
• Auditing security and regression risks before merging.

3. When Not to Use

• Do not use to create PRs; use github-pr-creator.
• Do not use for general repository architecture exploration; use repo-inspector.

4. Required Inputs

• pr_diff: The unified git diff of the PR.
• pr_description: Author's statement of intent.

5. Missing-Input Behavior

1. If pr_diff is empty: state "Diff is empty; no changes to review."
2. Always justify REQUEST_CHANGES with at least one blocker referencing exact line numbers.

6. Procedure

Follow these numbered actions:

1. Action 1: Understand Author's Intent
   • Read PR description and linked issue requirements.
2. Action 2: Scan for Security Vulnerabilities
   • Check SQL injection, leaked tokens, unescaped user input, path traversal.
3. Action 3: Verify Test Coverage
   • Check if new logic paths have corresponding automated tests in diff.
4. Action 4: Formulate Review Comments
   • Reference exact file and line number with suggested fixes.
5. Action 5: Determine Verdict
   • APPROVE or REQUEST_CHANGES.

7. Decision Rules

• If diff modifies authentication or encryption: mandate high-security review check.
• If diff lacks tests for new feature: require test case before approval.

8. Output Format

Emit the review using this template:

### GitHub PR Review

- **Verdict**: [APPROVE | REQUEST_CHANGES | COMMENT]
- **Summary**: [1-2 sentences on diff quality]

#### Actionable Comments
- **File**: `[file:line]`
  - **Severity**: [Blocker | Warning | Nit]
  - **Issue**: [Description]
  - **Suggestion**:
    ```suggestion
    [Replacement code]
    ```

9. Verification Checklist

• Verdict accurately reflects presence of blockers.
• Every comment references file and line.
• Concrete code replacement suggestion provided.

10. Common Failures and Recovery

11. Stop or Escalation Conditions

Stop and ask the user when:

• Diff is too large (> 2,500 lines) for single-turn review.

12. Examples

Example 1: Successful Execution

Input:

--- a/src/auth.ts
+++ b/src/auth.ts
@@ -10,2 +10,2 @@ export function hashPassword(pass: string) {
-  return bcrypt.hash(pass, 12);
+  return pass; // temporary test

Output:

### GitHub PR Review

- **Verdict**: REQUEST_CHANGES
- **Summary**: Critical security regression: password hashing was replaced with plaintext return.

#### Actionable Comments
- **File**: `src/auth.ts:11`
  - **Severity**: Blocker
  - **Issue**: Passwords must never be stored or returned in plaintext.
  - **Suggestion**:
    ```suggestion
    return bcrypt.hash(pass, 12);
    ```

Example 2: Ambiguous or Missing Input

Input:

Review empty PR.

Output:

### GitHub PR Review: No Changes

- **Verdict**: APPROVE (No Changes)
- **Summary**: Diff is empty.

Example 3: Expected Final Output

Output:

### GitHub PR Review

- **Verdict**: APPROVE
- **Summary**: Clean implementation of token expiration check with comprehensive unit tests.