Code Review

Perform a structured code review that checks for security vulnerabilities, performance issues, correctness bugs, and maintainability concerns. Produce actionable feedback organized by severity.

Workflow

Step 1: Gather the Diff

Determine what code to review based on user input:

• PR URL: Use gh pr diff <number> to fetch the diff.
• File path: Use git diff HEAD -- <path> or read the file directly.
• "staged": Use git diff --cached to review staged changes.
• No input: Use git diff for unstaged changes, or git diff HEAD~1 for the last commit.

Also gather context:

• Read surrounding code in modified files to understand usage patterns.
• Check for related tests that cover the changed code.
• Look at the project's linting config (.eslintrc, .flake8, pyproject.toml) for style expectations.

Step 2: Analyze for Issues

Review the diff systematically across these categories:

Security (Critical)

• SQL injection, XSS, command injection, path traversal
• Hardcoded secrets, API keys, credentials
• Missing authentication or authorization checks
• Insecure deserialization, unsafe eval usage
• SSRF, open redirect, CSRF vulnerabilities
• Missing input validation or sanitization

Correctness (High)

• Off-by-one errors, boundary conditions
• Null/undefined dereference risks
• Race conditions, deadlocks in concurrent code
• Missing error handling, swallowed exceptions
• Incorrect type conversions or comparisons
• Logic errors in conditionals, loops, recursion

Performance (Medium)

• N+1 query patterns in database access
• Missing database indexes for new queries
• Unbounded collection growth, memory leaks
• Unnecessary computation inside loops
• Missing pagination for large result sets
• Blocking I/O in async contexts

Maintainability (Low)

• Functions exceeding 50 lines or high cyclomatic complexity
• Duplicated code that should be extracted
• Poor naming that obscures intent
• Missing or misleading comments
• Dead code, unused imports, unreachable branches

Step 3: Check Test Coverage

• Verify that new code paths have corresponding tests.
• Check that edge cases (empty input, null, boundary values) are tested.
• Look for tests of error/failure paths, not just happy paths.
• Flag any mocking that hides real integration issues.

Step 4: Produce the Review

Organize findings by severity and provide actionable feedback.

Output Format

## Code Review Summary

**Files reviewed**: <count>
**Overall assessment**: APPROVE / REQUEST CHANGES / COMMENT

### Critical Issues (must fix before merge)

#### [C1] <Title> — <file>:<line>
**Category**: Security | Correctness
**Issue**: <what is wrong and why it matters>
**Suggestion**:
```<language>
// suggested fix

Warnings (should fix)

[W1] <Title> — <file>:<line>

Category: Performance | Correctness Issue: <description> Suggestion: <how to fix>

Suggestions (nice to have)

[S1] <Title> — <file>:<line>

Category: Maintainability | Style Note: <description>

Positive Highlights

• <something done well worth calling out>

Test Coverage

• New code paths are tested
• Edge cases are covered
• Error paths are tested

## Examples

**User**: "Review my staged changes"
**Action**: Run `git diff --cached`, analyze the diff, produce a categorized review.

**User**: "Review PR #42 with a focus on security"
**Action**: Run `gh pr diff 42`, focus analysis on security concerns, still note other critical issues.

**User**: "Is this code safe?" (with a file path)
**Action**: Read the file, analyze for security vulnerabilities, report findings.

## Best Practices

- Always explain WHY something is an issue, not just that it is one.
- Provide concrete fix suggestions with code snippets, not vague advice.
- Acknowledge good patterns — reviews that only contain criticism are demoralizing.
- Distinguish between blocking issues and stylistic preferences.
- If the diff is large (>500 lines), summarize the scope first and ask if the user wants a full review or wants to focus on specific files.
- Consider the project's existing patterns before flagging style issues — consistency with the codebase matters more than personal preference.
- When in doubt about intent, ask a clarifying question rather than assuming a bug.