Claude Cursor Skill

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.

LLM Mart · 0 points · 13 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download wshobson-agents-plugins_agent-teams_skills_multi-reviewer-patterns-554237f.zip · 3 KB
Part of wshobson/agents — 170 skills

Install

skills CLI npx skills add https://github.com/wshobson/agents/tree/main/plugins/agent-teams/skills/multi-reviewer-patterns
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install wshobson-agents@llmmart
Git 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

  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

## 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.

No comments yet.

Reviews (0)

No reviews yet.

Related