Easy PR Review

Conduct a thorough pull request review with structured feedback and actionable comments.

When to Use This Command

Run this command when you need to:

• Review a pull request systematically covering code quality, security, and correctness
• Generate structured review comments that can be posted directly to GitHub
• Catch common issues like missing tests, security vulnerabilities, or performance regressions

Consider alternatives when:

• You only need a quick glance at a small cosmetic change like a typo fix
• The PR is an automated dependency update that just needs a version bump approval

Quick Start

Configuration

Copy
name: easy-pr-review
type: command
category: git-workflow

Example Invocation

Copy
claude command:run easy-pr-review --pr 142

Example Output

Reviewing PR #142: "Add user notification preferences"
Fetching diff... 8 files changed, +347 -89

Code Quality:
  [WARN] src/services/notifications.ts:45 - Unhandled promise rejection
  [INFO] src/models/preferences.ts:12 - Consider using enum instead of string union

Security:
  [CRITICAL] src/api/routes.ts:78 - User input not sanitized before DB query

Tests:
  [WARN] Missing test coverage for NotificationService.sendBatch()

Summary: 1 critical, 1 warning, 1 info | Recommend: Request Changes

Core Concepts

Review Dimensions Overview

Aspect	Details
Code Quality	Readability, naming conventions, DRY principles, complexity analysis
Security	Input validation, injection attacks, XSS, auth bypass, secret exposure
Performance	N+1 queries, unnecessary re-renders, memory leaks, large payloads
Testing	Coverage gaps, edge cases, integration tests, mocking correctness
Architecture	Separation of concerns, dependency direction, API contract changes

Review Workflow

Fetch PR Metadata
       |
       v
Parse Diff (file by file)
       |
       v
Run Analysis Passes
  |    |    |    |
  v    v    v    v
Code  Sec  Perf Tests
  |    |    |    |
  v    v    v    v
Aggregate Findings
       |
       v
Generate Structured Report
       |
       v
Post Comments to GitHub

Configuration

Parameter	Type	Default	Description
pr	string	(required)	PR number or URL to review
severity	string	all	Minimum severity to report: info, warn, critical
post-comments	boolean	true	Automatically post review comments to GitHub
focus	string	all	Focus area: security, performance, tests, or all
max-files	integer	50	Skip review if PR exceeds this many changed files

Best Practices

1. Review small PRs promptly - The longer a PR sits, the more merge conflicts accumulate. Aim to review within the same business day to keep the team velocity high.

2. Distinguish blocking from non-blocking feedback - Mark critical security or correctness issues as blocking while keeping style suggestions as non-blocking so the author knows what must change versus what is optional.

3. Check the test plan first - Before diving into implementation details, verify that the PR includes adequate tests. Missing tests are the single most common source of future regressions.

4. Validate against the ticket requirements - Cross-reference the PR description with the linked issue to ensure all acceptance criteria are met, not just that the code compiles.

Common Issues

1. PR diff is too large to analyze - Break the review into logical chunks by focusing on one directory or module at a time using the focus parameter.

2. Review comments appear on outdated diff lines - Ensure the PR branch is rebased on the latest main before running the review so line numbers align correctly.

3. False positives in security analysis - Some patterns like parameterized queries may appear as raw SQL. Verify flagged items manually before requesting changes. Always cross-reference with the code context to understand whether the pattern is genuinely dangerous or a false alarm from static analysis.

4. Review hangs on very large diffs - PRs with more than 50 changed files may take significant time to analyze. Use the focus parameter to review one module at a time, or ask the PR author to split the change into smaller increments.