multi-review

Multi-Agent Code Review

Usage:

• /multi-review - auto-detect appropriate depth
• /multi-review 5 - explicit count
• /multi-review deep - depth-based scaling (quick | balanced | deep)

quick: 1-2 agents focused on correctness. Minimal overhead for simple changes.

balanced (default): 2-3 agents covering primary domains the code touches.

deep: 5+ agents for comprehensive coverage:

• architecture-auditor (always)
• security-reviewer (always)
• logic-reviewer (always)
• performance-reviewer
• error-handling-reviewer
• Domain-specific reviewers based on code

Auto-detect depth from context: single-file change with clear purpose → quick; multi-file implementation → balanced; architectural changes, new patterns, security- sensitive code → deep.

When called from /autotask, respect the complexity level already determined.

When agents surface valid issues, fix them. Don't carry technical debt forward with "we'll address this later." The only valid reasons to not fix something:

1. Wontfix: The suggestion doesn't apply given full context
2. Complexity trade-off: The fix adds more complexity than the risk it mitigates
3. Large scope: Fixing would require substantial architectural changes outside this PR

Reference plugins/core/code-review-standards.md for detailed guidance on false positives (single-use values, theoretical race conditions, redundant type safety, premature optimization) and complexity trade-offs. If the project has custom standards in .cursor/rules/code-review-standards.mdc, reference those as well.

For large scope: Create a follow-up issue/task, but be honest—if it should have been done differently from the start, that's feedback for next time, not permission to merge broken code.

Categorize by focus area: correctness, security, performance, architecture, quality, UX, observability. Select N agents ensuring diversity—don't pick multiple agents from the same domain.

When the code has characteristics that no discovered agent covers well, create a dynamic agent using general-purpose with a focused prompt.

After agents complete, apply the fix-first synthesis workflow:

1. Collect: Gather all findings, deduplicate across agents, group by severity, note which agent caught each issue

2. Classify each finding as AUTO-FIX, ASK, or DEFER:

   AUTO-FIX — Apply immediately without asking. High confidence, unambiguous, low risk of changing behavior in unexpected ways. In test files, only apply AUTO-FIX for import/formatting issues — route logic changes to ASK:

   • Unused imports, dead code flagged by multiple agents
   • Missing await where the return value is used or error must be caught (not fire-and-forget patterns — those require judgment and belong in ASK)
   • Obvious null/undefined checks where crash is certain
   • Wrong casing or naming convention violations
   • Missing error propagation (empty catch blocks, swallowed errors)
   • Import ordering, formatting issues
   • Straightforward type fixes (wrong type annotation, missing return type)