Let the LLM review your code.

    Lintrule is a command line tool for making a large language model do your code reviews. Enforce policies your linter can't, find bugs your tests won't, and go beyond "LGTM" without wasting your team's time.

    *No credit card required

    Install the CLI

    curl -fsSL https://lintrule.com/install.sh | bash
    Supported on MacOS, Linux, and WSL
    View source

    Write rules in plain language

    🚨 Fail if we're logging customer data or we'll lose our SOC2 certification.
    This is bad:
    This is probably fine:
    console.log("user id: " + user.id);
    $ rules check
    Checking 3 files in parallel...
    Pass - rules/soc2.md => app/routes/login.ts (2133ms)
    Pass - rules/soc2.md => app/routes/check.ts (1238ms)
    Fail - rules/soc2.md => app/routes/log.ts (2138ms)
    The expression 'throw new Error("Failed for customer: " + customer.email)' logs customer data, please fix.


    per 1,000 lines of code changed


    Lintrule runs on git diffs by default. You can estimate your bill by running the following command in your git repo:
    $rules billing estimate


    Lintrule costs more, the more code you write.

    Small Projects
    The Lintrule repo has ~4 contributors and costs about ~$20 per ruleset per month.
    Large Projects
    The Next.js repo has ~55 contributors and costs ~$150 per month per ruleset.
    Really large projects
    The Rust repo has ~190 contributors and costs ~$250 per month per ruleset.
    If you write code, Lintrule can probably review it, no matter the language.


    curl -fsSL https://www.lintrule.com/install.sh | bash


    In your codebase, setup a .rules folder with the init command.

    rules init

    Next, login to Lintrule.

    rules login

    This will create a file a .rules/no-bugs.md with your first rule. It's just a markdown file that says "don't approve obvious bugs." Try running it with:

    rules check

    To save on costs, Lintrule runs on diffs. By default, it runs on the changes since the last commit, effectively git diff HEAD^. If you want it to run on other diffs, you can pass them in as arguments.

    # Check against main and the a feature branch
    rules check --diff main..my-feature-branch
    # Run on the last 3 commits
    rules check --diff HEAD~3

    Configuring rules

    You can ensure rules only run on certain files by adding them to the frontmatter, like this:

    include: ["**/**.sql"]
    We're running postgres 8 and have about 1m rows
    in the "users" table, please make sure our
    migrations don't cause problems.


    Does Lintrule run on diffs?

    Yes. By default, Lintrule runs only on changes that come from git diff HEAD^.

    If you're in a GitHub Action, Lintrule smartly uses the GITHUB_SHA and GITHUB_REF environment variables to determine the diff. For PRs, Lintrule uses the GITHUB_BASE_REF and GITHUB_HEAD_REF.

    Does it have false positives?

    Yes. Just like a person, the more general the instructions, the more likely it will do something you don't want. To fix false positives, get specific.

    On the other hand, Lintrule tends to not be flaky. If a rule produces a false positive, it tends to produce the same false positive. If you fix it, it tends to stay fixed for the same type of code.

    That's a lot of money, how do I make it cheaper?

    • The estimator shows you how much it costs if you run Lintrule on every commit. Try running Lintrule only on pull requests.
    • Instead of using lots of rules, try fitting more details into one rule. But be warned, the more competing details you have in a rule, the more likely it is that you'll get false positives.
    • Use include to silo your rules to certain files. That makes it easier to add more rules without increasing your cost.

    As LLMs get cheaper to run, we expect the prices to go down significantly.

    Is it slow?

    Not really. Lintrules runs rules in parallel, so regardless of how many rules or files you have, it will complete in a few seconds.

    Made in San Francisco, California
    @2023 Lintrule.com