AutoGineer
Generated banner for Multi Reviewer Patterns
Generated logo for Multi Reviewer Patterns

Multi Reviewer Patterns

Seth HobsonCommunityCreated by Seth Hobson

  • Skill
  • Guidelines
  • Software development
  • MIT
  • No issues found
Download ZIP

From the author

Coordinate parallel code reviews across multiple quality dimensions with finding deduplication, severity calibration, and consolidated reporting. Use this skill when organizing multi-reviewer code reviews, calibrating finding severity, or consolidating review results.
— the description by Seth Hobson

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Multi-Reviewer Patterns provides a systematic approach to managing complex code reviews where multiple reviewers assess different quality dimensions simultaneously. It offers a standardized process for allocating review focus, deduplicating findings across reports, calibrating severity levels, and generating a consolidated final report. By using predefined dimensions—such as Security, Performance, Architecture, Testing, and Accessibility—teams can ensure comprehensive coverage while maintaining consistency in how issues are identified, ranked, and communicated.

What it does

  • Defines specific review dimensions and their appropriate use cases.
  • Provides rules for merging and deduplicating findings from multiple reviewers.
  • Establishes a severity calibration framework to ensure consistent impact assessment.
  • Offers a structured template for creating consolidated code review reports.
  • Includes detailed checklists for security, performance, architecture, testing, and accessibility.

When to use it

  • When conducting complex code reviews that require multiple areas of expertise.
  • When you need to reconcile conflicting feedback from different reviewers.
  • When you need to standardize severity ratings across a team.
  • When preparing a final, consolidated report for a large pull request or structural change.

Advantages

  • Reduces noise by deduplicating findings from multiple sources.
  • Ensures consistent severity assessment across different reviewers.
  • Provides clear, actionable guidance for various quality dimensions.
  • Facilitates professional and organized communication of review results.

Usage examples

“I have three reviewers looking at an API change. How should I combine their findings?”
The skill provides a deduplication process to merge findings by file and line, resolve conflicting severities by taking the higher rating, and include all reviewer attributions.
“How do I decide which review dimensions to apply to a database migration?”
The skill recommends focusing on Performance and Architecture dimensions for database migrations, providing specific checklists for each.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/wshobson/multi-reviewer-patterns/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip multi-reviewer-patterns.zip -d .agents/skills

Documentation by Seth Hobson

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
DimensionFocusWhen to Include
SecurityVulnerabilities, auth, input validationAlways for code handling user input or auth
PerformanceQuery efficiency, memory, cachingWhen changing data access or hot paths
ArchitectureSOLID, coupling, patternsFor structural changes or new modules
TestingCoverage, quality, edge casesWhen adding new functionality
AccessibilityWCAG, ARIA, keyboard navFor UI/frontend changes
Recommended Combinations
ScenarioDimensions
API endpoint changesSecurity, Performance, Architecture
Frontend componentArchitecture, Testing, Accessibility
Database migrationPerformance, Architecture
Authentication changesSecurity, Testing
Full feature reviewSecurity, Performance, Architecture, Testing

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
SeverityImpactLikelihoodExamples
CriticalData loss, security breach, complete failureCertain or very likelySQL injection, auth bypass, data corruption
HighSignificant functionality impact, degradationLikelyMemory leak, missing validation, broken flow
MediumPartial impact, workaround existsPossibleN+1 query, missing edge case, unclear error
LowMinimal impact, cosmeticUnlikelyStyle issue, minor optimization, naming
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}

Files

references/review-dimensions.md

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

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Seth Hobson
Publisher
Seth Hobson (Community)
Source
wshobson/agents · plugins/agent-teams/skills/multi-reviewer-patterns · commit 4bde316
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Seth Hobson.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download multi-reviewer-patterns.zip