JJev Cookbook
课程首页 中文文档 拓展阅读 GitHub ↗

拓展阅读 / Awesome Jev：生态资料导航

知识库收录材料 · 原始文件 ↗ · 来源、版本与许可

name: jev-curation description: Curate and expand the awesome-jev repository. Use when adding Jev projects or cases, collecting discussion evidence from X/Reddit/HN/blogs, promoting discussion items into main categories, refreshing README counts, or running periodic evidence sweeps.

Jev Curation

Use this skill to maintain awesome-jev as a strict, high-signal list of projects and practices built on Jev.

Goal

Keep the repository focused on two questions:

  1. Where is Jev actually being used in public?

  2. Which decision patterns transfer across domains?

This skill is for curation, not general AI news collection. Jev is a typed-decision model: Choice, Score, Boolean, each with confidence. Entries that do not involve a Jev decision do not belong here.

Source of truth

Read these files before making changes:

  • README.md

  • CONTRIBUTING.md

  • every file under categories/

README.md is the homepage aggregate, not the primary editing surface. Update category files first, then refresh README.md from the current category files. Always use scripts/build-readme.py instead of hand-editing the aggregate.

Hard inclusion rules

Only include items that satisfy at least one of these:

  • explicitly name Jev / jev

  • explicitly cite TypeSafe AI's System One models

  • clearly implement a typed-decision loop (typed question → typed answer + confidence → accept / reject / escalate)

And all of these:

  • source is public and citable

  • description is concrete

  • entry stays one sentence

  • item is strictly Jev-relevant, not a generic classifier, router, or LLM judge

Reject:

  • generic classifiers, routers, or decision agents with no Jev involvement

  • launch-hype commentary with no artifact

  • private or uncitable claims

  • things that need a paragraph to justify inclusion

Category model

Use main category pages for stronger evidence such as:

  • public repos

  • project pages

  • substantial write-ups

  • benchmark or evaluation results

Use categories/related-practices-discussions.md for:

  • X threads

  • Reddit discussions

  • Hacker News threads

  • interviews

  • blog mentions

when they show credible real practice signals but do not yet have a strong standalone repo or case page.

Main categories: classification-routing, verification-guardrails, scoring-ranking, agent-decisions, data-labeling-curation, evaluation-benchmarking, calibration-research, infra-sdks-integrations, related-practices-discussions.

Open categories still being seeded: content-moderation, compliance-legal, game-simulation, scientific-pipelines.

Working strategy

1. Search broadly, classify narrowly

Preferred evidence channels:

  • GitHub

  • X / Twitter

  • Reddit

  • Hacker News

  • Vercel AI Gateway / AI SDK ecosystem

  • independent blogs / write-ups

2. Keep queries simple

Prefer medium-complexity searches such as:

  • jev typesafe

  • typesafe-ai/jev

  • jev Choice Score Boolean

  • Jev System One Model

  • jev classification routing

  • jev verification guardrail

  • Jev Diogo Almeida

Avoid very long advanced-search expressions when the adapter is unstable.

3. Chinese + English

Search in both languages when useful. Useful Chinese patterns:

  • jev 大模型 决策

  • TypeSafe Jev 分类

  • Jev 类型化决策

Keep Chinese queries narrow to avoid noisy generic matches.

Promotion workflow

Use this exact ladder:

  1. Discussion lead found

    • Add to categories/related-practices-discussions.md if it is credible and directly Jev-related.

  2. Evidence chain search

    • Look for repo, project page, case page, or blog post.

  3. Promotion test

    • Promote only if public evidence clearly shows a real Jev decision in use.

  4. Promote

    • Move it into the best-fit main category.

  5. Deduplicate

    • Remove the weaker discussion-only item if the main case now covers it.

  6. Refresh counts

    • Run scripts/build-readme.py if category totals changed.

Entry-writing rules

Main categories

Format:

md
- [Name](URL) - Industry: one-sentence description of the Jev use case.

Rules:

  • one sentence only

  • must mention the decision + the typed shape (Choice / Score / Boolean) + the gate or escalation

  • prefer concrete verbs like classifies, routes, gates, scores, verifies

  • include a number when the source provides one

  • avoid hype

Discussions page

Format:

md
- [Name or thread title](URL) - Source/platform: one-sentence description of the Jev-related practice or discussion.

Rules:

  • keep it factual

  • describe the practice signal, not your opinion

  • if it is mostly about transfer of the pattern, say that clearly

Periodic maintenance loop

When invoked for a recurring sweep:

  1. Read the current category files.

  2. Search for 3-10 new public leads.

  3. Filter aggressively.

  4. Add only high-signal entries.

  5. Attempt promotion for the strongest discussion leads.

  6. Remove duplicates.

  7. Recount category totals.

  8. Refresh README.md so the homepage aggregate matches the current category files and counts.

  9. Publish one short X post covering the round, following the 统一格式 in /skill:tweet-posting-cdp (same layout for both awesome lists), then summarize what was added, promoted, and rejected.

    • Verify with DRY_RUN=1 first; the script prints 内容校验通过：N 字符 / M 段落 and must match before actually posting.

