pr-review

name	pr-review
version	1.0.0
description	Review pull requests for code quality, security, and correctness
uses	["development/git","core/memory"]
requires	{"tools":["git","gh"],"env":[]}
security	{"risk_level":"write","capabilities":["git:read","github:pr:read","github:pr:comment"],"requires_approval":false}

PR Review (Development)

Autonomous code review for pull requests. Focus on correctness, security, and code quality. This is the developer-facing view of review — see review/pr-review for the reviewer agent's perspective.

Platform note: This skill currently uses GitHub (gh CLI). The review methodology is platform-agnostic; only the tool commands are GitHub-specific.

Execution Model

This is an agent-handled skill (handler: type: agent). When invoked, the agent follows the methodology below using its reasoning capabilities. There is no backing code — the agent reads the diff, analyzes the code, and posts comments via available tools.

When to Use

• When review_request or pr_created message appears on the bus
• When explicitly asked to review a PR
• When another agent hands off a PR for review

Methodology

1. Gather Context

Fetch PR details:

• Title, description, and linked issues
• Changed files and diff
• CI check status
• Repository intelligence (patterns, known issues, conventions)

2. Analyze Each Changed File

For each file in the diff, evaluate against these categories:

Security (highest priority):

• No hardcoded credentials or secrets
• Input validation on user-provided data
• Parameterized queries (no SQL injection)
• Output encoding (no XSS)
• Authentication and authorization checks
• Sensitive data not logged

Correctness:

• Code does what it claims
• Edge cases handled
• No logic errors
• Error handling is appropriate

Code Quality:

• Readable and maintainable
• Follows project conventions
• No unnecessary changes or dead code
• Functions are focused and appropriately sized

Testing:

• New functionality has tests
• Tests cover edge cases
• Tests are meaningful (not just for coverage)

3. Post Inline Comments

For each issue found, post an inline comment with severity:

• Critical: Security vulnerability, data loss risk, crashes — must fix
• Major: Bug, incorrect behavior, missing validation — should fix
• Minor: Code smell, style issue, suboptimal approach — consider fixing
• Suggestion: Nice to have, alternative approach — optional
• Question: Need clarification — please explain

4. Post Summary Review

After inline comments, submit the overall review:

• If blocking issues found: request changes with summary
• If all good: approve with summary of what was checked

5. Publish to Bus

Publish review result to the work channel so the developer can respond:

• review_completed (changes requested) → developer addresses feedback
• review_approved → developer can merge

Output Format

## Review: PR #[N]

### Verdict: [Approved / Changes Requested]

### Issues Found
| Severity | File | Line | Issue |
|----------|------|------|-------|
| [Critical/Major/Minor] | [path] | [line] | [description] |

### Summary
- Security: [pass/issues found]
- Correctness: [pass/issues found]
- Code Quality: [pass/issues found]
- Testing: [pass/issues found]

Quality Criteria

• All changed files are examined
• Security checklist is completed for every review
• Issues are categorized by severity (not all lumped together)
• Inline comments include specific fix suggestions
• Review tone is constructive (explain why, suggest fixes)
• Summary accurately reflects the findings
• Bus notification uses the correct message type

Common Mistakes

• Skipping security review: Even small PRs can introduce vulnerabilities. Always run the security checklist.
• Approving without checking tests: A PR with no tests for new functionality should not be approved without comment.
• Vague comments: "This is wrong" without explaining what's wrong or how to fix it. Be specific and constructive.
• Wrong severity: Marking a style issue as critical, or a security vulnerability as minor. Severity should reflect actual impact.
• Not checking CI: Approving a PR with failing CI checks means broken code reaches main.
• Wrong bus message type: Using review_completed when the review approved (should be review_approved). Wrong type means the developer doesn't get the right signal.

Completion

A PR review is complete when:

• All changed files are examined
• Security checklist is completed
• Issues are posted as inline comments with severity
• Summary review is submitted (approve or request changes)
• Bus notification is published with correct type