Multi Review

Workflow

Step 1: Identify Target

Determine what to review:

1. If task_id provided: read ~/.nexus/workspace/active/{task_id}/PROGRESS.md for output files
2. If file path provided: use directly
3. If no args: find latest modified workspace in ~/.nexus/workspace/active/
4. Fallback: git diff HEAD~1 --name-only for recent changes

List all target files with line counts.

Step 2: Spawn Reviewers

Launch 3-5 parallel review agents using the Agent tool. Each reviewer operates independently.

Core reviewers (always, --light or default):

Extended reviewers (--full only):

Each reviewer agent receives:

• The target file contents
• The DISPATCH.md (what was requested) -- if available
• The PROGRESS.md (what was claimed done) -- if available
• Instruction: "Produce findings as: ID, SEVERITY (CRITICAL/HIGH/MEDIUM/LOW), SUMMARY, FIX. Return PASS or FAIL verdict."

Standalone mode (no DISPATCH.md/PROGRESS.md): When context files are absent, reviewers operate in file-only mode. Skip acceptance-criteria validation (correctness-reviewer checks internal logic only). Security and integration reviewers function normally.

Timeout: Each reviewer agent has a 120-second soft limit. If a reviewer has not returned after 120s, mark it SKIPPED and proceed with available verdicts. Use the Agent tool's natural completion; do not add artificial waits.

Step 3: Collect Verdicts

Wait for all reviewers to complete. Build verdict table:

| Reviewer | Verdict | Findings |
|----------|---------|----------|
| security | PASS | 0 |
| correctness | PASS | 1 (LOW) |
| integration | FAIL | 1 (HIGH) |

Step 4: Gate Decision

PASS conditions (ALL must be true):

• Majority of reviewers return PASS (2/3 or 3/5)
• Zero CRITICAL findings from ANY reviewer
• Zero HIGH findings from security-reviewer specifically

FAIL conditions (ANY triggers FAIL):

• Any CRITICAL finding from any reviewer
• Majority FAIL (2/3 or 3/5 return FAIL)
• Any HIGH from security-reviewer

CONDITIONAL:

• Majority PASS but HIGH findings exist (non-security)

Step 5: Report

Output the review summary:

## Multi-Review: {task_id or file}

| Reviewer | Verdict | Findings |
|----------|---------|----------|
| ... | ... | ... |

### Gate: PASS / CONDITIONAL / FAIL

### Findings (if any)
{numbered list of all findings across all reviewers, sorted by severity}

### Recommendation
{MERGE / FIX-THEN-MERGE / BLOCK}

Step 6: Post-Review Actions

• PASS/MERGE: No action needed. TECH proceeds with delivery.
• CONDITIONAL/FIX-THEN-MERGE: List specific fixes. TECH applies fixes, then re-runs /multi-review --light.
• FAIL/BLOCK: Escalate to GENIE with full findings. Do not merge.

Save review results to ~/.nexus/workspace/active/{task_id}/REVIEW.md if task_id exists.

Integration with TECH Pipeline

This skill augments the existing verify-after-write chain:

1. IL-11: grep-verify edits (TECH runs)
2. IL-12: runtime test (TECH runs)
3. IL-13: test all consumers (TECH runs)
4. IL-14 (NEW): /multi-review parallel peer review (this skill)

TECH should invoke /multi-review after IL-13 passes. If multi-review returns FAIL, TECH does NOT mark the delivery as complete.

Error Handling

• If a reviewer agent fails/times out: mark that reviewer as SKIPPED, continue with remaining
• If 2+ reviewers SKIPPED: flag [PARTIAL-REVIEW], gate decision based on available verdicts only
• If ALL reviewers fail: report error, do not gate (let TECH decide)
• If target files don't exist or workspace is empty: report [NO-TARGET] error, exit without gating
• If DISPATCH.md/PROGRESS.md missing: switch to standalone mode (review files directly, skip acceptance-criteria validation)
• If git diff fallback also yields nothing: ask user for explicit file path via AskUserQuestion

Cortex Persistence

After every completed review (PASS, CONDITIONAL, or FAIL), store a summary to Cortex:

cortex_store(collection="technical", text="Multi-Review {task_id}: {GATE_VERDICT}. {count} findings ({severity_breakdown}). Reviewers: {reviewer_verdicts}.", metadata={type: "review", task_id: "{task_id}", verdict: "{verdict}", findings_count: N})

This enables cross-session trend analysis (e.g., "which components fail security review most often").