Suggested commands

Count entries:

bash
python3 scripts/build-readme.py && sed -n '/## Current coverage/,/Each entry lives/p' README.md

Example searches:

bash
bb-browser site twitter/search 'jev typesafe' --json
bb-browser site google/search 'site:github.com "typesafe-ai/jev" OR "jev" typesafe | sed -n "1,120p"'
bb-browser site google/search 'site:news.ycombinator.com jev typesafe | sed -n "1,120p"'
bb-browser site google/search 'site:reddit.com jev typesafe model | sed -n "1,120p"'
opencli gh api repos/typesafe-ai/jev/readme

Quality bar

Promote slowly. Add discussions faster.

If evidence is good but not strong enough for a main case, keep it in discussions. Precision beats coverage. This model shipped in September 2026, so the corpus is small — resist padding it.

Before adding a repository, check depth (see CONTRIBUTING.md, "AI-assisted work, and bulk submissions"):

  • Does the code actually call the Jev API, or is the claim README-only?

  • Is there a runnable check (test, example with expected output, public demo)?

  • Is the repository mostly prompt documents? Then describe it as such, or skip it.

  • Does a batch of same-day repositories share one scaffold? That is a risk signal, not momentum — review each on its own merits, and cap a single author at three entries per rolling seven days.

  • Are the numbers in the entry traceable to the linked page? Strip what you cannot verify.

Handling pull requests

When a contributor opens a PR:

  1. Verify the repository, do not just read the PR body — file tree, source, tests, CI, commit history, and whether the code really calls the Jev API.

  2. If the repository is thinner than the entry implies (README-only claims, no runnable check, docs outweighing code), say so in a review comment and ask for the missing evidence rather than merging or silently rejecting it.

  3. When an author already has three entries accepted in a rolling seven-day window, state the rule in the PR comment before acting, and queue the extra entries to a later cycle instead of rejecting them. Link the CONTRIBUTING section so the contributor knows it is policy, not a judgement about them. Queue by submission order, never by quality — picking "the best three" turns the rule into a hidden quality verdict, which is exactly what it exists to avoid. If one of the queued entries has more stars than the merged ones, say so explicitly in the comment.

  4. Bulk AI-generated submissions are a rule, not a preference (CONTRIBUTING → "Rule: do not submit bulk drops of AI-generated projects"). Before merging a cluster of same-author, same-day repositories, check for a shared scaffold (AGENTS.md / CLAUDE.md / STATE.md), a common README template, or single-commit histories — those mark one project family, which counts as one submission, so merge at most one and queue the rest. Disclose-or-pause also applies: if a submission was generated and not disclosed, hold the author's whole pending batch until they say so.

  5. Never edit a contributor's wording purely for style; do fix inaccurate claims.

  6. README.md is generated — when a PR conflicts there, rebase the branch and regenerate it (python3 scripts/build-readme.py) rather than hand-resolving. For conflicts in a category file, keep main's version and append the PR's new line.

  7. An entry written only into README.md (no category file) will be silently erased by the next generator run. Move it into the right category file, regenerate, amend the commit, and push back to the contributor's branch — then say so in a comment, including that the mistake is easy to make from the current docs.

  8. Use scripts/maintainer/merge-prs.sh to process PRs in bulk. It handles the four traps that make manual merging tedious: fork repository names vary (awesome-jev, awesome-jev-yibie, yibie_awesome-jev, awesome-jev-1), so it resolves them via headRepository.nameWithOwner; it fast-forwards local main before rebasing, because rebasing onto a stale base leaves the PR conflicting after the push; it loops over conflict rounds, because a PR with two commits (add the entry, then reword it) conflicts twice; and it appends the PR's entry with grep -qF -- so an entry starting with - [ is not parsed as a grep option.

  9. A PR that edits only a category file merges cleanly and leaves the README count stale, so merge-prs.sh rebuilds the README after every merge and pushes a follow-up commit when it drifted.

  10. Every PR touches the adjacent count lines in README.md, so from the second PR onward conflicts are normal, not a sign of a bad contribution. Expect to rebase and force-push to the contributor's branch (most forks have maintainerCanModify: true) rather than asking them to resolve it.

Deliverable checklist

Before finishing, verify:

  • entries are one sentence

  • no generic classifiers or judges slipped in

  • promoted items have stronger evidence than discussion-only items

  • discussions page remains useful as a map of emerging practice

  • README homepage aggregate matches the current category files

This skill should be used for prompts like:

  • "继续搜集 awesome-jev"

  • "做一轮 Jev 证据巡检"

  • "把 discussions 里强条目升格"

  • "更新 jev awesome list"

  • "定期维护这个仓库"

第十一章知识库收录材料 · 来源、版本与许可 · 第三方内容版权归各自作者；观点与数字请对照原始来源核验。