日本語 · 简体中文 · English

Get started  ·  CLI  ·  Presets  ·  Coding agents  ·  Docs

A model-based linter that tells you what to refactor first.

ESLint tells you a line broke a rule. jevlint reads every file in your repository, scores how clean it is against principles you choose, and hands you a ranked list: messiest and most-changed files first. Then it writes the prompt that gets Claude Code or Codex to fix them.

_{Illustrative example on a fictional file.}

No install, no API key, and your code stays on your machine:

npx @indxjp/jevlint --ast-only

npm install -g @indxjp/jevlint     # or: pnpm add -g @indxjp/jevlint
jevlint --version

Requires Node.js 24.22.1 or later (or 22.23.4, or 26.12.1, on those lines).

A team inherits shop-api and has one afternoon for cleanup. jevlint picks the file, explains why, hands it to Claude Code, and confirms the score went up.

_{Simulated run on a fictional project. Recording script.}

• Two kinds of judgement. AST analysis measures what is measurable, such as complexity and nesting. A decision model answers what needs judgement, such as "do these names carry meaning?"
• Decision models, not chatbots. Models like TypeSafe AI's Jev return calibrated scores and probabilities rather than prose. That makes them fast and cheap, and it means results can be ranked and cached.
• A ranking, not a wall of warnings. Files are ordered by mess, git churn and size, so the first item is the one worth your time.
• Reviews of a change, not only a repository. jevlint pr and jevlint commits show a file's score before and after, and only what the change made worse. --intent also holds a change against its message and your AGENTS.md.
• Your own rules, in one sentence. An ast-grep pattern picks the code and a yes/no question judges each match, so a model's verdict gets a line number.
• Most source languages. TypeScript, JavaScript, Python, Go and Rust get exact metrics. Other languages get approximate ones, with no extra install.
• Principles as presets. Audit against ideas from well-known software books, or write your own in a few lines of TOML.
• Scores you can settle. A jevlint-score comment fixes an accepted score with a reason, so nobody chases points. See Pinning scores.
• Ready for coding agents. jevlint prompt | claude -p, or let jevlint fix run the agent. A Claude Code plugin and an edit hook are included.
• Pay for an answer once. Results are cached by content, and an S3-compatible bucket shares them across CI and your team.

• Not a replacement for your linter. Keep ESLint, Ruff, Clippy and your type checker for what they can decide exactly. jevlint ranks what they cannot judge.
• Not a verdict. Model scores are calibrated opinions. They vary between models and can move between model versions, so treat them as candidates for a person to review, pin a model version in CI, and use jevlint test to see when a question drifts.
• Not private by default, once a provider is on. Everything except --ast-only sends code to the provider you configure. See Before you run it.

jevlint auth set typesafe   # store a key once, per user
jevlint init                # create jevlint.toml in this repository
jevlint audit --dry-run     # see what would be sent, with no provider requests
jevlint audit               # rank the whole codebase

No TypeSafe access? Use another provider, such as openai, cloudflare or gateway.

jevlint prompt --top 3 --copy      # paste into any agent
jevlint prompt | claude -p         # or pipe it
jevlint fix --agent claude         # or run the agent, then re-score
jevlint quickfix --agent claude    # or let it only edit, then see the diff, new score and commit

In Claude Code, install the plugin for a skill and /jevlint:audit, /jevlint:explain and /jevlint:review. Its edit hook is off until you turn it on:

/plugin marketplace add INDXDev/jevlint
/plugin install jevlint@jevlint

See Coding agents.

jevlint spec turns your documents into a checklist, then checks code and documents against it:

jevlint spec compile --copy   # a prompt for your agent: write .jevlint/spec from the docs
jevlint spec check            # which files violate an item, and which items nothing implements
jevlint spec drift            # where the docs and the checklist disagree

The checklist is YAML with two levels: a project checklist, and one per feature. Each file is first routed to its feature, then judged against that feature's items only. See Spec-driven development.

An ast-grep pattern decides which code is looked at. One question decides whether it is a problem, and yes means a violation. Each hit is reported on its line:

# jevlint.toml
[[rules]]
id = "catch-hides-failure"
language = "typescript"
pattern = "try { $$$ } catch ($E) { $$$ }"
question = "Does this catch block swallow a failure the caller needed to know about?"
message = "This catch hides a failure"
fix = "Rethrow it, or return an error the caller must handle."
threshold = 0.8   # optional: report at or above this probability

Each match is one provider request, up to max_rule_matches per rule and file, and --ast-only skips rules. See Semantic rules.

Prove a preset question works with good-* and bad-* fixtures, and catch a model update that moves it:

jevlint test            # every fixture must land on the right side
jevlint test --record   # save today's answers
jevlint test --drift    # ask again, and list what moved

jevlint pr --ast-only                # what this branch's pull request made worse
jevlint pr 42 --ast-only             # the same, by number
jevlint commits --count 5 --ast-only # the same, commit by commit
jevlint commits --count 5 --intent   # also check each message and AGENTS.md against the diff

Your working tree stays as it is, and your own config applies, not the change's. --intent reads the repository's instructions from the base commit, so a change cannot rewrite what it is judged by. See the CLI reference, and Continuous integration to run it on every pull request.

Catch a regression before it is committed, with no key and no network:

jevlint init --pre-commit   # stops a commit that makes a file worse than HEAD

# jevlint.toml
[scoring]
fail_under = 60    # exit 1 below this

On a legacy codebase, gate on what is new instead of on the score:

jevlint baseline --ast-only                      # commit .jevlint/baseline.json
jevlint audit --new --ast-only --format github   # exit 1 on anything new, as PR annotations
jevlint audit --ast-only --format sarif > jevlint.sarif   # for code scanning

See CI.

Jev made a linter an obvious thing to build, and several people built one independently. None of these is affiliated with this project. They answer different questions, so pick by what you need:

Baselines, SARIF output, fixtures, drift checks and message checks here follow the lead of the first two projects above. jevlint, jev-lint and @hazymoon/jevlint all use ast-grep to read code.

# jevlint.toml
presets = ["readable-code", "solid"]
include = ["src/**"]
exclude = ["**/*.generated.ts"]

[provider]
name = "typesafe"
model = "jev-latest"

[scoring]
scale = 100        # use 1 for scores from 0 to 1
fail_under = 60    # exit 1 below this, for CI

[weights]
"readable-code.naming" = 3   # care about this more
"solid.dependency-inversion" = 0   # turn this off

Start with the documentation index.

• Getting started
• Concepts
• CLI reference
• Configuration
• Providers
• Presets
• Scoring
• Architecture review
• Architecture-driven development and the SSOT reference
• Spec-driven development and the spec reference
• Coding agents
• Caching
• Continuous integration
• JSON output
• Security and privacy
• Troubleshooting
• Architecture and code reference

An audit sends the contents of your source files to the provider you configure. Read Security and privacy first if your code is confidential. audit --ast-only never touches the network.

See CONTRIBUTING.md. To report a vulnerability, see SECURITY.md.

MIT

jevlint is an independent open-source project. It is not affiliated with or endorsed by TypeSafe AI, Cloudflare, Microsoft, OpenAI, Vercel or Anthropic. All product names are the property of their respective owners.