Code Review Workflow Framework

Structured code review methodology covering review checklists, PR standards, automated checks, review prioritization, and feedback delivery patterns for maintaining high code quality at scale.

When to Use This Skill

Choose Code Review Workflow when:

• Establishing code review standards for a team or organization
• Improving review speed without sacrificing quality
• Creating reviewer assignment and rotation systems
• Integrating automated checks to reduce manual review burden
• Training new team members on effective review practices

Consider alternatives when:

• Need automated code analysis — use SAST/linting tools
• Need architecture review — use design review processes
• Need pair programming instead — use real-time collaboration

Quick Start

Copy
# Activate code review framework
claude skill activate expert-code-review-workflow-framework

# Set up review process
claude "Set up a code review workflow for our 8-person team"

Example: PR Template with Review Checklist

Copy
## Description
[Concise description of what this PR does and why]

## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Refactoring
- [ ] Documentation
- [ ] Performance improvement

## Testing
- [ ] Unit tests added/updated
- [ ] Integration tests pass
- [ ] Manual testing completed
- [ ] Edge cases considered

## Review Checklist (for reviewer)
### Correctness
- [ ] Logic is correct and handles edge cases
- [ ] Error handling is appropriate
- [ ] No race conditions or concurrency issues

### Security
- [ ] No hardcoded secrets or credentials
- [ ] Input validation present for user data
- [ ] SQL/command injection prevented

### Performance
- [ ] No N+1 queries or unnecessary database calls
- [ ] No memory leaks or unbounded growth
- [ ] Caching considered where appropriate

### Maintainability
- [ ] Code is readable without excessive comments
- [ ] Functions have single responsibility
- [ ] No unnecessary duplication

## Screenshots (if UI change)
[Before/After screenshots]

Core Concepts

Review Prioritization

PR Category	Review SLA	Reviewer Count
Hotfix / Security	1 hour	1 (senior)
Bug fix	4 hours	1
Feature (small)	8 hours	1
Feature (large)	24 hours	2
Refactoring	24 hours	2
Documentation	48 hours	1

Automated Checks (Before Human Review)

Check	Tool	Blocks PR
Tests pass	CI (GitHub Actions)	Yes
Lint / Format	ESLint, Prettier, Ruff	Yes
Type check	TypeScript, mypy	Yes
Security scan	Snyk, CodeQL	Yes (critical only)
Bundle size	bundlesize, size-limit	No (warning)
Coverage	Codecov	No (comment)

Copy
# CODEOWNERS for automatic reviewer assignment
# .github/CODEOWNERS
*.ts @frontend-team
*.tsx @frontend-team
/backend/ @backend-team
/infrastructure/ @devops-team
*.sql @backend-team @dba-team
/security/ @security-team

Configuration

Parameter	Description	Default
required_approvals	Number of approvals needed	1
auto_assign	Use CODEOWNERS for assignment	true
max_pr_size	Maximum lines changed (soft limit)	400
review_sla	Default review time target	24h
stale_pr_days	Days before PR is marked stale	7
required_checks	CI checks that must pass	["tests", "lint", "typecheck"]

Best Practices

1. Keep PRs small — under 400 lines of changes — Review quality degrades sharply above 400 lines. Large PRs get rubber-stamped because reviewers can't maintain attention. Split features into logical, independently-reviewable chunks.

2. Automate everything automatable before human review — Every manual check that can be automated should be. Linting, formatting, type checking, test execution, and security scanning should run in CI so human reviewers focus on logic, design, and edge cases.

3. Review the PR description and tests first, code second — Understanding what the PR aims to accomplish (description) and how it's verified (tests) provides context for reviewing the implementation. If the tests make sense, the code review confirms the implementation matches.

4. Give feedback on behavior, not the person — Say "This function doesn't handle the null case" not "You forgot to handle null." Frame suggestions as questions when possible: "Have you considered what happens when X is null?" This keeps reviews collaborative.

5. Use CODEOWNERS for automatic, expertise-based reviewer assignment — Manual reviewer assignment creates bottlenecks and uneven workloads. CODEOWNERS routes PRs to people with relevant expertise and distributes review load across the team.

Common Issues

Review bottleneck — PRs wait days for review. Set explicit review SLAs (4h for bugs, 24h for features). Implement a review rotation so everyone reviews daily. Use Slack/Teams bots to notify reviewers of pending PRs. Track and report review times weekly.

Reviews become nitpicky about style rather than substance. Automate style enforcement with formatters and linters. Add a team agreement that style issues caught by automation don't need human comments. Focus human review on correctness, design, and edge cases.

New team members don't know what to look for in reviews. Create a review guide with examples of good feedback and common issues to check. Pair new reviewers with experienced ones for their first 10 reviews. Share anonymized examples of excellent reviews as learning material.