Question 1

Is this just another opinionated linter that will fight my formatter?

Accepted Answer

It is scoped to avoid that overlap. Formatting stays with Prettier, syntax and static patterns with ESLint, types with the compiler, behavior with tests, and known credential formats with a secret scanner. jev-pref is for semantic rules you can state as an externally defined, evidence-grounded condition, and the guidance is explicit that deterministic tooling should keep the rules it enforces reliably.

Question 2

What stops me from asking Jev whether this code is good and getting confident nonsense?

Accepted Answer

Setup classifies each candidate preference as DIRECT, NEEDS SHAPING, or NOT FOR JEV, and only DIRECT candidates become checks. The bar is that you must be able to explain what visible evidence would make the answer true. Anything about architecture quality, cleanliness, or test sufficiency is either routed away from Jev or reshaped into a concrete observable condition, one semantic predicate per check.

Question 3

Will a wide diff blow past Jev's input limit?

Accepted Answer

Jev input is capped at 30k tokens and each call sees only its own scope. You pick the scope explicitly: --hunks for focused per-hunk work with file and line attribution, --files for broader changes and pull requests, and --include or --exclude to narrow further. --dry-run shows the planned questions and state without a live call, so you can see the shape before spending.

Question 4

Can I prove these checks work, or is the threshold just a guess?

Accepted Answer

Only against labels you write yourself. tune scores each case in evals/*.json with one Jev call and reports accuracy at the current gateThreshold, comparing P >= threshold against the expected true or false for conditions and the selected label for choices. --sweep re-scores frozen answers from 0.5 to 0.9 and proposes a gateThreshold diff without writing anything.

Question 5

Where do the checks live, and how do they stay in sync with my docs?

Accepted Answer

setup writes jev-pref.json as committed shared checks, a gitignored jev-pref.local.json if you want a local layer, and a review plus sync contract into AGENTS.md, CLAUDE.md or wherever you choose. npx jev-pref sync then reads the guidance files, both config layers and git ignore state, prints the reconciliation protocol for the agent, writes nothing and decides no policy.

Question 6

What outcomes can a check produce, and can I gate CI on it?

Accepted Answer

A condition is a Bernoulli question: Jev estimates p(true) and the gate threshold turns it into approve, advisory or fix_now, and verdicts keep an exit-code contract that CI, hooks and scripts can rely on. --raw opts out of that, printing P, confidence and the cutoff per preference and scope, applying no outcome, ignoring --fail-on and always exiting 0 on success.

Question 7

Where does the API key live, and what actually gets sent?

Accepted Answer

Credentials stay environment-only: setup records the variable name and never its value, so the key itself is never written into the repo. What leaves your machine is the reviewed change text under the scope you chose plus your stated guidance, which is why the README says only conditions visible in the review input should be encoded as checks.

Jev Pref

About this project

Highlights

Quickstart

Questions about this entry

Reactions & coverage

From the Jev guides

From the Jev AI model community