Multi Reviewer Patterns

Multi-Reviewer Patterns

Patterns for coordinating parallel code reviews across multiple quality dimensions, deduplicating findings, calibrating severity, and producing consolidated reports.

When to Use This Skill

• Organizing a multi-dimensional code review
• Deciding which review dimensions to assign
• Deduplicating findings from multiple reviewers
• Calibrating severity ratings consistently
• Producing a consolidated review report

Review Dimension Allocation

Available Dimensions

Recommended Combinations

Finding Deduplication

When multiple reviewers report issues at the same location:

Merge Rules

1. Same file:line, same issue — Merge into one finding, credit all reviewers 2. Same file:line, different issues — Keep as separate findings 3. Same issue, different locations — Keep separate but cross-reference 4. Conflicting severity — Use the higher severity rating 5. Conflicting recommendations — Include both with reviewer attribution

Deduplication Process

For each finding in all reviewer reports:
  1. Check if another finding references the same file:line
  2. If yes, check if they describe the same issue
  3. If same issue: merge, keeping the more detailed description
  4. If different issue: keep both, tag as "co-located"
  5. Use highest severity among merged findings

Severity Calibration

Severity Criteria

Calibration Rules

• Security vulnerabilities exploitable by external users: always Critical or High
• Performance issues in hot paths: at least Medium
• Missing tests for critical paths: at least Medium
• Accessibility violations for core functionality: at least Medium
• Code style issues with no functional impact: Low

Consolidated Report Template

## Code Review Report

**Target**: {files/PR/directory}
**Reviewers**: {dimension-1}, {dimension-2}, {dimension-3}
**Date**: {date}
**Files Reviewed**: {count}

### Critical Findings ({count})

#### [CR-001] {Title}

**Location**: `{file}:{line}`
**Dimension**: {Security/Performance/etc.}
**Description**: {what was found}
**Impact**: {what could happen}
**Fix**: {recommended remediation}

### High Findings ({count})

...

### Medium Findings ({count})

...

### Low Findings ({count})

...

### Summary

| Dimension    | Critical | High  | Medium | Low   | Total  |
| ------------ | -------- | ----- | ------ | ----- | ------ |
| Security     | 1        | 2     | 3      | 0     | 6      |
| Performance  | 0        | 1     | 4      | 2     | 7      |
| Architecture | 0        | 0     | 2      | 3     | 5      |
| **Total**    | **1**    | **3** | **9**  | **5** | **18** |

### Recommendation

{Overall assessment and prioritized action items}

Review Dimension Checklists

Detailed checklists for each review dimension that reviewers follow during parallel code review.

Security Review Checklist

Input Handling

• [ ] All user inputs are validated and sanitized
• [ ] SQL queries use parameterized statements (no string concatenation)
• [ ] HTML output is properly escaped to prevent XSS
• [ ] File paths are validated to prevent path traversal
• [ ] Request size limits are enforced

Authentication & Authorization

• [ ] Authentication is required for all protected endpoints
• [ ] Authorization checks verify user has permission for the action
• [ ] JWT tokens are validated (signature, expiry, issuer)
• [ ] Password hashing uses bcrypt/argon2 (not MD5/SHA)
• [ ] Session management follows best practices

Secrets & Configuration

• [ ] No hardcoded secrets, API keys, or passwords
• [ ] Secrets are loaded from environment variables or secret manager
• [ ] .gitignore includes sensitive file patterns
• [ ] Debug/development endpoints are disabled in production

Dependencies

• [ ] No known CVEs in direct dependencies
• [ ] Dependencies are pinned to specific versions
• [ ] No unnecessary dependencies that increase attack surface

Performance Review Checklist

Database

• [ ] No N+1 query patterns
• [ ] Queries use appropriate indexes
• [ ] No SELECT \* on large tables
• [ ] Pagination is implemented for list endpoints
• [ ] Connection pooling is configured

Memory & Resources

• [ ] No memory leaks (event listeners cleaned up, streams closed)
• [ ] Large data sets are streamed, not loaded entirely into memory
• [ ] File handles and connections are properly closed
• [ ] Caching is used for expensive operations

Computation

• [ ] No unnecessary re-computation or redundant operations
• [ ] Appropriate algorithm complexity for the data size
• [ ] Async operations used where I/O bound
• [ ] No blocking operations on the main thread

Architecture Review Checklist

Design Principles

• [ ] Single Responsibility: each module/class has one reason to change
• [ ] Open/Closed: extensible without modification
• [ ] Dependency Inversion: depends on abstractions, not concretions
• [ ] No circular dependencies between modules

Structure

• [ ] Clear separation of concerns (UI, business logic, data)
• [ ] Consistent error handling strategy across the codebase
• [ ] Configuration is externalized, not hardcoded
• [ ] API contracts are well-defined and versioned

Patterns

• [ ] Consistent patterns used throughout (no pattern mixing)
• [ ] Abstractions are at the right level (not over/under-engineered)
• [ ] Module boundaries align with domain boundaries
• [ ] Shared utilities are actually shared (no duplication)

Testing Review Checklist

Coverage

• [ ] Critical paths have test coverage
• [ ] Edge cases are tested (empty input, null, boundary values)
• [ ] Error paths are tested (what happens when things fail)
• [ ] Integration points have integration tests

Quality

• [ ] Tests are deterministic (no flaky tests)
• [ ] Tests are isolated (no shared state between tests)
• [ ] Assertions are specific (not just "no error thrown")
• [ ] Test names clearly describe what is being tested

Maintainability

• [ ] Tests don't duplicate implementation logic
• [ ] Mocks/stubs are minimal and accurate
• [ ] Test data is clear and relevant
• [ ] Tests are easy to understand without reading the implementation

Accessibility Review Checklist

Structure

• [ ] Semantic HTML elements used (nav, main, article, button)
• [ ] Heading hierarchy is logical (h1 → h2 → h3)
• [ ] ARIA roles and properties used correctly
• [ ] Landmarks identify page regions

Interaction

• [ ] All functionality accessible via keyboard
• [ ] Focus order is logical and visible
• [ ] No keyboard traps
• [ ] Touch targets are at least 44x44px

Content

• [ ] Images have meaningful alt text
• [ ] Color is not the only means of conveying information
• [ ] Text has sufficient contrast ratio (4.5:1 for normal, 3:1 for large)
• [ ] Content is readable at 200% zoom