rag_for_git

An AI pull-request reviewer that reads your whole repository — hybrid RAG + a code graph + Claude Code. Plain linters check a diff in isolation; this agent gives the model the same context a human reviewer has — semantic + lexical retrieval over the entire repo and a structural code graph — then posts the result back to GitHub as inline comments on the exact diff lines, with applyable fixes.

🇷🇺 Русская версия — глубокий, сверенный с кодом разбор: README.ru.md

Table of contents

• Why it exists
• What a review looks like
• Highlights
• How a review runs
• How it works / Architecture
• One-click install prompt
• Installation
• Configuration reference
• CLI reference
• Reviewer grounding in plan/review phases
• Skills reference
• MCP tools reference
• Plugin usage
• Per-repo policy & task board
• Observability web admin
• Known limitations & caveats
• Tests
• Project layout
• Contributing
• License

Why it exists

Plain linters catch syntax and style but miss meaning and relationships — the things a human reviewer actually looks for:

• a changed function contract that silently breaks its callers,
• a guard clause removed three files away from where it mattered,
• a change that contradicts an existing test,
• an edge case that only shows up once you read the helper it calls.

Catching those needs context beyond the diff: who calls this, what it implements, which tests pin its behaviour. rag_for_git gives the model that context — semantic + lexical retrieval over the whole repository and a structural code graph — then runs an agentic tool loop per changed file and posts the result back to GitHub as inline comments on the exact diff lines, plus a summary and applyable fixes.

It is not a wrapper around "send the diff to an LLM." It is a retrieval + code-graph pipeline with a deterministic, anti-hallucination publishing tail.

What a review looks like

An illustrative inline comment the agent posts on a changed line — it found the bug by following the call graph from the edited function to its callers and a contract test:

🟠 correctness — an expired token is no longer rejected

verify_token used to raise on an expired signature; the new guard only checks payload is None, so _decode() returning a payload with a past exp now passes as valid. Two call sites depend on that raise — require_auth (auth/deps.py:48) and the contract test test_expired_rejected (tests/test_auth.py:71), which this change would break.

    if payload is None or payload.get("exp", 0) < now:
        raise InvalidToken("expired or malformed token")

Every finding is grounded on an exact quote from the diff, carries a category / severity / confidence, and — when it's safe — ships as a one-click GitHub suggestion. A hidden fingerprint (<!-- ai-review:… -->) makes re-runs idempotent: the same issue is never posted twice.

Highlights

• Whole-repo context, not just the diff. Hybrid retrieval (pgvector ANN + BM25, fused with RRF, reranked by Voyage) over the entire indexed codebase — for changed files the agent sees the new version, for everything else a stable base index.
• It sees impact. A Neo4j code graph (CALLS / IMPLEMENTS) expands each changed symbol 1–2 hops to surface callers, callees, implementations, and the tests that pin them.
• Anti-hallucination by construction. A finding must quote real code to be placed on a line; a dedicated verify pass drops invented findings; line grounding is exact-match.
• Real GitHub output. Inline comments on diff lines, applyable suggestion blocks under safe invariants, a summary for everything off-diff — idempotent across re-runs.
• Lives in your editor, not a CI black box. Ships as a Claude Code plugin and as an MCP server usable from 12+ AI clients (Cursor, VS Code, Gemini CLI, Codex, Windsurf, Claude Desktop, …). One uvx command; published on PyPI.
• Local-first. Your code stays on your machine — only embedding/query text goes to Voyage; the stores (Postgres/ParadeDB + Neo4j) run in local Docker.
• More than review. The same RAG + graph powers grounded codebase Q&A (ask), PR walkthroughs, and per-subsystem summaries.
• From task to implementation — the killer feature. solve-task reads a task from your board, pulls related tasks/prs/code via the RAG + graph, distills a structured brief, and hands off to the full superpowers cycle: brainstorming → writing-plans → subagent-driven-development → executing-plans → finishing. The only end-to-end pipeline that truly connects your task tracker to implementation.

How a review runs

A single PR review is three stages:

prepare_review (MCP) → analyze (Claude subagents) → publish_review (MCP)

