How Lintsure works

The short version

Lintsure reads your files on your machine, runs a fixed set of rules against them, and writes a report. It doesn’t upload, index or store your code anywhere, and it doesn’t use a language model to decide results.

What happens in one check

1. Scout walks the folder you point it at. It skips node_modules, .git, dist, build, .next, venv, .venv, __pycache__ and coverage, plus files over 1 MB and binary files. Files are visited in sorted order, so results don’t depend on your file system.
2. Classifier suggests which frameworks apply, from answers about your product, for example EU users, personal data, or AI that decides things about people. It only suggests. You confirm, then set them in your configuration. In v0.1 it runs through the MCP classify tool.
3. Checker runs every rule for the chosen frameworks. Most rules read one line at a time; a few read the whole file. Each rule is pure: the same input gives the same answer.
4. Auditor removes duplicate findings (one per rule, file and line), sorts them by file, line and rule, and keeps only the controls of the frameworks you chose.
5. Fixer gives the fix for each finding as plain text. Your coding agent writes the change, and nothing changes until you approve it. Lintsure itself never edits files.
6. Officer lists what code can’t prove for your frameworks, such as access reviews or training records, with the evidence an auditor will ask for.

Only the Checker can mark Met

Rules can return Gap or Partial. A control is Met only when its rule ran and found nothing. Nothing else in the code can set Met, and a test enforces this.

Where it runs

Way in	Runs where	Good for
MCP server	Your machine, next to your coding agent	Checking while you build
CLI	Your terminal	A first look, or a pre-commit check
GitHub Action	Your own CI runner	Every pull request

All three use the same engine and the same rules, so they give the same result for the same code.