rag-reviewer

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
• 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