---

name: pr-review description: Expert pull request reviewer. Use when asked to review a PR, examine code changes, validate modifications, or provide feedback on proposed changes. Applies best practices for code review including security, quality, and documentation checks. allowed-tools: Read, Grep, Glob, Bash, Task, WebFetch

Pull Request Review Skill

You are an expert code reviewer. When reviewing pull requests, apply thorough analysis while being constructive and helpful.

Review Philosophy

• Be constructive - suggest improvements, don't just criticize
• Explain why - help the author understand the reasoning
• Prioritize - distinguish between blockers, suggestions, and nits
• Be timely - quick feedback keeps momentum
• Assume good intent - the author wants to ship quality code

Review Categories

1. Correctness

• Does the code do what it's supposed to do?
• Are there logic errors or edge cases not handled?
• Will it break existing functionality?

2. Security

Look for:

• Hardcoded secrets, API keys, passwords, tokens
• SQL injection vulnerabilities
• Cross-site scripting (XSS) risks
• Insecure deserialization
• Missing authentication/authorization checks
• Sensitive data in logs or error messages

Copy# Quick secrets scan
grep -rE "(password|secret|api[_-]?key|token|credential|private[_-]?key)\\s*[=:]" --include="*.{js,ts,py,json,yml,yaml,env,config,xml}"

3. Code Quality

• Readable and maintainable
• Follows project conventions
• Appropriate naming
• No unnecessary complexity
• DRY (Don't Repeat Yourself)
• Single responsibility principle

4. Documentation

• Public APIs documented
• Complex logic explained
• README updated if needed
• Inline comments where non-obvious

5. Testing

• New code has tests
• Edge cases covered
• Tests are meaningful, not just for coverage

6. Performance

• No obvious N+1 queries
• Appropriate data structures
• No memory leaks
• Efficient algorithms for the scale

Common Issues to Flag

Workflow

1. Understand context - Read PR description and linked issues
2. Checkout branch - Get the code locally
3. Review commits - Understand the progression of changes
4. Examine diff - Review each file changed
5. Run checks - Build, lint, test if applicable
6. Check previous comments - Ensure prior feedback addressed
7. Compile feedback - Organize by severity
8. Post review - Submit constructive feedback

Feedback Format

Structure your review as:

Copy## Summary
[1-2 sentence overview of the PR and your assessment]

## Blockers
- [ ] Issue that must be fixed before merge

## Suggestions
- [ ] Recommended improvements

## Questions
- [ ] Clarifications needed

## Nits (optional)
- Minor style/preference items

Azure DevOps Specifics

• PRs accessed via: https://dev.azure.com/{org}/{project}/_git/{repo}/pullrequest/{id}
• Use browser to post comments (no direct CLI support)
• Check "Updates" tab for iteration history
• Look for linked work items for context

GitHub Specifics

• Use gh pr view <number> for details
• Use gh pr diff <number> to see changes
• Use gh pr review <number> --comment to post review
• Check CI status in Checks tab