| 🇩🇰 Dansk | 🇪🇸 Español | 🇮🇷 Farsi | 🇫🇮 Suomi | 🇯🇵 日本語 | 🇳🇴 Norsk | 🇵🇹 Português | 🇷🇺 Русский | 🇦🇱 Shqip | 🇨🇳 中文 | 🇮🇳 हिन्दी |

git-lrc

Free, Micro AI Code Reviews That Run on Commit

 

     

GenAI today is a race car without brakes. It accelerates fast -- you describe something, and large blocks of code appear instantly. But AI agents silently break things: they remove logic, relax constraints, introduce expensive cloud calls, leak credentials, and change behavior -- without telling you. You often find out in production.

git-lrc is your braking system. It hooks into git commit and runs an AI review on every diff before it lands. 60-second setup. Completely free.

In short, git-lrc helps Prevent Outages, Breaches, and Technical Debt Before They Happen

At a glance: 10 risk categories · 100+ failure patterns tracked · every commit scanned automatically.

# Try it now (Linux/macOS)
curl -L https://hexmos.com/ipm-install | bash && ipm i HexmosTech/git-lrc

Windows, alternative installs, and full setup walkthrough: see Get Started.

Issue Navigator

A wall of inline comments is hard to triage. The Issue Navigator turns every review into a structured, filterable view across 10 risk categories and 100+ patterns — so you can see exactly what's wrong, ranked by how much it can hurt you.

• Filter by severity — Critical, Warning, Info — fix what matters first instead of scrolling through everything.
• Drill into categories and subcategories — Security → Secrets Management, Reliability → Error Handling, and 100+ more, each with a live count of how many issues were found.
• Slice by type and area — Bug, Code Smell, Reliability, Security — to see exactly where risk is concentrated in a diff.
• Send straight to your AI agent — copy the visible issues or "Send to Claude" and feed them back into the fix loop without retyping anything.
• Feedback loop built in — thumbs up/down on each finding tunes future reviews, so signal-to-noise improves the more your team uses it.

Summary Deck

Every completed review also generates a short slide deck — a 60-second summary of what changed, why, and what risks were flagged, without anyone having to write it.

• What was implemented, in plain English — a short narrative of the change, not just a diff.
• Risks called out up front — security, cost, and reliability issues get their own highlighted slides, in red when they matter.
• Technical highlights, isolated — new config, new endpoints, new data flows — the things a reviewer (or future-you) actually needs to know about.
• Pairs with Git Log Tracking — between the iteration/coverage history in your git log and the summary deck for each review, your team gets institutional memory of every change without anyone maintaining a changelog.

For onboarding new engineers, post-incident reviews, or just remembering why a change was made six months ago, this is the fastest way to get oriented — without re-reading the diff.

See It In Action

See git-lrc catch serious security issues such as leaked credentials, expensive cloud operations, and sensitive material in log statements

https://github.com/user-attachments/assets/cc4aa598-a7e3-4a1d-998c-9f2ba4b4c66e

Why

• AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
• Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
• Build a habit, ship better code. Regular review → fewer bugs → more robust code → better results for your team.
• Why not wait for a PR? By PR time, the faulty code is already committed, pushed, and visible. That is too late for issues you could have fixed yourself while the change was still fresh, without pulling team attention into avoidable cleanup.
• Why not rely on IDE extensions? Extensions are convenience, not a universal trigger. An engineer may choose to run them or not, and teams do not share one editor.
• Why commit? Commit is the sweet spot: early enough to catch problems before they enter permanent git history, but not so early that review depends on individual discretion or special tooling.
• Git is the common denominator. You can't force every engineer onto one IDE or one AI assistant -- but everyone commits. git-lrc plugs into the one workflow step every team already shares.
• Built on habit, not hype. No new dashboard to check, no new ritual to adopt. It rides the commit you were already going to make.

Get Started

Install

Via IPM (Recommended):

