jev-skill: a catalogue of decision skills for coding agents

Jev chooses, the agent acts

The one-line summary in the README sets the division of labour, and it is the design idea behind the whole repository. Jev chooses, classifies and scores, and your agent supplies evidence and takes action.

That is a narrower contract than most agent tooling offers. Instead of asking a model to reason and act in one step, the collection provides a way to make the choosing step explicit, and the agent keeps the parts that need a model. The illustrated guide listed among the demos, credited to the author of an illustration of Noul, Choice and Score, suggests there are three primitives in the vocabulary, and the Learn Jev demo is described as three ways to ask Jev.

The scale of the collection is stated in the badges and repeated in the overview text. There are 5 skills, 108 scenarios, 67 projects and resources, and 14 recorded input/output pairs. The overview also points to two areas beyond the main catalogue, semantic find, presented as a semantic command-F, and story sensors.

The audience is a developer working with coding agents who wants a repeatable decision procedure rather than a bespoke prompt for each task. The three-column contents table in the README frames it the same way: projects for demos, apps and local models, skills for installing and picking a skill, and examples for finding a task, editing a template and seeing the output.

The project calls itself an awesome collection of Jev use cases, workflows, and agent skills, and the description says the same. It is a catalogue, and the value depends on what is in it.

Installing is a prompt, not a package

The install story is unusual and worth reading carefully, because it determines what you are actually installing.

The README says that if you are new you should give the install prompt to your agent, and if you are already installed you should ask it to update. The install section is linked from the skills badge, and there is a separate update log under docs/updates/ with dated entries, one of which is the September 20 note about adding semantic find, sponsor segments, story sensors, MIDI composition and local-model comparisons.

So the unit of installation is a skill that your agent knows how to read and follow, not a wheel you add to your environment. That is the pattern used by agent skill collections, and the .claude/ directory at the repository root is the giveaway that these skills are written for an agent runtime rather than for a Python program.

The Python package is a thin wrapper around that content, and the packaging tells you how thin. The build is setuptools with a build requirement of setuptools>=77, the project name is jev-skill at version 0.2.1, it requires Python 3.10 or newer, and the dependencies list is empty. The distribution exposes a single console script:

[project.scripts]
jev-decide = "jev:main"

And the packaging section points the module at the skills directory:

[tool.setuptools]
py-modules = ["jev"]
package-dir = {"" = "skills/jev/scripts"}

So the single module lives at skills/jev/scripts/jev.py, and installing the package puts a jev-decide command on your path. There is no runtime dependency list to audit, which is unusual and mostly a good sign for a collection like this.

The catalogue: demos, apps and what each one shows

The Projects section is explicitly labelled as community projects separate from the skills, and the README states plainly that listed does not mean installed or tested, and that alternatives are not official Jev and are not connected automatically. That disclaimer is the first thing to read, and it is a good one, because a list of 67 entries is a list of things someone built rather than things the maintainers verified.

The Demos subsection is presented with a warning of its own: these are community demos and an illustrated guide, clicking a preview opens the original, and they are not the maintainers' test runs. Six demos are shown in a table of preview images. The browser demo, where Jev picks browser steps, links to a project in the browser-use organisation. The Tetris demo, where the code lists legal moves, links to a project called jev-tetris. The whale city demo, where Jev runs a small world, is an author's post. The music demo, where Jev picks music parts, links to a project called jevthoven. The code review demo, where Jev flags code to check, links to jev-review. And the Learn Jev demo, with the illustration of the three primitives, links to jev-explained.

The Apps table that follows is more concrete because it names what each project does and where the claim comes from. Jev Ultrafast handles DOM actions with a small LLM handling typing. WebMCP, also called WindTunnel, does website-tool selection and has a published browser benchmark. Stagehand plus Jev places Jev inside act, observe and extract primitives.

Two things are worth noticing in that sourcing column. The claims are attributed to a README, a report or an author post, which is how a community catalogue keeps itself honest, and the browser cluster suggests the most-developed integration area is browser automation.

Scenarios, evaluations and the recorded examples

The parts of the repository that are not the community list are the ones a user actually installs.

