git-lrc: A Git Hook That Runs an AI Review Before Your Commit Lands

The failure mode git-lrc is built around

The README frames the problem with a specific claim: AI agents silently break things. Removed logic, relaxed constraints, new cloud calls that cost money, credentials pasted into a diff. The pitch is that you find out in production rather than in the diff. Whether or not you accept the framing, the timing argument underneath it is concrete. By the time a change reaches a pull request, it is committed and pushed, and the review now involves other people. git-lrc moves the check earlier, to the commit itself, so the finding arrives while the change is still fresh and still yours. The intended user is someone committing frequently, often with an agent or a coding assistant producing large blocks of code quickly, who wants a pass over the diff without opening a PR or pulling a teammate into cleanup. The README also positions it against IDE extensions on the grounds that an extension is a convenience you have to remember to invoke, whereas a git hook fires on every commit. That distinction is the whole design premise.

Where the review actually happens: a git hook and a taxonomy

The mechanism the README describes is a hook on git commit that runs an AI review on every diff before it lands. Two artefacts come out of a completed review. The first is the Issue Navigator, which turns the review into a structured view rather than a wall of inline comments. Its dimensions are stated in the README: filter by severity (Critical, Warning, Info), drill into categories and subcategories (the README gives Security to Secrets Management and Reliability to Error Handling as examples), and slice by type and area (Bug, Code Smell, Reliability, Security). The organising structure is a taxonomy of 10 risk categories and 100+ tracked failure patterns. The second artefact is the Summary Deck, a short slide summary covering what was implemented in plain English, risks called out up front with security, cost and reliability issues on their own slides, and technical highlights such as new config, new endpoints and new data flows. The README states that each finding carries thumbs up/down feedback that tunes future reviews, so signal-to-noise is meant to improve with use. It does not describe the tuning mechanism, so treat that as an unverified claim about behaviour rather than a documented one. The README also mentions pairing the deck with Git Log Tracking, which it says records iteration and coverage history in the commit log.

Installing it and the commands the README gives

The README gives a single install line for Linux and macOS: curl -L https://hexmos.com/ipm-install | bash && ipm i HexmosTech/git-lrc. That pipes a remote script into bash, which is worth pausing on. You are trusting whatever hexmos.com serves at that path, and the repository metadata does not let you verify what that script contains. The safer path, if you want one, is to build the Go binary from the repository yourself, since the primary language is Go and the module path appears in the Go Report Card badge as github.com/HexmosTech/git-lrc. The README points to a Get Started section for Windows, alternative installs and a full setup walkthrough, and claims a 60-second setup. It does not document the config file path or any config keys in the material available here, so I cannot tell you what to edit to change the model, the severity threshold or the categories in scope. If you need that level of control, check the Get Started section and the repository before installing. The README also links a Discord community, which is likely where configuration questions get answered in practice.

The limitation that matters most: it reviews a diff, not a system

Every hook-based reviewer shares a structural blind spot, and git-lrc is no exception. It sees the diff at commit time. It does not run your tests, does not observe runtime behaviour, and cannot tell you that a change is logically wrong but syntactically clean. The README's own list of what it catches (removed logic, relaxed constraints, expensive cloud calls, leaked credentials, changed behaviour) is a list of patterns recognisable from text, which is exactly what a pattern taxonomy can do and exactly where it stops. A subtle off-by-one in a boundary condition, a race introduced by reordering two lines, or a migration that is correct in isolation but wrong against production data are all plausible misses. There is a second, quieter cost: a hook that runs on every commit adds latency to every commit, and if the review is slow or noisy, developers learn to bypass it with --no-verify. The README's feedback loop and severity filtering are clearly aimed at that noise problem, but the material does not state how long a review takes or how many findings a typical diff produces. Treat the 60-second figure as setup time, not review time. Finally, the README's own comparison to PR review cuts both ways: PR review exists partly because a second human brings context the diff does not contain.

What it is not: a replacement for Semgrep or gitleaks

The repository runs four security workflows on itself: gitleaks for secret scanning, osv-scanner for dependency vulnerabilities, govulncheck for Go vulnerabilities, and semgrep for static analysis. That is a useful signal about where the maintainers think the boundary lies. Those tools are deterministic. A gitleaks rule either matches a credential pattern or it does not, and the result is reproducible commit to commit. git-lrc is probabilistic: the same diff can produce different findings on different runs, and the thumbs up/down mechanism exists precisely because the output needs tuning. The two approaches are complementary rather than competing. If your goal is to guarantee that no AWS key ever reaches the history, a deterministic scanner configured as a pre-commit hook is the correct tool, and the README's own CI setup suggests the project agrees. git-lrc's value is in the fuzzy middle: catching a removed null check, a new outbound API call, or a log statement that leaks a token, where the pattern is real but no regex will find it reliably. If you already run gitleaks and Semgrep in CI, git-lrc does not replace either; it adds a layer that fires earlier and reads more loosely.

Licence and maintenance: two things the metadata does not settle

The repository metadata reports the licence as NOASSERTION, which means GitHub could not map the licence file to a known identifier. That is not the same as having no licence, and it is not the same as any particular licence. It means you cannot conclude from the metadata alone what you are permitted to do with the code, particularly if you plan to redistribute it or embed it in a commercial product. Read the LICENSE file in the repository and, if the terms matter to your organisation, have someone qualified read it. On maintenance, the release cadence visible in the material is tight: v0.6.9 and v0.6.10 both landed on 2026-08-24, and v0.6.11 on 2026-09-05. Three releases in under two weeks on a 0.6.x line suggests active development, and it also suggests the interface and behaviour are still moving. The version numbering is the honest signal here: a 0.x project can change how it behaves between minor releases. Budget for that. If you install via the ipm installer, you will need to track upstream to know when a release changes review behaviour or configuration, because the material does not describe a stable config schema you can pin against.

Who should install it, and what to check first

The clearest fit is a developer or small team committing frequently through an AI agent or coding assistant, where large diffs arrive fast and the review habit is the bottleneck. The commit-time trigger suits that workflow because the diff is small and the context is still in your head. The Summary Deck has a second, narrower use: onboarding a new engineer to a change, or reconstructing why something was done six months later, where a plain-English narrative beats re-reading a diff. The clearest mismatch is a team whose commits are already gated by CI checks they trust, or one that cannot send diffs to an external model, since the material does not state where the review runs. Before you wire it into a shared workflow, verify three things in the repository rather than in this article: the licence terms behind the NOASSERTION label, whether the review is local or remote, and what the hook does when the model is unreachable, because a commit hook that fails closed will block every commit and one that fails open will silently skip the review. Check the Get Started section for the Windows path and the config surface, and check the release notes for v0.6.11 to see what changed most recently before you pin a version for a team.

Editorial conclusion

Adopt git-lrc if you commit frequently through an agent or a coding assistant and want a second opinion at the moment the diff is still small and yours, not at PR time when the branch is already pushed. Do not adopt it as your only review gate: it reviews a diff, not a running system, and it will not tell you whether the feature is correct. Before depending on it, confirm two things from the repository itself: the actual licence terms, since the metadata reports NOASSERTION rather than a named licence, and whether your diff leaves the machine at all, since the README documents the install and the review flow but does not state where the model runs.

Official sources

1. HexmosTech/git-lrc on GitHub
2. Issues
3. Project website
4. README
5. Releases