How LintCat works

How a review works

• Read. The reviewer starts from the diff, then opens the surrounding code, the previous version of each file, the files that import it and the tests that cover it.
• Propose. It returns candidate findings, each tied to a file, a line and, where it can, a fix.
• Check. LintCat drops anything that doesn’t point at a line you changed, isn’t confident enough or repeats another finding, and checks every fix against the current file.
• Post. What survives becomes inline comments, the AI PR Review check run and the review on your dashboard.

After the first review, a new push is reviewed from the commits added since, and findings nobody has resolved stay listed on the check run.

What it looks for

• Correctness: wrong conditions or bounds, unhandled empty input, swallowed errors, missing awaits, ordering bugs.
• Security: missing or bypassable auth, cross-tenant access, injection, leaked secrets, sensitive data in logs.
• Performance: N+1 queries, unbounded reads on a request path, quadratic scans over growing data.
• Tests: a new branch the module’s tests don’t exercise, or a test still asserting the old behaviour.
• Documentation: a README, doc or comment the change made wrong.

It leaves style, formatting, naming and architectural taste to your linter and your team. It reports a problem only when it can say concretely what goes wrong, and when.

Keeping the codebase in line

A diff only shows what changed. Before the reviewer starts, LintCat maps the repository’s imports, so for every changed file the reviewer already knows:

• what kind of file it is, and which package owns it;
• which test covers it, or that nothing does;
• how many files import it;
• whether it is dead, with nothing importing it and no entry point reaching it;
• whether it sits in an import cycle.

It can also look up which files use a name that changed, and which files have historically changed alongside this one. That is how it catches the caller that wasn’t updated, the test that no longer covers the code, and the doc that now describes something else.

How it's different

• Nothing unchecked reaches your pull request. Every finding and fix is checked before it posts. See Security.
• It can’t change your repository. The AI reviewer can only read. Comments, and fixes if you turn them on, are posted by LintCat after the checks.
• Fixes are proven, not guessed. A fix is only offered when the lines it replaces match the file exactly, so a suggestion never lands on the wrong code.
• The branch can’t mislead it. LintCat maps your repository as it was before the pull request, so a change can’t misrepresent the rest of your code.
• It never blocks a merge. The check run is advisory.
• Your model, nothing in CI. Install the GitHub App and add a model key. There is no workflow file to maintain.