Multi Reviewer Patterns
Run parallel agent-driven code review with dimension-specific checklists (security, performance, and more) so findings are structured instead of one vague pass.
Overview
multi-reviewer-patterns is an agent skill most often used in Ship (also Build backend hardening) that provides dimension checklists for parallel structured code review.
Install
npx skills add https://github.com/wshobson/agents --skill multi-reviewer-patternsWhat is this skill?
- Security dimension checklist: input validation, parameterized SQL, XSS escaping, path traversal, authN/authZ, JWT valida
- Performance dimension checklist: N+1 queries, indexes, pagination, connection pooling, memory and resource patterns (tru
- Designed for parallel reviewers—each dimension follows the same checklist structure
- Concrete pass/fail style bullets agents can cite in review comments
- Extensible pattern for additional review dimensions beyond security and performance
- 2 detailed review dimensions documented (Security, Performance) with multi-item checklists each
Adoption & trust: 5.9k installs on skills.sh; 36.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent or team does ad-hoc review and repeatedly misses security or performance classes because no one owns a explicit dimension checklist.
Who is it for?
Solo builders shipping backend or full-stack changes who want security and performance lenses on every meaningful PR.
Skip if: Greenfield spikes with no code to review yet, or teams that already run dedicated SAST/DAST pipelines and only need ticket triage automation.
When should I use this skill?
When running parallel or multi-pass code review that should follow fixed dimension checklists.
What do I get? / Deliverables
Review output is organized by dimension with checklist-backed findings you can turn into tickets or blockers before merge.
- Dimension-scoped review notes aligned to checklists
- Structured security and performance finding lists for follow-up
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Ship/review is the canonical shelf because the skill encodes pre-merge review rituals, though the same dimensions matter while hardening features in Build. Review subphase matches explicit checklist-driven scrutiny before release, aligned with multi-reviewer parallel workflows.
Where it fits
Split a large PR into security and performance reviewer passes before tagging a release.
Self-review a new API layer against SQL injection and N+1 criteria before opening the PR.
Review a production hotfix with the security checklist emphasizing secrets and auth regressions.
How it compares
Checker playbooks for parallel human/agent review—not a replacement for dependency scanners or load-testing tools.
Common Questions / FAQ
Who is multi-reviewer-patterns for?
Indie developers and lean teams using AI agents for code review who need consistent security and performance criteria per review pass.
When should I use multi-reviewer-patterns?
Before merge in Ship/review, after major Build/backend changes, or when validating a hotfix under Operate/iterate—whenever structured multi-dimension review beats a single generic pass.
Is multi-reviewer-patterns safe to install?
It is checklist documentation; review the Security Audits panel on this Prism page and never grant agents merge rights solely based on checklist completion.
SKILL.md
READMESKILL.md - Multi Reviewer Patterns
# 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