# Linux/macOS
curl -L https://hexmos.com/ipm-install | bash && ipm i HexmosTech/git-lrc

# Windows
iwr https://hexmos.com/ipm-install-ps | iex; ipm i HexmosTech/git-lrc

Alternative (direct install):

Linux / macOS:

curl -fsSL https://hexmos.com/lrc-install.sh | bash

Windows (PowerShell):

iwr -useb https://hexmos.com/lrc-install.ps1 | iex

curl -fsSL https://git.new/lrc-install | bash

Binary installed. Hooks set up globally. Done.

Also Included: claude-lrc for Claude Code

Installing git-lrc also gives you claude-lrc -- the same review, vouch, and skip workflow, available as slash commands right inside Claude Code. No separate install, no leaving the chat.

Use git-lrc when you want editor-independent, commit-time enforcement across repos and tools. Use claude-lrc when you want natural-language and slash-command control directly inside Claude Code.

Setup

git lrc setup

Here's a quick video of how setup works:

https://github.com/user-attachments/assets/392a4605-6e45-42ad-b2d9-6435312444b5

Two steps, both open in your browser:

1. LiveReview API key — sign in with Hexmos
2. Free Gemini API key — grab one from Google AI Studio

~1 minute. One-time setup, machine-wide. After this, every git repo on your machine triggers review on commit. No per-repo config needed.

Pricing

Predictable, LOC-based. 30k LOC free every month. Premium starts at $32 for 100k LOC. No headcount based pricing, scales with workload.

No credit card required for the free tier. See the full pricing page for details.

How It Works

Option A: Review on commit (automatic)

git add .
git commit -m "add payment validation"
# review launches automatically before the commit goes through

Option B: Review before commit (manual)

git add .
git lrc review          # run AI review first
# or: git lrc review --vouch   # vouch personally, skip AI
# or: git lrc review --skip    # skip review entirely
git commit -m "add payment validation"

Either way, a web UI opens in your browser.

https://github.com/user-attachments/assets/ae063e39-379f-4815-9954-f0e2ab5b9cde

The Review UI

• GitHub-style diff — color-coded additions/deletions
• Inline AI comments — at the exact lines that matter, with severity badges
• Review summary — high-level overview of what the AI found
• Staged file list — see all staged files at a glance, jump between them
• Diff summary — lines added/removed per file for a quick sense of change scope
• Copy issues — one click to copy all AI-flagged issues, ready to paste back into your AI agent
• Cycle through issues — navigate between comments one by one without scrolling
• Event log — track review events, iterations, and status changes in one place

https://github.com/user-attachments/assets/b579d7c6-bdf6-458b-b446-006ca41fe47d

The Decision

📎 Screenshot: Pre-commit bar showing Commit / Commit & Push / Skip buttons

The Review Cycle

Typical workflow with AI-generated code:

1. Generate code with your AI agent
2. git add . → git lrc review — AI flags issues
3. Copy issues, feed them back to your agent to fix
4. git add . → git lrc review — AI reviews again
5. Repeat until satisfied
6. git lrc review --vouch → git commit — you vouch and commit

Each git lrc review is an iteration. The tool tracks how many iterations you did and what percentage of the diff was AI-reviewed (coverage).

Vouch

Once you've iterated enough and you're satisfied with the code:

git lrc review --vouch

This says: "I've reviewed this — through AI iterations or personally — and I take responsibility." No AI review runs, but coverage stats from prior iterations are recorded.

Skip

Just want to commit without review or responsibility attestation?

git lrc review --skip

No AI review. No personal attestation. The git log will record skipped.

Agent Mode (for coding agents / CI)

Coding agents (Claude Code, Cursor, etc.) shouldn't sit and wait for a browser-based review UI. --agent-mode runs a real AI review non-interactively and reports the findings as JSON:

git add .
git lrc review --agent-mode
git commit -m "add payment validation"