1. prepare — GitHubProvider pulls the PR (base/head SHA) and changed files; changed .py files are chunked (tree-sitter) and embedded (Voyage) into an ephemeral overlay ref="pr:N"; policy and per-file review units are assembled.
2. analyze — the Claude Code skill fans out one subagent per file. Each reasons over the diff in a tool loop, pulling in whatever code it needs: search_code, get_related_symbols, read_file, get_definition, find_callers, get_changed_file_diff. In parallel, dimension subagents run a performance and maintainability pass, plus a requirements pass when a task board is wired up, and a final verify pass strips hallucinations.
3. publish — a deterministic tail: policy gate (category/severity/confidence/paths) → line grounding by exact code quote (anti-hallucination) → dedup → assemble (inline vs summary, suggestion invariants, fingerprint idempotency, comment cap) → post to GitHub → history record → overlay/session cleanup.

If a review is abandoned between prepare_review and publish_review (user cancelled, orchestrating LLM session died), publish never runs — such an overlay is collected by GC: opportunistically on the next prepare_review, and via the reviewer gc command.

Session liveness is extended by activity (keepalive): review tool calls bump last_seen_at, so a review running longer than review_session_ttl_hours keeps its overlay; an idle review is still collected once the TTL elapses.

Status: working v1. Target analysis language is Python; VCS is GitHub (behind a VCSProvider interface). Proven live: it catches real bugs and sees the impact on calling code and existing tests.

How it works / Architecture

The core is the reviewer/ library, assembled in reviewer/app.py::build_components(settings) from Settings (pydantic-settings, .env). Entry points are reviewer/entrypoints/cli.py (Click) and reviewer/entrypoints/mcp_server.py (FastMCP). Three pieces work together:

• RAG (hybrid retrieval). Postgres/ParadeDB stores code chunks with pgvector (HNSW ANN) and pg_search (BM25). A query embeds with Voyage, runs both ANN and BM25 search, and the result lists are merged with Reciprocal Rank Fusion (RRF), then reranked with Voyage rerank-2.5.
• Code graph (SCIP or tree-sitter, Neo4j). Symbols and their relationships live in Neo4j. The graph orchestrator (graph/backend.py) picks a backend via GRAPH_BACKEND (auto|scip|treesitter): SCIP (@sourcegraph/scip-python) gives a precise, type-aware graph with CALLS + IMPLEMENTS edges; tree-sitter is a fast fallback with CALLS-by-name only. Retrieval expands the changed symbols 1–2 hops to surface callers/callees/implementations/tests.
• Claude Code plugin via MCP. The reviewer-mcp server exposes prepare_review, publish_review, and the agent tools. The Claude Code plugin (plugin/) drives the review: it calls prepare_review, runs analysis subagents against those MCP tools, then calls publish_review.

