Jev System Architect

项目摘要

The skill helps a coding agent recognize patterns such as prompt → JSON → parser → retry and propose smaller Jev Choice, Noul, or Score boundaries while leaving execution and policy in application code.

来源原文

I dropped a generic Jev System Architect skill. And I think the distinction behind it is important. TypeSafe already has an official skill for Jev that helps coding agents understand the API, SDK, primitives, and implementation patterns. But there’s another question that comes before implementation: Where should Jev exist in the system in the first place? That's what this skill is for. Most AI coding agents are increasingly good at: "Implement this API." They're much less reliable at recognizing: "We just built 300 lines of brittle semantic logic because nobody realized this should have been a tiny probabilistic decision boundary." So the skill continuously looks for patterns like: unstructured information ↓ fuzzy semantic judgment ↓ software needs a typed answer Those are potential Jev boundaries. For example: Customer message ↓ Huge LLM prompt ↓ "Return JSON" ↓ parse validate retry ↓ route ticket Maybe you don't need an agent there. Maybe you need four judgments: ┌→ topic Choice │ MESSAGE → JEV ──┼→ refund requested? Noul │ ├→ frustration Score │ └→ fraud signal? Noul ↓ CODE ↓ decides what happens That architecture is fundamentally different. Jev supplies programmable judgment. Your software still owns the system. The skill teaches an agent to inspect a codebase for things like: → prompt → JSON → parser → retry pipelines → giant semantic if/else trees → expensive reasoning models doing tiny classifications → agent loops whose entire purpose is making one bounded decision → brittle routing logic → semantic verification → RAG relevance decisions → guardrails → fuzzy extraction from known candidates → tool/function selection Then it asks: Should Jev actually be used here? Importantly, "no" is a valid answer. If the problem is deterministic: use code. If the output needs to be genuinely generative: use a generative model. If the task requires deep multi-step reasoning: use a reasoning model. But if normal software encounters something it can't semantically understand and only needs a bounded judgment to continue... that's where Jev gets interesting. The skill then helps decompose that boundary into: Choice – Which bounded option? Score – Where does this sit on an ordered semantic spectrum? Noul – What's the probability this proposition is true? And instead of one enormous prompt: Analyze this customer, determine whether they're angry, whether fraud is likely, whether they want a refund, which department should handle them, what priority they should receive, and what we should do next. You get atomic judgments: topic → Choice refund_requested → Noul fraud_signal → Noul frustration → Score Then: JEV ↓ typed probabilistic judgments ↓ CODE ↓ compose / route / verify / ask / escalate / execute The skill also pushes several architectural principles I think matter a lot: 1. Batch independent judgments. If five questions can see the same state, don't automatically make five sequential model calls. Fan them out. ┌→ urgency ├→ category STATE → JEV ─────┼→ sentiment ├→ refund? └→ escalation? 2. Treat uncertainty as part of the interface. Typed does not mean infallible. So your application can explicitly decide: high confidence → automate uncertain → gather more evidence lower confidence → human review And those thresholds should depend on the consequence of being wrong. Showing the wrong help article and moving money should obviously not share the same risk policy. 3. Keep side effects in code. Jev can help determine: "Does this look like a cancellation request?" Your application should still own: permissions authorization transactions tool execution policy side effects 4. Use Jev around generative models too. This is where I think things get especially interesting. INPUT ↓ Jev guardrail ↓ LLM ↓ Jev verification ↓ CODE ↓ return / retry / escalate Or with RAG: query ↓ retrieve 50 passages ↓ Jev relevance / injection judgments ↓ keep the useful context ↓ reasoning model The broader idea is: We're very quickly giving software access to increasingly powerful reasoning and agency. But not every intelligent decision needs an agent. Sometimes software just needs a tiny piece of machine judgment. My mental model for Jev is increasingly: CODE ↓ encounters something deterministic code can't understand ↓ JEV ↓ small typed probabilistic judgment ↓ CODE ↓ continues deterministically Or even shorter: Give normal software access to programmable common sense. I packaged the architecture rules into a reusable SKILL.md so coding agents can recognize those boundaries themselves. Works with Cursor / Claude Code / compatible skill harnesses. MIT licensed. I recommend pairing it with TypeSafe's official skill: their skill → how to implement Jev This skill → where and why to use Jev Repo: https://github.com/samtay32/jev-system-architect

原记录的限制

• This is an architecture aid, not proof that every proposed boundary improves a production system.
• The skill cannot replace open-ended reasoning, code generation, or authorization logic.
• Every suggested boundary needs human review and a task-specific evaluation set.