Rigour

Rigour

[npm version] [npm downloads] [License: MIT] [MCP Registry]

A reviewer that knows how your team works, whichever agent writes the code.

Whichever agent your engineers use, its work arrives already shaped by how your team builds software, and it gets closer to your standards every week.

Teams used to carry their judgment through people: the senior who briefed you before you started, the reviewer who caught what you missed, the engineer who remembered why the last attempt failed. Coding agents write faster than any person can brief, review or remember. The knowledge is still in your team; Rigour is how it reaches every agent, at the speed agents work.

Works with Claude Code, Cursor, Codex, Cline and Windsurf. Free, open source, and runs on your machine.

How it does it

1. Brief before writing. Before an agent edits a file, it is told what your team asks of that file: the rules your repository wrote for it, the lessons your team learned on it, the points your team settled against. At most three items per file, each cited. Installed by rigour setup (--no-brief to leave it out), or rigour_brief for any agent with MCP. See The briefing.
2. Verify while writing and before push. Your team's checks and rules gate any agent's work: on every edit, before the agent says "done", and before git push, where your formatter, linter, type check and the tests that touch the change run too. Opt-in, the change is also checked against the goal its pull request declares: files outside its scope, "done when" items it never did. See The goal check.
3. Review with your team's context, at your team's severity. A reviewer that reads every point from your last human review, checks each rule your repository wrote that the change touches, and takes your reviewer's own "Blocking / Should fix / Nits" over its own reading. What your team blocks and what it lets go is your repository's setting, not one global opinion. See The reviewer.
4. Learn from outcomes. A review point becomes a lesson only on evidence: a person corrected an agent's work, someone on the team decided, or it recurred across authors. What happened after the merge (a later fix on its lines, a revert) is shown to a person to decide, never a promotion on its own, and a lesson the team keeps merging against cleanly is taken back. What it learns flows into the next briefing and the next review.

One piece of work is one task, whatever agents and people touch it, and rigour thread shows everything that happened to it: what was caught while the code was written and fixed before the push, what blocked, what each review found. See The task thread.

What it is, and what it is not

• It learns only from evidence: your rules files, review points that were acted on, people's corrections, and what happened after merge. A guess never becomes a rule.
• It shapes and checks the agent; it never changes the model. No training, no fine-tuning. Any agent, any model.
• Concrete taste it captures well ("bound the window at both ends", "rerun the code generator after changing the schema"). Design taste stays with your people: anything Rigour cannot show in code is a should-fix at most, never a block.
• One machine, many companies, nothing crosses. Profiles keep each employer's or client's memory, lessons and team apart, chosen by the repository you're in. See Profiles.
• It starts from what you have written down. On day one, the briefing and the reviewer carry your repository's own rules (AGENTS.md, CLAUDE.md, Cursor rules, Copilot instructions). Lessons join as your reviews give them evidence, so a team with little review history starts with little to brief, and the briefing is off until you turn it on.

What runs by default, and what it costs

How it works

With the briefing on, a line comes before all of these: before each file's first edit, what your team asks of that file.

Get started

See what it finds first, changing nothing (on a branch with work on it):

npx @rigour-labs/cli review --base origin/main

Worth it? Set it up:

brew install rigour-labs/tap/rigour    # or: npm install -g @rigour-labs/clirigour setup                           # in your repository

rigour setup connects Rigour to your agents, installs the three moments, and checks that everything works. By default it is personal: nothing in your working tree. The agent hooks are installed once per machine and stay silent in any repository you have not switched on, and switching this one on writes only inside .git/. When your team wants it for everyone who clones, rigour setup --team commits it to the repository instead. Either way it merges into the agent configs you already have rather than replacing them. Changed your mind? rigour uninstall takes out exactly what it put in. Get started walks through it.

Rigour is about 70 MB per version. Semantic search (about 250 MB on Linux, 280 MB on macOS) is installed once per machine by rigour setup and shared by every version; skip it with --no-semantic.