The single key linking RAG and the graph is node_id = "path#fqn" (e.g. rag/embedder.py#VoyageEmbedder.embed_query). Both the chunk in Postgres and the node in Neo4j use it, so graph expansion and chunk retrieval are stitched together without any mapping table.

Index freshness: a stable base + a PR overlay. A full reindex of a large repo is expensive, so the index keeps a persistent base and layers PR changes on top:

• ref="base:<branch>" — the persistent index of a tracked branch (e.g. "base:main", "base:master"). Each tracked branch in REVIEW_BRANCHES has its own isolated index. Updated incrementally by reviewer index --ref <branch> (only changed files are chunked; only chunks with a new content_hash are re-embedded — embeddings are reused across branches by hash, saving Voyage quota).
• ref="pr:N" — an ephemeral overlay of just the PR's changed files at its HEAD.
• On a query: retrieval = (base:<branch> where path ∉ changed) ∪ overlay. For changed files the agent sees the new version; for everything else, the stable base.
• Multi-branch. A PR is reviewed against the index of its target branch (base_ref from the PR). A PR targeting an untracked branch is skipped (prepare_review returns {"status":"skipped",...}). The code graph (Neo4j :Symbol) is also branch-scoped via a branch property, with unique constraint (repo, branch, id).

                ┌─────────────────────────── reviewer (core library) ───────────────────────────┐
                │                                                                                 │
  GitHub PR ───▶│  VCSProvider (github.py)  ──diff/files/patches──▶  MCPReviewService             │
  (owner/repo#N)│        ▲  publish inline + summary                       │ prepare_review        │
                │        │                                                 ▼                       │
                │        │                          ┌──────────── retrieval/Retriever ──────────┐ │
                │        │                          │  hybrid search        graph expansion      │ │
                │        │                          │  ┌──────────────┐   ┌───────────────────┐  │ │
                │        │                          │  │ Postgres      │   │ Neo4j             │  │ │
                │        │                          │  │ (ParadeDB)    │   │ Symbol(path#fqn)  │  │ │
                │        │                          │  │ pgvector(HNSW)│   │ -[:CALLS]->        │  │ │
                │        │                          │  │ + pg_search   │   │ (IMPLEMENTS: SCIP) │  │ │
                │        │                          │  │   (BM25, RRF) │   │ expand 1–2 hops    │  │ │
                │        │                          │  └──────┬───────┘   └─────────┬─────────┘  │ │
                │        │                          │   Voyage embed/rerank   tree-sitter graph  │ │
                │        │                          └─────────────────┬─────────────────────────┘ │
                │        │                                            ▼ ContextPack                │
                │        │                       Claude Code subagents (skill /rag-reviewer:reviewer_review-pr)
                │        │                         tools: search_code, get_related_symbols,        │
                │        │                         read_file, get_definition, find_callers, …      │
                │        └─────────────────── publish_review (gate/grounding/dedup/assemble) ◀─────┘
                └─────────────────────────────────────────────────────────────────────────────────┘

  Stores (Docker):  Postgres/ParadeDB (:5433)  ·  Neo4j (:7687)
  External API:     Voyage (embeddings voyage-code-3 + reranker rerank-2.5)

For a deeper, code-verified walkthrough of every module and the data flow, see README.ru.md (Russian).

One-click install prompt

Copy and paste into any AI coding assistant:

uvx --from rag-reviewer reviewer install --all

This auto-detects installed AI clients and wires the MCP server. For manual setup see Manual setup below.

Installation

The MCP server is published on PyPI as rag-reviewer and runs via uvx — no clone of this repo required.

Requirements: Docker, uv (includes uvx), a Voyage API key, a GitHub token. Python 3.11–3.13 (only needed for a pip/editable install; uvx manages its own).

Quick setup (recommended, all platforms)

# 0) Install the reviewer CLI — once, globally
uv tool install rag-reviewer
# uv and uvx are the same binary; installing uv gives you both.
# The MCP server launched by your editor uses uvx @latest and self-updates automatically.

# 1) Infrastructure
curl -O https://raw.githubusercontent.com/mimfort/rag_for_git/main/docker-compose.yml
docker compose up -d          # Postgres/ParadeDB (:5433) + Neo4j (:7687)

# 2) Configure keys and settings interactively
reviewer init
#    Interactive wizard: fills VOYAGE_API_KEY, GITHUB_TOKEN, and optional groups
#    (stores, multi-repo, task board). Re-run any time to update settings.
#    CI / non-interactive: reviewer init --yes  (accepts all defaults silently)

# 3) Register the MCP server (and skills) in your editor/CLI
reviewer install --all        # auto-detect installed clients + install skills
#    or a specific one: reviewer install cursor|vscode|claude-code|claude-desktop|windsurf|gemini|antigravity|mimo|opencode|kimi|trae|codex
#    file-based skills go to Gemini/Mimo/OpenCode/Kimi; --no-skills skips skills

# 4) Verify
reviewer check

# Update CLI later:
uv tool upgrade rag-reviewer

reviewer install is cross-platform (Windows / macOS / Linux). It injects the absolute path to uvx automatically — no bash -lc wrapper needed. The manual JSON configs below use bash -lc for macOS/Linux only; on Windows use reviewer install or set "command": "uvx" with "args": ["--from", "rag-reviewer@latest", "reviewer-mcp"] directly.

Claude Code is global by default. reviewer install claude-code manages the user-scope rag-reviewer plugin from the canonical HTTPS marketplace source, so it works from any current directory and in every project. It also writes the global mcp__reviewer__* allowlist rule in ~/.claude/settings.json (permissions.allow). Use reviewer install claude-code --no-skills when you need only a global MCP server and no plugin skills.

Where keys are read from. The reviewer resolves its .env from a fixed location, not the current working directory — MCP clients launch the server with an arbitrary CWD, so a project-local .env is unreliable. Lookup order: $REVIEWER_ENV_FILE → $XDG_CONFIG_HOME/rag-reviewer/.env (default ~/.config/rag-reviewer/.env) → ./.env (handy when running from a repo clone). Real environment variables always win over the file, so you can instead pass keys via an "env": { "VOYAGE_API_KEY": "…", "GITHUB_TOKEN": "…" } block in your MCP client config — works in every client.

• Voyage (VOYAGE_API_KEY): https://dashboard.voyageai.com/ — free token pool; attach a card to lift the 3 RPM / 10K TPM limit (charged only beyond the free pool).
• GitHub (GITHUB_TOKEN): a PAT with Pull requests: Read and write + Contents: Read (fine-grained) or the repo scope (classic). Quick option: gh auth token.

All other settings have defaults (documented in .env.example and in Configuration reference below).

Manual setup (alternative)

If you prefer to configure your client config by hand rather than using reviewer install:

Each AI coding tool has its own config file. Pick yours:

Files marked ✓ are already present in this repo — if you open rag_for_git as a project in that tool, the MCP server auto-connects. For a global install (works from any project), add the entry to the corresponding global config file. For Claude Code, use the user-scope plugin command below instead of a project-local MCP file.

The MCP entry format by tool (macOS/Linux — use reviewer install on Windows):

Mimo Code (mimocode.json):

{
  "$schema": "https://mimo.xiaomi.com//config.json",
  "mcp": {
    "reviewer": {
      "type": "local",
      "command": ["/bin/bash", "-lc", "uvx --from rag-reviewer@latest reviewer-mcp"],
      "enabled": true
    }
  }
}

OpenCode (opencode.json):

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "reviewer": {
      "type": "local",
      "command": ["/bin/bash", "-lc", "uvx --from rag-reviewer@latest reviewer-mcp"]
    }
  }
}

Kimi Code / Cursor / Gemini CLI / Trae / Claude Desktop / Windsurf / Antigravity (standard mcpServers JSON):

{
  "mcpServers": {
    "reviewer": {
      "command": "/bin/bash",
      "args": ["-lc", "uvx --from rag-reviewer@latest reviewer-mcp"]
    }
  }
}

VS Code (mcp.json — note: key is servers, not mcpServers):

{
  "servers": {
    "reviewer": {
      "command": "/bin/bash",
      "args": ["-lc", "uvx --from rag-reviewer@latest reviewer-mcp"]
    }
  }
}

Codex CLI: install with the canonical commands in AGENTS.md, then verify:

codex plugin list --json
codex mcp list

Success means rag-reviewer is installed and enabled and codex mcp list contains exactly one reviewer. Identified legacy skills are moved to $CODEX_HOME/reviewer-legacy-backups/<timestamp>; modified or ambiguous copies stay untouched. Failures print the config backup path. Open a New Chat/new CLI session after installation; in an IDE, also use Reload Window.

Claude Code (global plugin marketplace)

Install or update it from any directory:

uvx --from rag-reviewer@latest reviewer install claude-code

The command manages the user-scope rag-reviewer plugin through the canonical HTTPS source https://github.com/mimfort/rag_for_git.git; it does not depend on the current project. Verify the installed plugin with the public CLI:

claude plugin list --json
# optional: confirm the canonical marketplace source too
claude plugin marketplace list --json

plugin list should contain an enabled rag-reviewer@rag-reviewer-marketplace entry with "scope": "user". The optional marketplace listing should report "source": "git" and the exact HTTPS URL above. Open a New Chat/new CLI session afterwards; in an IDE, use Reload Window as well.

To register only the global MCP server and intentionally skip plugin skills, run:

uvx --from rag-reviewer@latest reviewer install claude-code --no-skills

Manual fallback (only if the installer cannot be used):

claude plugin marketplace add https://github.com/mimfort/rag_for_git.git \
  --scope user --sparse .claude-plugin plugin
claude plugin install rag-reviewer@rag-reviewer-marketplace --scope user

You get:

• Skills: /rag-reviewer:reviewer_review-pr, /rag-reviewer:reviewer_solve-task, /rag-reviewer:reviewer_sync-codebase, /rag-reviewer:reviewer_sync-tasks, /rag-reviewer:reviewer_performance-review, /rag-reviewer:reviewer_maintainability-review, /rag-reviewer:reviewer_ask, /rag-reviewer:reviewer_pr-walkthrough, /rag-reviewer:reviewer_configure-review, /rag-reviewer:reviewer_summarize-subsystems, /rag-reviewer:reviewer_finish-task (see Skills reference).
• MCP server reviewer exposing the 31 tools in MCP tools reference.

Run /plugin to confirm rag-reviewer is installed and enabled.

Install skills globally (optional)

Every directory under plugin/skills/ that contains SKILL.md is registered under the rag-reviewer namespace. _common and nested references are delivered as supporting files but are not registered as skills. These skills wrap the MCP tools into guided flows. Without them you can still call MCP tools directly, but the skills are the intended entry point.

reviewer install already installs them for clients that support file-based skills (Gemini, Mimo, Kimi, OpenCode). To (re)install just the skills — or pick a specific client — use:

uvx --from rag-reviewer reviewer install-skills --all     # all detected skills-capable clients
uvx --from rag-reviewer reviewer install-skills gemini    # a specific one
uvx --from rag-reviewer reviewer install-skills --list    # show targets + directories

It downloads the skills from GitHub (no repo clone) and unpacks them into each client's global skills directory, with a path-traversal guard. Manual fallback (equivalent):

curl -sL https://github.com/mimfort/rag_for_git/archive/refs/heads/main.tar.gz -o /tmp/rag-reviewer.tgz
mkdir -p ~/.gemini/skills
tar xz -C ~/.gemini/skills --strip-components=3 -f /tmp/rag-reviewer.tgz 'rag_for_git-main/plugin/skills'
rm /tmp/rag-reviewer.tgz

That's it. Build the base index (recommended — see CLI reference) and review a PR (see Plugin usage).

Configuration reference

Everything is configured through environment variables (.env, see .env.example with comments). The only required external key is VOYAGE_API_KEY; GITHUB_TOKEN is required for PR review. All other settings have working defaults that match the bundled docker-compose.yml. The .env is resolved from $REVIEWER_ENV_FILE → ~/.config/rag-reviewer/.env → ./.env (real env vars always win).

Voyage — embeddings + reranker (required)

GitHub (required for PR review)

Stores (Postgres/ParadeDB + Neo4j)

Multi-platform VCS (optional)

Multi-repo / multi-branch (optional)

Review policy (env defaults; per-repo .review.yml overrides)

Observability & sessions (optional)

Summary & graph tuning (optional)

Task board (optional) — deploy-wide default

A board connection is the same for every repo of one team, so it is configured once in the reviewer-mcp env rather than duplicated in each repo's .review.yml. See Per-repo policy & task board.

Getting YOUGILE_API_KEY (Yougile). UI: press Ctrl + ~ (or ⚙ next to the company name → "Настроить") → API → create/copy the key. REST: get companyId (Ctrl + Alt + Q, or POST /api-v2/auth/companies {login,password}), then POST /api-v2/auth/keys {login,password,companyId}. The key belongs only in the reviewer-mcp env (~/.config/rag-reviewer/.env), not in a chat or a client config.

Reviewer grounding in plan/review phases (optional)

The reviewer MCP tools are available in every phase, not only inside a PR review. If you run a plan/review workflow (e.g. Superpowers' writing-plans, or any code-review step), you can have the agent ground its work in the RAG + code graph instead of raw grep. This is opt-in: paste the block below into your agent context file (CLAUDE.md / AGENTS.md / GEMINI.md / .cursorrules — whichever your client uses).

Reviewer grounding (plan/review, optional, fail-open). When the reviewer MCP is connected and its base index is fresh (reviewer status --json -> drift == 0), prefer the session-less reviewer tools over grep to ground cross-file facts during planning and review: search_codebase (relevant code), callers (blast-radius of a signature you are about to change), related_symbols, definition, implementations (directed subclasses/overrides). Be targeted — skip small/familiar edits and files already in context (Voyage is rate-limited). The base index tracks the target branch, not your working tree: grounding is reliable for existing code but blind to symbols you just edited locally — verify those with Read. If reviewer is absent or the index is stale, fall back to grep/Read.

CLI reference

All commands run via uvx --from rag-reviewer <command>, or after uv tool install rag-reviewer / pip install -e ".[dev]" simply as reviewer. Two entry points are installed: reviewer (the CLI below) and reviewer-mcp (the MCP server, started by your editor/plugin).

Examples:

# First-time setup
uvx --from rag-reviewer reviewer init
uvx --from rag-reviewer reviewer install --all
uvx --from rag-reviewer reviewer check

# Build the base index (whole-repo context for RAG + graph)
uvx --from rag-reviewer reviewer index /path/to/repo --ref main --repo owner/name
uvx --from rag-reviewer reviewer index /path/to/repo --ref master --repo owner/name   # second tracked branch

# Diagnostics (no Voyage spend except `search`)
uvx --from rag-reviewer reviewer search "token verification" --branch master
uvx --from rag-reviewer reviewer status /path/to/repo --branch dev

# Web admin
uvx --from rag-reviewer reviewer serve --host 127.0.0.1 --port 8000

Reviewing works even without a prior index — context is then limited to the diff and the overlay (RAG/graph are "thin"). For full whole-repo impact analysis, run index against the target branch.

Skills reference

Skills are the guided entry points for the workflow. With the plugin installed they are invoked as /rag-reviewer:<name> in Claude Code (the leading /rag-reviewer: is the plugin namespace; on other clients the skill name is the same). Arguments are passed as free text after the skill name ($ARGUMENTS).

reviewer_review-pr — full PR review

Orchestrates the three-stage pipeline (prepare_review → subagents → publish_review).

• Arguments: the PR as owner/repo#N, owner/repo N, or a GitHub PR URL. Add --dry-run to assemble and return the full report without posting to GitHub.
• MCP tools used: prepare_review, search_code, get_related_symbols, read_file, get_definition, find_callers, get_changed_file_diff, get_impact, submit_findings, get_candidate_findings, submit_verdicts, publish_review; plus index_task / get_task_context / search_tasks when a task board is wired up. Task reads are scoped via project=<task_board.project> passed to get_task/get_task_context/search_tasks (PRI-170).
• Flow: prepare (PR + policy + units + board config) → fan out one analysis subagent per file → parallel performance / maintainability dimensions (+ requirements if a TaskBrief exists) + blast-radius (impact analysis via get_impact, plus shared-interface conformance: a changed Protocol/ABC → enumerate implementations and confirm all are updated) → verify pass (drops is_real=false findings) → publish (gate/grounding/dedup/assemble). If prepare_review returns status:"skipped" (target branch not tracked) it stops; draft PRs are skipped unless REVIEW_SKIP_DRAFTS=false.

reviewer_solve-task — from task to implementation (killer feature)

This is the plugin's standout capability: it reads a task from your board, pulls everything the implementer needs via the RAG + code graph, and hands off to the full superpowers development cycle — not just a single step.

Reads a task (if a key + board), pulls related/similar tasks and relevant code, distills a brief, and enters brainstorming. It disciplines context-gathering — it does not write the code.

• Arguments: a task key (e.g. PRI-4, must match key_pattern) or a free-text description (e.g. "add a logout endpoint"). Board-less mode falls back to description + code search.
• MCP tools used: get_board_config, get_subsystem_summaries, get_task, index_task, get_task_context, search_tasks, search_codebase, related_symbols, callers, definition, implementations, get_pr_diff; plus the connected board MCP (mcp__<board>__*) to read the task. All task tools are scoped via project=<task_board.project>.
• Flow: preflight (index freshness check → task corpus warmup via sync_board) → subsystem prior via get_subsystem_summaries → resolve board config → identify task (key vs free text) → store-first task read via get_task(key, project=...) (hit = use directly; miss = board MCP fallback) → best-effort, fail-open context gathering (task graph, similar tasks, relevant code, lazy PR diffs of similar tasks) → distill a structured brief (Task / Related work / Relevant code / Constraints) → persist it to docs/superpowers/briefs/ (ГГГГ-ММ-ДД-<KEY>-<slug>.md, survives context compaction) → hand off to superpowers:brainstorming with the brief file path as seed → full superpowers cycle: brainstorming → writing-plans → subagent-driven-development → executing-plans → finishing-a-development-branch.
• Cheaper model for the brief (cross-CLI). Before building the brief, solve-task asks which model tier to run it on (by tier — cheap / mid / premium — not by model name, so it works across CLIs) and recommends a mid (Sonnet-class) default: gathering and distilling the brief is light reasoning, so a top-tier model is overkill. Where the harness supports per-subagent model override it dispatches the brief-building on the chosen model; otherwise it builds inline.

reviewer_sync-codebase — build/update the base index

Thin wrapper over reviewer index (vector store + code graph) from a local clone.

• Arguments (all optional): --path <path> (default: CWD), --ref <branch> (default: main), --repo <owner/name> (default: derived from git remote get-url origin), --backend <auto|scip|treesitter> (default: auto, sets GRAPH_BACKEND).
• MCP tools used: none directly — it shells out to uvx --from rag-reviewer reviewer index.
• Flow: resolve inputs → check prerequisites (uvx, git repo, reviewer check, Docker up) → run indexing → optional reviewer search to verify → report chunks/nodes/edges and which graph backend was used.

`reviewer_s