--agent-mode bundles: no browser/TUI, JSON output, and staged-diff scope (commit/range reviews still take priority if you pass --commit/--range explicitly). If the review completes, it records an agent-reviewed attestation — distinct from skipped (no AI review ran at all) and vouched (a human approved without AI) — so the following git commit proceeds without a separate --skip/--vouch step. If the review fails (network, quota, timeout), no attestation is written, so git commit safely falls back to a normal review/skip/vouch decision instead of silently proceeding.

Like a normal git lrc review, you can run --agent-mode more than once before committing (e.g. after fixing flagged issues) — the tool still tracks iterations and prior-coverage credit the same way it does for review/vouch.

Risk-Scored Review View

Huge diffs are hard to triage — 500 lines across 10 files, and every hunk looks equally important. The Risk-Scored View ranks every hunk by blast radius (how far a mistake could ripple through the codebase) and customer impact potential (how close it is to a production-facing surface), so the riskiest changes are always first.

Benefit to Engineering Leaders (CTO / VP Eng / Tech Lead)

• Sensitive code gets more attention. Route handlers, auth modules, persistence layers, and widely-reused interfaces are elevated regardless of how many callers they have — the tool understands architectural importance, not just fan-in counts.
• Review consistency across teams. Every reviewer sees the same risk ranking — not one engineer's hunch about what "looks important" vs another's.
• Quantified review debt per commit. A diff where most hunks rank highly is a diff that deserves more time; a diff that's mostly low-risk hunks can be skimmed with confidence.

Benefit to Engineers

• Never accidentally miss an important piece of code. When a 500-line diff arrives with 10 hunks, the highest-risk one is at the top — not buried in the middle of the diff where it's easy to skim over.
• More efficient review. Start with what matters most; the low-risk formatting or logging-only changes sort to the bottom with a visible hygiene dampener (×0.05) so you can handle them last or skip them.
• Understand why a hunk is risky, not just that it is risky. Click any score badge to see every contributing signal — caller chains, HTTP routes, duplicate implementations, missing tests, architectural-layer classification, and the exact points each contributed.

How Scoring Works (Briefly)

Every hunk gets two independent 0-100 scores, each built from labeled Signals:

Blast Radius — how far the change can propagate:

• Transitive callers up to 3 hops (decay-weighted, sqrt-compressed so one hub symbol cannot swallow the scale)
• Being an HTTP handler or CLI entry point, or being reachable from one
• Repo-wide hotspot and architectural-layer checks (is this symbol a known top-fan-in node, or in the "core" / "api" layer?)
• Implementing or defining a widely-reused interface
• File co-change coupling from git history (files that historically change together even without a code reference between them)
• Lightweight path-keyword heuristics for auth, persistence, config, build, and schema

Review Priority — how much attention this hunk needs:

• A near-duplicate implementation exists elsewhere (did you fix it in both places?)
• Missing direct test coverage
• Cyclomatic complexity, loop depth, and fan-out (supplementary signals)

Combined blends Blast Radius and Review Priority at 60/40 into the final ranking number used for sorting.

Scoring runs locally against a codebase-memory-mcp knowledge graph, concurrently with the server-side AI review — neither waits for the other. The engine binary is auto-installed into ~/.lrc/bin only (no PATH edits, no agent-config changes). Manage it any time with:

git lrc graph install    # install/update the engine
git lrc graph status     # binary path, version, indexed projects
git lrc graph uninstall  # remove it

The first review in a repository indexes it automatically (larger repos take a few minutes, during which the review proceeds normally and scores appear when ready); subsequent reviews refresh the index incrementally in about a second. Reviews work exactly as before without the engine — scoring stays off. Disable explicitly with --blast-radius=false.

Git Log Tracking

Every commit gets a review status line appended to its git log message:

LiveReview Pre-Commit Check: ran (iter:3, coverage:85%)

LiveReview Pre-Commit Check: vouched (iter:2, coverage:50%)

LiveReview Pre-Commit Check: skipped