Using Claude Code? The plugin does all of it:

/plugin marketplace add rigour-labs/rigour-plugin/plugin install rigour@rigour-labs

Want the reviewer too? It is off until someone turns it on, and you choose how far to take it: for yourself in Studio's Setup page, or for the whole team in rigour.yml:

review:  reviewer:    enabled: true    mode: full          # one judge per vendor, up to `judges`; single (the default) is one judge    panel: on           # only what most judges confirm blocks; required: no one may turn it off    judges: 3           # 2 or 3, one per vendor installed    escalate: risk      # add judges only for risky changes; measure it with rigour backtest first

The push goes through as soon as the checks pass; the reviewer then reads the pushed commit in the background (only when it has an open, non-draft pull request, so you pay for a model only when someone will read the push). rigour review --status shows its verdict and what ran; rigour review --reviewer --full is the hard stop before you ask a person to review. Your own choice wins for your runs, except where the team set a floor, and Rigour always says which judges actually ran and why.

Then open Studio to watch it work:

rigour studio

The commands you will use

Everything else is in rigour help --all.

Built to be trusted

• It blocks only on what it can show. A deterministic check blocks only after it has been run over real merged pull requests. The model reviewer's findings block only when they name a wrong outcome or a cost, and with a panel, only when most judges agree. Guesses about style or size never block you and never show up on a PR.
• Say "not a bug" once. That finding never comes back, and checks your team keeps overruling go quiet on their own.
• When it can't check, it says so. No reviewer answer, nothing to review, a tool that isn't installed: each is reported plainly, never as a clean pass.
• Your code stays on your machine. The checks run locally. Code leaves only for a model you choose: your agents' own CLIs for the reviewer, or a provider when you run a model review with your key. Team sync sends only lessons from your team's own repositories. Every network call Rigour can make, and how to turn each off, is in Security.
• You see what it costs. When a model is used, Rigour records the real cost of each run.
• You see what each judge knew. A judge reads your repository and what Rigour gives it. The Claude judge loads no one's personal instructions; where a judge cannot be kept from a person's own config (Codex, Cursor), the record of the review says what else it read.
• Measured in the open. Claims about what Rigour catches are tested on real pull requests in the public driftbench arena.
• Measured against your own reviewers. rigour backtest replays the review on commits your team reviewed, with the review hidden, and scores it: which of the reviewer's points it would have caught first, and whether it would have blocked anything they called good. See Backtest.
• One rule for what blocks. The review, the stop hook and the push gate decide from the same rule, so they never disagree about a finding.

What it costs

Rigour is free. With an agent you need nothing else: the checks run locally, and the reviewer and the review of risky changes use your agent's own model and login. A model key is only for reviewing code written without an agent, and for the pull request bot.

For teams

Pull requests. Add one workflow file and Rigour reviews every PR, quietly. Make it a required check, and a PR can't dismiss its own findings or loosen its own settings. See Pull requests and CI.

One setup for everyone. rigour setup --team commits the configuration, and each teammate runs rigour setup once after cloning. See Team setup.

Shared knowledge. Point Rigour at a PostgreSQL database and lessons one person's agent learns can be shared with the whole team, after someone approves them. Only lessons from the team's own repositories are ever sent. See Team database.

Joining a team that already shares lessons? Ask your team's Rigour administrator for your own login first: by design, nobody can add themselves. Then it is one command per machine and three per clone. See Join an existing team.

How the benefit reaches each person. One review comment, followed from the pull request where a senior wrote it to every teammate's agent on the next change: A team's knowledge, from one review to every agent.

Working for more than one company? Profiles keep each one's memory, lessons and team apart, chosen by the repository you're in. See Profiles.

Learn more

Build from source

pnpm installpnpm buildpnpm test

See Contributing.

Documentation · Discussions · Issues

MIT © Rigour Labs · Built by Ashutosh