The skills directory is the payload. The pyproject packaging points at skills/jev/scripts, and the README describes the workflow as finding a task, editing a template and seeing the output, which is the shape of a template-driven skill collection. The 5 skills badge and the 108 scenarios badge sit side by side in the header, and the description of the scenarios is a task to find, a template to edit and an output to see, with 14 recorded input/output pairs provided as reference.

The evals/ directory is the part that separates this from a prompt dump. A collection of skills with recorded expected outputs is something you can regression test: change a skill, re-run the evaluation, and see whether the outputs still match. The tests/ directory and the CI badge in the header, pointing at a test workflow, suggest the repository is checked rather than merely published.

There is a second evaluation angle in the catalogue itself, the local-model comparisons added in the September 20 update. Comparing how the same skill behaves on different local models is a different question from whether the skill produces a good decision, and having both in one repository is unusual.

The release history shows the same progression. v0.1.1 is titled context-first, parallel decisions, v0.1.2 is choose Jev or your current agent, and v0.2.0, the most recent tagged release from 2026-09-21, is project collection, guided setup and evaluation workflows. Each title names a feature that arrived in that release, which is a legible changelog.

Maintenance, licence and the shape of the project

The licence is MIT, recorded in pyproject.toml and in the LICENSE file at the repository root, and the licence identifier in the header badge matches. For a collection of skills and prompts that you copy into your own agent setup, a permissive licence is the right call, since there is no copyleft obligation on anything you derive from it.

The repository is not archived and the last push was on 2026-10-17, four days before the present date, so the collection is being worked on. The tagged releases are recent as well, v0.2.0 from 2026-09-21, v0.1.2 from 2026-09-20 and v0.1.1 from 2026-09-20, which means the project is young and moving fast. The version in pyproject.toml is 0.2.1, one patch past the last tag.

The layout shows a documentation-heavy project. There is a docs/ directory holding the update log and media credits, an evals/ directory, a skills/ directory, a tests/ directory, a .claude/ directory for the agent runtime configuration, a CLAUDE.md file, a CONTRIBUTING.md, a MANIFEST.in, and both an English README and a Simplified Chinese one at README.zh.md, with the header linking the two side by side.

The Chinese translation and the per-date update log are the two signals that this is a project being maintained in public with a community around it. The contributor list in the README is long, and the header thanks everyone who has contributed.

Where jev-skill is the wrong thing to reach for

The first case is a team looking for an agent framework. This is a collection with five skills and 108 scenarios. It does not provide a runtime, a tool protocol, a memory layer or an evaluation harness for arbitrary agents. If your need is a platform to build agents on, this is the wrong shape of thing, and the fact that it is a Python package with one console script should make that clear early.

The second case is a team that needs a decision record for its own system. The framework here is about making an agent's choice explicit, with the evidence and the score visible. If you want the same discipline applied to a service's own routing, caching or fallback logic, you would be adapting the vocabulary rather than adopting the tool, and at that point the collection's value is the idea, not the artefact.

The third case is a team that needs to trust a community list. The Projects section is 67 entries of things other people built, and the README says twice and in bold terms that listed does not mean installed or tested. That honesty is welcome, but it means the number is a discovery aid rather than a supply chain, and every entry you pull in is code you have to read yourself.

The alternative worth comparing is not a different collection, it is doing the thing yourself. Writing three or four skills of your own, with explicit choices and a score, and storing them in version control alongside your agent configuration, gives you a collection of exactly the size you need, maintained by the people who own the codebase, with no dependency on an external catalogue's release cadence. The difference in approach is ownership. jev-skill offers a maintained, tested set of skills and a ready-made evaluation harness, and it asks you to accept the maintenance model that comes with adopting someone else's agent behaviour, which is a decision about how much of your agent's judgement you want to own.

Editorial conclusion

jev-skill fits a developer who wants a coding agent to make an explicit choice, with the evidence and the score visible, rather than producing a plausible answer with no trace of how it got there, and the evaluations and recorded input/output pairs give you something concrete to compare against. It is the wrong choice if you want a general agent framework to build on, since the repository is a catalogue with five skills and 108 scenarios rather than an extensible platform, and it is the wrong choice if you need a service or an API to call. Before adopting it, read the install prompt and the skill definitions under skills/ rather than the README alone, check the recorded examples in the evaluation directory against your own tasks, and decide whether you will keep the jev-decide command in the loop or let the agent call the skills directly.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. wuyoscar/jev-skill on GitHub