• iter — number of review cycles before committing. iter:3 = three rounds of review → fix → review.
• coverage — percentage of the final diff already AI-reviewed in prior iterations. coverage:85% = only 15% of the code is unreviewed.

Your team sees exactly which commits were reviewed, vouched, or skipped — right in git log.

Bring Your Own AI Connector (BYOK)

In addition to the default Gemini setup, you can bring your own API keys for:

• OpenAI
• Claude
• DeepSeek
• OpenRouter
• Atlas Cloud

Use:

lrc ui

From the UI, you can:

• Re-authenticate your account
• Add or update AI connectors
• Reorder connectors to set priority

By default, the first connector in the list is used for reviews.

Compatible API Support

We also support:

• Anthropic Compatible API

To configure:

• Select the option Anthropic Compatible API connector from the UI.
• Set the base URL for the API connector by selecting from the dropdown (e.g., gw.claudeapi.com) or entering a custom URL.
• Enter your API key.
• Select the Claude model to use for reviews.

Setup guide: Using ClaudeAPI with git-lrc

Atlas Cloud Support

We also support:

Atlas Cloud

To configure:

• Select the option Atlas Cloud connector from the UI.
• Enter your Atlas Cloud API key.
• Select the model to use for reviews (e.g., deepseek-ai/deepseek-v4-flash).

Repository Rules — Teaching the Reviewer About Your Repository

A good reviewer doesn't just know your language and framework — it knows your repository: which patterns your team prefers, which dependencies are off-limits, and which shortcuts are fine here but wouldn't be elsewhere. Most of that knowledge never makes it into docs, which is why AI review can feel like feedback from a new hire.

git-lrc lets you write that knowledge down once, in a .lrc/ directory at the root of your repo, version-controlled like everything else:

lrc config init

.lrc/
├── README.md            # explains this setup
├── ignore                # files/paths the reviewer should never see
└── rules/
    ├── INSTRUCTIONS.md   # read first — your most important guidance
    ├── design.md
    ├── security.md
    └── style.md          # add as many *.md files as you need

