mirror of
https://github.com/wshobson/agents.git
synced 2026-03-18 17:47:16 +00:00
feat(agent-teams): add plugin for multi-agent team orchestration
New plugin with 7 presets (review, debug, feature, fullstack, research, security, migration), 4 specialized agents, 7 slash commands, 6 skills with reference docs, and Context7 MCP integration for research teams.
This commit is contained in:
Seth Hobson
126
plugins/agent-teams/skills/multi-reviewer-patterns/SKILL.md
Normal file
126
plugins/agent-teams/skills/multi-reviewer-patterns/SKILL.md
Normal file
@@ -0,0 +1,126 @@
|
||||
---
|
||||
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.
|
||||
---
|
||||
|
||||
# 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}
|
||||
```
|
||||
@@ -0,0 +1,127 @@
|
||||
# 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
|
||||
Reference in New Issue
Block a user