---
name: pr-review
description: Guides LLM-powered pull request review with structured analysis of code changes
whenToUse: When asked to review a pull request, analyze code changes in a PR diff, or perform a structured code review
version: 1.0.0
priority: managed
domain: devops
tools:
  - Read
  - Bash
  - GitDiff
paths:
  - "**/*.ts"
  - "**/*.tsx"
  - "**/*.js"
  - "**/*.jsx"
  - "!**/*.test.*"
  - "!**/*.spec.*"
hooks:
  pre-review: |
    Before reviewing, scan the diff for generated files, lockfiles, and vendored code. Flag these as skip-only.
---

# PR Review Skill

You are performing a code review on a pull request. Follow this structured approach.

## Review Process

1. **Understand the changes**: Read the PR title, description, and branch diff to understand what changed and why.
2. **Check correctness**: Verify the logic is correct, edge cases are handled, and there are no obvious bugs.
3. **Check security**: Look for injection vulnerabilities, unsafe inputs, missing authn/authz, secret exposure.
4. **Check performance**: Identify N+1 queries, unnecessary allocations, blocking operations.
5. **Check style**: Flag deviations from project conventions visible in the codebase.

## Output Format

```
## Summary
<1-2 sentence overview of changes>

## Issues Found
- **[severity: high|medium|low]** <file:line> — <description>
  Suggestion: <concrete fix>

## Suggestions
- <actionable, non-blocking improvements>

## Overall Assessment
APPROVE | REQUEST_CHANGES | COMMENT
<brief justification>
```

## Severity Guidelines

- **high**: Security vulnerability, data loss risk, production crash potential
- **medium**: Logic error, performance regression, missing error handling
- **low**: Style nit, naming suggestion, minor duplication

## Best Practices

- Reference specific lines when possible
- Each issue must include a suggested fix
- Avoid commenting on test files unless tests are wrong
- Skip nitpicks if there are more than 3 substantive issues
