Code Review

/xavier review spawns multiple persona-driven reviewer agents in parallel. Each reviewer examines your diff from a different angle. Findings are aggregated incrementally as reviewers complete — no waiting for the slowest one before you see results.

How it works

1. Vault context load — Xavier reads relevant notes from your vault: team conventions, past review decisions, recurring patterns
2. Diff detection — runs git diff to determine what's being reviewed
3. Spawn reviewers — 3 background agents (remoras) launch in parallel, each with the diff, vault context, and a distinct persona
4. Immediate feedback — you see "Review started, 3 reviewers working..." right away
5. Incremental aggregation — the pilot fish categorizes and deduplicates findings as each reviewer completes
6. Final verdict — approve, request changes, or rethink — with categorized findings
7. Vault write — the review summary is stored in ~/.xavier/knowledge/reviews/

Personas

Personas are markdown files that define a reviewer's perspective. Each contains a system prompt that shapes how the reviewer analyzes code.

Default personas:

Where personas live

• Global: ~/.xavier/personas/ — apply to all repos
• Repo-level: <your-repo>/.xavier/personas/ — override globals for that repo

You customize the panel by adding, editing, or removing persona files. Want a reviewer focused on accessibility? Create a11y.md in your personas directory.

Active learning

Xavier scans the 10 most recent review notes for the current repo before spawning reviewers. Patterns that appeared in 2+ reviews are extracted and injected as a ## Recurring Patterns section in each reviewer's prompt.

This means your reviewers get smarter over time. If Xavier has flagged missing error boundaries in your React components three times, it'll proactively look for that pattern in future reviews.

How it degrades gracefully:

• Fewer than 2 reviews for this repo? The recurring patterns section is omitted entirely
• Max 10 patterns, ~200 words — enough context without polluting the prompt

Multi-model debate

Review can optionally run a second pass that dispatches the review brief to GPT and Gemini in parallel via the multi-model-dispatch dependency skill. Findings are merged with attribution and surfaced alongside the single-persona findings.

Prerequisites

Two requirements are checked at runtime:

• The external agent CLI must be installed and resolvable on PATH.
• The dispatch.sh and parse.sh scripts must be present (installed as part of the multi-model-dispatch dependency skill).

If either is missing, multi-model is a silent no-op — the single-persona review path runs unchanged. Nothing fails.

Attribution

Model labels pass through as GPT and Gemini (not generic A/B identifiers). Every finding from the multi-model pass is attributed so you can trace a concern back to the source model.

Debate output contract

The multi-model-dispatch skill parses per-model outputs into a structured format. For v1, the Description and Scenario fields are optional — parsers tolerate minimal outputs. A vault-contradicted dispute format is available in the structured brief template when one model's finding is contradicted by vault context (recurring patterns from prior reviews).

When to use it

Multi-model debate is useful when you want cross-model validation on a high-stakes change. The tradeoff is extra latency and API cost. If you don't have the agent CLI and scripts, review works fine without it.

Review notes

Every review is stored as a Zettelkasten note with structured frontmatter:

---
repo: my-app
module: src/auth
type: review
finding-categories: [security, correctness]
recurring: true
tags: [auth, token-handling]
related: [knowledge/repos/my-app-architecture]
created: 2026-04-08
updated: 2026-04-08
---

These notes serve dual purpose:

• Lookup — "what did we flag last time on this module?"
• Active learning — recurring patterns are extracted and fed to future reviewers

Example walkthrough

You're working on an authentication service and have changes ready to review:

# You've made changes to the auth middleware
git diff --stat
# src/middleware/auth.ts | 45 ++++++++--
# src/utils/token.ts    | 12 ++-
# 2 files changed, 42 insertions(+), 15 deletions(-)

Run /xavier review:

Review started, 3 reviewers working...

✓ Correctness reviewer complete (1/3)
✓ Security reviewer complete (2/3)
✓ Performance reviewer complete (3/3)

── Review Verdict: Request Changes ──

## Security (2 findings)
- Token refresh logic doesn't invalidate the old token → potential token replay
- Session expiry check uses client-side clock → can be bypassed

## Correctness (1 finding)
- Missing error handling when refresh token is expired → unhandled promise rejection

## Performance
- No findings

## Recurring Patterns
⚠ Token handling in this module has been flagged in 2 previous reviews
  for similar invalidation gaps.

The review note is committed to your vault. Next time you touch this module, the reviewers will have this context.