• rules/*.md — short notes on how your team works, e.g. "Prefer direct SQL over ORM abstractions" or "Avoid new infrastructure dependencies." INSTRUCTIONS.md is read first; every other file follows in order. All of it is combined into one set of instructions sent to the reviewer.
• ignore — gitignore-style patterns for files the reviewer should skip entirely (generated code, vendored files, etc.). Ignored files aren't sent to the AI and don't count toward billable lines.
• policy/ — (TODO, not yet enforced) machine-readable settings, such as which tools the reviewer is allowed to use.

Keep it short

The rules/ bundle is capped at 3000 characters. That's on purpose — a twenty-page style guide gets skimmed, by humans and AI alike. A handful of sentences that repeatedly change a review's outcome are worth far more than a full manual:

• "Reliability matters more than latency."
• "Prefer explicit implementations over abstraction layers."
• "Avoid new infrastructure dependencies."
• "Direct SQL is preferred over ORM abstractions."

Nothing hidden

lrc config check    # validate rules, ignore patterns, and bundle size — offline
lrc config preview  # show the exact instructions that will be sent to the reviewer

If it's sent to the model, you can see it first.

Security You Can Trust

• Security is treated as a core product requirement in git-lrc.
• We document reporting channels, response commitments, and operational safeguards clearly.
• Automated security checks and SBOM workflows support transparent verification.
• For complete details, see SECURITY.md.

What git-lrc Checks For

Every review is checked against 10 risk categories and 100+ specific failure patterns, grouped into three pillars: what takes down production, what ends up in a disclosure letter, and what slows every future release. Expand any pillar, then any category, to see the exact patterns and why each one matters.

FAQ

Review vs Vouch vs Skip?

Review is the default. AI analyzes your staged diff and gives inline feedback. Each review is one iteration in the change–review cycle.

Vouch means you're explicitly taking responsibility for this commit. Typically used after multiple review iterations — you've gone back and forth, fixed issues, and are now satisfied. The AI doesn't run again, but your prior iteration and coverage stats are recorded.

Skip means you're not reviewing this particular commit. Maybe it's trivial, maybe it's not critical — the reason is yours. The git log simply records skipped.

Why not review in a PR?

Because that is already late. If a bug or low-value mistake survives until PR review, you have already committed it, pushed it, and asked teammates to look at something you could have corrected yourself earlier. That leaves a record of faulty code and draws shared attention to avoidable cleanup. git-lrc moves that feedback to commit-time, when context is still fresh and fixes are still cheap.

Why not review using IDE extensions?

IDE extensions help, but they are not a reliable enforcement point. A developer can skip them, disable them, or use another editor entirely. That makes them useful convenience tooling, not a universal review trigger.

Why is commit the sweet spot?

Commit-time is early enough to stop faulty code before it becomes part of permanent git history, but late enough to be dependable because every engineer has to commit. It gives you a reliable checkpoint without forcing one IDE, one AI assistant, or extra manual discipline.

How is this free?

git-lrc uses Google's Gemini API by default for AI reviews, and also supports BYOK connectors (OpenAI, Claude, DeepSeek, OpenRouter) — see Bring Your Own AI Connector (BYOK). Gemini offers a generous free tier. You bring your own API key(s) — there's no middleman billing. The LiveReview cloud service that coordinates reviews is free for individual developers.

Which AI providers can I use with BYOK?

You can connect Gemini (default), OpenAI, Claude, DeepSeek, and OpenRouter.

Manage connectors from:

lrc ui

How do I choose which connector is used for review?

Open:

lrc ui

Then reorder your connector list. The first connector is used by default when a review runs.

Can I re-authenticate or change connectors later?

Yes. Run lrc ui anytime to re-authenticate, add/remove connectors, and update connector priority.

What data is sent?

Only the staged diff is analyzed. No full repository context is uploaded, and diffs are not stored after review.

Can I disable it for a specific repo?

git lrc hooks disable   # disable for current repo
git lrc hooks enable    # re-enable later

Can I review an older commit?

git lrc review --commit HEAD       # review the last commit
git lrc review --commit HEAD~3..HEAD  # review a range

Quick Reference

Tip: git lrc <command> and lrc <command> are interchangeable.

It's Free. Share it with your friends and colleagues.

git-lrc is completely free. No credit card. No trial. No catch.

If it helps you — share it with your developer friends. The more people review AI-generated code, the fewer bugs make it to production.

⭐ Star this repo to help others discover it.

Community

Pick the right place based on what you need:

• Discord: discord.gg/sGdnKwB3qq - Best for joining the community, asking general Q&A, and having quick back-and-forth with the team.
• GitHub Discussions: github.com/HexmosTech/git-lrc/discussions - For in-depth idea proposals, scoping, design discussions, modification proposals, and constructive criticism.
• GitHub Issues: github.com/HexmosTech/git-lrc/issues - For concrete, scoped tasks such as bugs, focused feature requests, and actionable implementation work.

License

git-lrc is distributed under a modified variant of Sustainable Use License (SUL).

[!NOTE]

What this means:

• ✅ Source Available — Full source code is available for self-hosting
• ✅ Business Use Allowed — Use LiveReview for your internal business operations
• ✅ Modifications Allowed — Customize for your own use
• ❌ No Resale — Cannot be resold or offered as a competing service
• ❌ No Redistribution — Cannot redistribute modified versions commercially

This license ensures LiveReview remains sustainable while giving you full access to self-host and customize for your needs.

For detailed terms, examples of permitted and prohibited uses, and definitions, see the full LICENSE.md.

For Teams: LiveReview

Using git-lrc solo? Great. Building with a team? Check out LiveReview — the full suite for team-wide AI code review, with dashboards, org-level policies, and review analytics. Everything git-lrc does, plus team coordination.