--- name: moa-review description: Multi-perspective code review using the Mixture-of-Agents pattern. Spawns independent perspective agents in parallel, then synthesizes their findings into a unified report with confidence levels. tools: Bash, Read, Grep, Glob, Agent model: sonnet --- # MoA Review Skill Perform a multi-perspective code review where independent agents analyze the same artifact from different angles and a synthesizer combines their findings. ## When to Use - Critical code changes (auth, payments, data pipelines) - Architecture changes before major refactoring - Security-sensitive modifications - Pre-launch review of high-stakes features Do NOT use for routine changes, small fixes, or documentation-only updates. MoA costs 3-5x a single-agent review. ## How to Execute When the user invokes this skill (via `/afx-moa-review` or by asking for a multi-perspective review), follow these steps exactly. ### Step 1: Identify the Artifact Determine what to analyze. The user may provide: - A git diff: `git diff HEAD~1`, `git diff main...feature-branch` - A file path: `src/auth/login.py` - A directory: `src/auth/` If not specified, ask. Then read the artifact content: ```bash # For a diff git diff HEAD~1 # For a file cat src/auth/login.py # For a directory -- get all source files find src/auth/ -type f \( -name "*.py" -o -name "*.ts" -o -name "*.js" -o -name "*.go" -o -name "*.java" -o -name "*.rb" \) | head -20 ``` Count approximate tokens (rough estimate: 1 token per 4 characters). ### Step 2: Estimate Cost and Confirm Calculate and present the estimate: ``` MoA Review Estimate Artifact: [description] (~[N] tokens) Perspectives: [list] ([count] agents) Estimated tokens: [count] perspectives x ~[N] input tokens = ~[total] input [count] perspectives x ~1,500 output tokens = ~[total] output Synthesizer: ~[N] input + ~2,000 output Total: ~[grand total] tokens Proceed? [Y/n/customize] ``` If total exceeds 50,000 tokens, add a warning: ``` WARNING: Estimated usage exceeds 50K tokens. Consider narrowing the scope or reducing perspectives. ``` Let the user confirm, customize perspectives, or cancel. ### Step 3: Select Perspectives Default perspectives for code review: 1. **Security** (opus) -- vulnerabilities, injection, auth, data exposure 2. **Performance** (sonnet) -- complexity, resources, caching, N+1 3. **Quality** (sonnet) -- readability, tests, naming, patterns Additional perspective available on request: 4. **Maintainability** (sonnet) -- coupling, cohesion, extensibility, debt For architecture review, default to all four: Scalability, Resilience, Simplicity, Security. Show the user what is selected and let them adjust: ``` Perspectives for this review: [x] Security (opus) [x] Performance (sonnet) [x] Quality (sonnet) [ ] Maintainability (sonnet) Add/remove? Or press enter for defaults. ``` ### Step 4: Launch Perspective Agents in Parallel Spawn each perspective agent using the Agent tool. Each agent MUST: - Receive ONLY the artifact content and its perspective-specific prompt - NOT see any other perspective's findings - Produce findings in the standardized format **Security Agent Prompt:** ``` You are analyzing the following code from a SECURITY perspective. Focus ONLY on security concerns: - Injection vulnerabilities (SQL, XSS, command injection, path traversal) - Authentication and authorization gaps - Data exposure risks (secrets, PII, tokens in logs) - Cryptographic misuse - OWASP Top 10 categories - Input validation and sanitization - Session management Do NOT comment on code style, performance, or maintainability. Artifact to analyze: --- [artifact content] --- Produce findings in this exact format: === FINDINGS: Security === ### Critical - [finding with file:line reference and CWE ID if applicable] ### Important - [finding with file:line reference] ### Minor - [finding] ### Positive - [security practices done well] === END FINDINGS === ``` **Performance Agent Prompt:** ``` You are analyzing the following code from a PERFORMANCE perspective. Focus ONLY on performance concerns: - Algorithmic complexity (Big-O analysis where relevant) - Resource usage (memory, CPU, file handles, connections) - Caching opportunities and cache invalidation - N+1 query patterns - Unnecessary allocations or copies - Blocking operations in async contexts - Database query efficiency - Network call optimization Do NOT comment on security, code style, or maintainability. Artifact to analyze: --- [artifact content] --- Produce findings in this exact format: === FINDINGS: Performance === ### Critical - [finding with file:line reference and estimated impact] ### Important - [finding with file:line reference] ### Minor - [finding] ### Positive - [performance practices done well] === END FINDINGS === ``` **Quality Agent Prompt:** ``` You are analyzing the following code from a CODE QUALITY perspective. Focus ONLY on quality concerns: - Readability and clarity - Naming conventions (variables, functions, classes) - Design pattern usage and misuse - Test coverage and test quality - Code duplication - Function/method length and complexity - Error handling completeness - Documentation (comments, docstrings) Do NOT comment on security, performance, or architecture. Artifact to analyze: --- [artifact content] --- Produce findings in this exact format: === FINDINGS: Quality === ### Critical - [finding with file:line reference] ### Important - [finding with file:line reference] ### Minor - [finding] ### Positive - [quality practices done well] === END FINDINGS === ``` **Maintainability Agent Prompt (if selected):** ``` You are analyzing the following code from a MAINTAINABILITY perspective. Focus ONLY on maintainability concerns: - Coupling between modules (tight vs. loose) - Cohesion within modules - Extensibility for likely future changes - Technical debt introduction - API surface area (too broad? too narrow?) - Backward compatibility - Configuration vs. hardcoding - Dependency management Do NOT comment on security, performance, or code style. Artifact to analyze: --- [artifact content] --- Produce findings in this exact format: === FINDINGS: Maintainability === ### Critical - [finding with file:line reference] ### Important - [finding with file:line reference] ### Minor - [finding] ### Positive - [maintainability practices done well] === END FINDINGS === ``` Launch all selected agents in parallel. Show progress: ``` Launching perspective agents... [1/3] Security (opus) -- running [2/3] Performance (sonnet) -- running [3/3] Quality (sonnet) -- running ``` Update as each completes: ``` [1/3] Security (opus) -- complete (4 findings) [2/3] Performance (sonnet) -- complete (3 findings) [3/3] Quality (sonnet) -- complete (5 findings) All perspectives complete. ``` ### Step 5: Run the Synthesizer Once all perspectives have reported, concatenate their findings and pass them to the synthesizer. The synthesizer MUST NOT add its own findings -- it only organizes and correlates. **Synthesizer Prompt:** ``` You are a synthesis agent. You have received findings from multiple independent perspective agents who analyzed the same code artifact. Your job is to combine their findings into a single unified report. Rules: 1. AGREEMENTS: When 2+ perspectives flag the same issue, merge into one item. Note which perspectives agreed. Use the highest severity among them. 2. CONFLICTS: When perspectives disagree, flag for human judgment. Present both sides without picking a winner. 3. UNIQUE INSIGHTS: When only one perspective caught something, include it with source attribution (e.g., "[Security]"). 4. Do NOT add your own findings. Only synthesize what was provided. 5. Do NOT remove or downgrade any findings. Severity based on consensus: - CRITICAL: All commenting perspectives agree it is severe - HIGH: Majority agree (2+ of 3, or 3+ of 4) - MEDIUM: Minority flagged (1 of 3, or 2 of 4) - LOW: Single perspective, flagged as minor Perspective findings: --- [all perspective findings] --- Produce the report in this exact format: # MoA Review Report **Artifact**: [artifact name] **Perspectives**: [list] **Date**: [today] ## Critical Findings [Items where all commenting perspectives agree on severity. Each item: severity, description, file:line, which perspectives, recommendation] ## High-Confidence Findings [Items where majority of perspectives agree. Each item: severity, description, file:line, which perspectives, recommendation] ## Conflicts (Human Judgment Required) [Items where perspectives disagree. Present both sides.] ## Additional Insights [Unique findings from individual perspectives, with [Source] attribution] ## Positive Observations [Things done well, noted by any perspective] ## Summary - Total findings: [count] - Critical: [count] - High: [count] - Conflicts requiring judgment: [count] - Unique insights: [count] ``` ### Step 6: Present the Report Display the synthesized report to the user. After the report, provide next steps: ``` Next steps: 1. Address CRITICAL findings immediately 2. Address HIGH findings before merge 3. Review CONFLICTS and make judgment calls 4. Consider ADDITIONAL INSIGHTS based on priority ``` ## Architecture Review Mode When the user requests an architecture review (or analyzes a directory/system rather than a diff), use architecture perspectives instead: **Scalability Agent**: "Can this handle 10x load? Look for bottlenecks, single points of contention, data growth concerns, connection pooling, horizontal scaling barriers." **Resilience Agent**: "What happens when components fail? Look for missing circuit breakers, retry storms, cascading failures, data consistency during failures, timeout configurations." **Simplicity Agent**: "Is this more complex than necessary? Look for over-abstraction, unnecessary indirection, features that could be deferred, cognitive load on new developers." **Security Agent**: "What is the attack surface? Look for trust boundaries, unauthenticated endpoints, data flow between components, encryption gaps, dependency vulnerabilities." ## Important Rules 1. **Independence**: Perspective agents MUST NOT see each other's findings 2. **No self-findings**: The synthesizer MUST NOT add its own analysis 3. **Severity respect**: Never downgrade a finding during synthesis 4. **Cost transparency**: Always show cost estimate before running 5. **User control**: Always let the user select or adjust perspectives 6. **Scope awareness**: Warn if the artifact seems too small for MoA or too large for budget