multi-reviewer-patterns
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.
Install
npx skills add https://github.com/wshobson/agents/tree/main/plugins/agent-teams/skills/multi-reviewer-patterns
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install wshobson-agents@llmmart
git clone https://github.com/wshobson/agents.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole wshobson/agents collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
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
| Dimension | Focus | When to Include |
|---|---|---|
| Security | Vulnerabilities, auth, input validation | Always for code handling user input or auth |
| Performance | Query efficiency, memory, caching | When changing data access or hot paths |
| Architecture | SOLID, coupling, patterns | For structural changes or new modules |
| Testing | Coverage, quality, edge cases | When adding new functionality |
| Accessibility | WCAG, ARIA, keyboard nav | For UI/frontend changes |
Recommended Combinations
| Scenario | Dimensions |
|---|---|
| API endpoint changes | Security, Performance, Architecture |
| Frontend component | Architecture, Testing, Accessibility |
| Database migration | Performance, Architecture |
| Authentication changes | Security, Testing |
| Full feature review | Security, Performance, Architecture, Testing |
Finding Deduplication
When multiple reviewers report issues at the same location:
Merge Rules
- Same file:line, same issue — Merge into one finding, credit all reviewers
- Same file:line, different issues — Keep as separate findings
- Same issue, different locations — Keep separate but cross-reference
- Conflicting severity — Use the higher severity rating
- 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
| Severity | Impact | Likelihood | Examples |
|---|---|---|---|
| Critical | Data loss, security breach, complete failure | Certain or very likely | SQL injection, auth bypass, data corruption |
| High | Significant functionality impact, degradation | Likely | Memory leak, missing validation, broken flow |
| Medium | Partial impact, workaround exists | Possible | N+1 query, missing edge case, unclear error |
| Low | Minimal impact, cosmetic | Unlikely | Style 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 (agents)
-
references
-
review-dimensions.md 4 KB
# 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
-
-
SKILL.md 5.1 KB
--- name: multi-reviewer-patterns description: 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. version: 1.0.2 --- # 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 | Dimension | Focus | When to Include | | ----------------- | --------------------------------------- | ------------------------------------------- | | **Security** | Vulnerabilities, auth, input validation | Always for code handling user input or auth | | **Performance** | Query efficiency, memory, caching | When changing data access or hot paths | | **Architecture** | SOLID, coupling, patterns | For structural changes or new modules | | **Testing** | Coverage, quality, edge cases | When adding new functionality | | **Accessibility** | WCAG, ARIA, keyboard nav | For UI/frontend changes | ### Recommended Combinations | Scenario | Dimensions | | ---------------------- | -------------------------------------------- | | API endpoint changes | Security, Performance, Architecture | | Frontend component | Architecture, Testing, Accessibility | | Database migration | Performance, Architecture | | Authentication changes | Security, Testing | | Full feature review | Security, 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 | Severity | Impact | Likelihood | Examples | | ------------ | --------------------------------------------- | ---------------------- | -------------------------------------------- | | **Critical** | Data loss, security breach, complete failure | Certain or very likely | SQL injection, auth bypass, data corruption | | **High** | Significant functionality impact, degradation | Likely | Memory leak, missing validation, broken flow | | **Medium** | Partial impact, workaround exists | Possible | N+1 query, missing edge case, unclear error | | **Low** | Minimal impact, cosmetic | Unlikely | Style 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 ```markdown ## 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} ```
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.