jev-tools asks OpenJev (Codiv "System One") typed questions (yes/no, pick-one, score) and gets calibrated probabilities back instead of generated text. There is nothing to parse and nothing to hallucinate; your own code applies the thresholds. It runs against the hosted API, a model on your own machine, or in an offline pattern-only mode.

Write-up with the numbers, failures and privacy notes: I built a Claude Code plugin around a model that only answers yes/no · feedback welcome in issue #1.

🚀 Quick start

You need: Python 3.10+ as the command python (the hooks call exactly that), the claude CLI, and uv or pipx.

# 1. install the setup tool (once)
uv tool install jev-tools-setup          # or: pipx install jev-tools-setup

# 2. optional, read-only: is this machine ready?
jev-tools-setup check

# 3. install the plugin and choose how Jev runs
jev-tools-setup

Setup installs the skills, scripts and hooks through Claude Code (so terminal and desktop share one install), asks which backend you want, validates it, and finishes by writing ~/.jev-tools/LOG.md. Restart Claude Code, then run the status skill to confirm everything is wired.

Prefer a one-shot run without installing anything? uvx jev-tools-setup check and uvx jev-tools-setup work too. To run the latest unreleased code straight from GitHub, use uvx --from git+https://github.com/Rcidshacker/jev-tools jev-tools-setup.

/plugin marketplace add Rcidshacker/jev-tools
/plugin install jev-tools@jev-tools

🔀 Choose how Jev runs

jev-tools-setup serve        # add --device cpu to force the CPU

🧰 What's inside

⚙️ How it works

flowchart LR
    A["Claude Code event<br/>edit · prompt · skill"] --> B["jev-tools script"]
    B --> C{"backend"}
    C -->|api| D["api.codiv.ai"]
    C -->|local| E["Verdict · Laya · OpenJev<br/>127.0.0.1:8080"]
    C -->|offline| F["keyword and pattern<br/>fallbacks"]
    D --> G["typed answers<br/>yes/no · pick · score"]
    E --> G
    G --> H["thresholds in plain code"]
    F --> H
    H --> I{"mode"}
    I -->|shadow| J["log only"]
    I -->|active| K["block or inject"]

Each piece turns a fuzzy judgment into typed questions, sends them with the relevant text as state to POST /v1/systemone, and applies thresholds in ordinary code. Every failure path is explicit: hooks fail open (an outage never blocks your edit or prompt) and the review pre-check fails safe (an outage routes to full review). Details and the reasoning behind each threshold: HOW_IT_WORKS.md.

Modes

Recommended path: run in shadow for a week, read LOG.md, run rule-calibrate on a project, then switch that setup to active. Set the mode with the plugin's mode option or JEV_MODE (the variable wins).

🔒 Privacy: what leaves your machine

With the api backend this plugin sends text to a third party (api.codiv.ai). local and offline send nothing. Read this before enabling api on any project.

• Shadow mode still sends. The hook needs the model's answer to log it. Only mode: off sends nothing.
• A local seatbelt runs first. Before sending, these become [REDACTED]: private-key blocks, vendor-style keys (sk-/sk_live_, AWS, Google, GitHub, Slack, npm), JWTs, Bearer tokens, credentials in connection strings, assignments to names containing password/secret/token/api key, and long hex or base64-looking strings. Files named like secrets (.env*, *.pem, *.key, id_rsa*, credentials*, secrets* …) are never read into a request. It is a pattern match: a bare token in an unusual shape, names, emails, customer or employee records and internal business data are not caught, and about 0.2% of ordinary code lines that mention token/secret get partly redacted. Risk reduction, not a guarantee.
• Retention is unknown to us. Codiv's public API docs say nothing about how request data is stored or used. Check their terms before sending anything you would not paste into a public forum.
• Nothing sensitive is stored locally. The decision log holds verdicts, probabilities, latency and token counts, never file contents and never the key.

Turn it off for one project (regulated, customer, employee or client data) in that project's .claude/settings.local.json:

{ "env": { "JEV_MODE": "off" } }

🩺 When something looks wrong

jev-tools-setup always ends by writing ~/.jev-tools/LOG.md, even when setup fails. Refresh it any time with jev-tools-setup report, or run the report skill inside Claude Code. It merges every decision log (the plugin data directory and ~/.jev-tools) into plain English:

• a one-line health verdict: ✅ healthy · ⚠️ notes · ❌ problems
• your setup: backend, model, mode, which variable the key came from (never the key), which logs were read
• problems, each with a fix
• what happened: event counts, median latency, rule checks flagged
• your setup history and the last 40 events, one sentence each

It contains no API key, file contents or prompts; home paths show as ~ and key-shaped strings are redacted, so it is safe to attach to an issue.

Hooks fail open, so a broken install looks identical to a working one until you look at the log. That is exactly what LOG.md and the status skill are for. To remove everything: jev-tools-setup uninstall deletes ~/.jev-tools (key, config, log); remove the plugin with /plugin uninstall jev-tools@jev-tools.

📚 Reference

.claude-plugin/plugin.json       plugin manifest and user settings (api_key, mode, skill_picker)
.claude-plugin/marketplace.json  single-plugin marketplace so /plugin marketplace add works
installer/jev_tools_cli.py       the jev-tools-setup command (setup, check, serve, report, uninstall)
installer/jev_report.py          builds LOG.md (also run by the report skill)
hooks/hooks.json                 the two hooks
scripts/                         jevlib.py (client) and one script per piece, review_policy.json
skills/<name>/SKILL.md           six skills
tests/test_all.py                offline suite against a local mock of /v1/systemone
docs/                            how it works, measurements, build log, Codiv API notes
pyproject.toml                   packages the installer as jev-tools-setup

🛠️ Development

python tests/test_all.py          # offline suite, no network, no key needed
python scripts/jevlib.py          # one live call, needs OPENJEV_API_KEY
uv build                          # builds the jev-tools-setup wheel and sdist
# releases: publishing a GitHub release runs .github/workflows/publish.yml (PyPI trusted publishing, no token)

The tests spin up a local server that mimics /v1/systemone, so they prove the logic and the wire format, not OpenJev's accuracy. Accuracy claims come only from the live runs recorded in the docs. See the CHANGELOG for what changed in each version.

🙏 Credits

Ideas and hard-won numbers borrowed, with thanks, from projects that got there first (exactly what was taken from each: BUILD_LOG.md): abide (rule compilation, calibration verdicts, second look) · hermes-jev-skills (confidence floor, two-stage retrieval) · jev-kit (shadow-first rollout) · jevgate (confirming before acting) · jev-skill-router (plugin layout, honest field report on skill routing). The small local models are Verdict by Heman10x and Laya by Nandakishor M / Convai Innovations, served by OpenJev.

Built with Claude Code. MIT licensed, see LICENSE.