Not an agentic reviewer
Reviewers hunt for anything that might be wrong. IntentLint enforces a finite rule set your team already chose. Agents read those rules before they write. CI checks the result after.
Tribal knowledge, declared
Payments in integer cents. Migrations that survive a rolling deploy. The authorization boundary nobody is allowed to skip. Write the invariant once. It lives in the repository, not in a senior engineer’s head.
Seconds. Pennies.
It costs pennies to check a pull request against your written rules. Checks usually finish in a few seconds, so engineers and coding agents get the answer while the change is still open.
Setup that starts itself
Install the GitHub App. IntentLint reads the repository and proposes the rules already hiding in docs, reviews, and code. You pick a few. It opens the pull request. No blank config screen.
Beyond syntax
Ordinary linters parse syntax. They cannot tell that a new endpoint skipped your policy layer, or that a worker would charge a customer twice on retry. Prose can.
One GitHub Check
High-confidence violations land as one check. Engineers see a named rule, the evidence, and the smallest fix. Clean pull requests get silence, not a thread of suggestions.
The gap
Your codebase has rules no linter knows
Linters can enforce syntax. They cannot understand that a migration must survive a rolling deployment, that a payment must be safe to retry, or that a new endpoint must use your authorization boundary.
IntentLint evaluates the meaning of a change against the rules unique to your system.
- Payments must use integer minor units.
- Migrations must work with the previous application version.
- Jobs with external side effects must be safe to retry.
- Authorization must pass through the policy layer.
- Customer APIs must not reveal internal account states.
Onboarding
Find the rules you already have
Important engineering knowledge is scattered across documentation, review comments, architecture decisions, and senior engineers’ memories.
IntentLint examines the repository and proposes rules specific enough to enforce. Review the evidence, keep the useful ones, choose warn or fail, and let IntentLint open the configuration pull request.
See how setup works
- Install the GitHub App on the repository.
- Scan. Candidates arrive with the evidence behind them.
- Choose warn or fail for each rule you keep.
- Merge the
.intentlint.yml pull request. Quiet enforcement starts.
One rulebook
Humans, agents, and CI read the same file
Rules live in .intentlint.yml. Coding agents read them before making changes. Developers inspect them in code review. IntentLint independently evaluates them in CI.
No separate prompt library. No reviewer-specific configuration. No knowledge trapped in one tool. The agent that writes the code is not the thing that certifies it.
The rule
version: 1
rules:
- id: jobs/retry-safe-side-effects
description: >
Background jobs that cause external
side effects must be safe to retry
without duplicating irreversible work.
action: fail
scope:
include:
- internal/jobs/**
Quiet by default
Silent when everything is fine
IntentLint does not summarize every pull request or fill it with suggestions. The GitHub Check is the interface. Detail shows up only when someone needs to act.
- IntentLint — Passed No configured rules were violated. No comment.
- IntentLint — 1 warning A confident, non-blocking finding. One remediation.
- IntentLint — 1 rule failed A blocking invariant, with the rule, the evidence, and the smallest fix.
- Unsure Nothing on the pull request. Uncertainty never looks like a pass or a failure.
Category
Not another AI reviewer
AI reviewers search broadly for potential problems. IntentLint checks the specific invariants your team has chosen. Use a reviewer for suggestions. Use IntentLint for rules that must be remembered.
Agentic reviewers
IntentLint
Review code broadlyEnforce a finite rule set
Optimize for coverageOptimize for precision
Comment on clean pull requestsStay silent when nothing failed
Invent criteria on the flyUse rules the team can read
Act like another reviewerAct like CI
Help after the code is writtenGuide agents first, then verify
Trust
Built to be trusted
A semantic check is only useful if developers trust it. IntentLint tracks reliability per rule, stays quiet when it is unsure, separates infrastructure failures from policy failures, and recommends disabling or rewriting rules that generate noise.
Review
Turn repeated feedback into policy
When the same note shows up in review again, capture it once. IntentLint helps turn durable feedback into a named rule, so the next developer and the next agent know the constraint before the pull request exists.
